We've been doing some work with our application to make it Slony-aware.
Specifically, we want the application to detect when a switchover is
occurring and behave in a rational manner.  The goal here is the illusion
of zero downtime, so we want the application to detect that a switchover
is occurring and "stall" until it is complete.

As best I can tell from experiments, during switchover there is a period
where, for all intents and purposes, all the nodes are slaves and there
are no masters.  Once this is accomplished, the triggers are reorganize
on the new master and updates can proceed again.

Works for me.  The part that's throwing me is the error returned.  In
src/backend/slony1_funcs.c the following statement appears:
elog(ERROR,
         "Slony-I: Table %s is replicated and cannot be "
         "modified on a subscriber node",
         NameStr(tg->tg_relation->rd_rel->relname));

My concern is that on the client end, this results in the SQLSTATE
returned as the default XX000, which is more or less "general failure"
(according to the docs, it's "INTERNAL ERROR")

This forces us to parse the returned message to determine whether the
problem was the result of talking to a Slony system that is replicated
or some other (totally unrelated) problem.  Parsing error messages makes
me queasy ;)

Looking at the valid SQLSTATEs:
http://www.postgresql.org/docs/8.1/interactive/errcodes-appendix.html
there's obviously not one for "This is a read-only Slony replica", but
2F002 (MODIFYING SQL DATA NOT PERMITTED) seems more POLA than a generic
error.

I recommend the following to replace the above code snippet:
ereport(ERROR,
        (errcode(MODIFYING_SQL_DATA_NOT_PERMITTED),
	 errmsg("Slony-I: Table %s is replicated and cannot be "
                "modified on a subscriber node",
                NameStr(tg->tg_relation->rd_rel->relname)));

I think this is a general improvement no matter what.

However, it doesn't _totally_ solve my particular problem.  Since other
(not uncommon) conditions can return that SQLSTATE, I'm still reduced
to parsing the error message text.

So, I'm suggesting the above change.  But I'm also fishing for ideas on
how to more deterministically communicate Slony's state to client
applications.

Ideas?

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023