On Wed, Jun 25, 2008 at 5:40 PM, Troy Wolf <troy at troywolf.com> wrote:
> DISCLAIMER: I am a relative newbie myself, so my advice is worth what you pay...
> If, like the user in the link you provided, you are trying to
> SUBSCRIBE, then use WAIT FOR EVENT to know when the SUBSCRIBE has
> completed, then your problem is that this does not work. WAIT FOR
> EVENT is unable to reliably know when the subscribe has completed, and
> you cannot MERGE SET until the SUBSCRIBE completes.
>
> You'll probably notice that if you wait long enough--usually a few
> seconds depending on your data size--the MERGE will work.

Correct on both counts.

> If the MERGE never works and keeps telling you a SUBSCRIBE is in
> progress, then check your logs to see if something is holding up the
> subscribe--like older transactions or locks. Look for
> removeWorkerThread warnings about "transactions earlier than XID %s
> are still in progress". Then you may have to do some postgres dba
> magic to find the process that owns that transaction and kill it. We
> occasionally have this problem and sometimes it is because a user
> started a transaction (BEGIN) and never completed the transaction
> (COMMIT / ROLLBACK). The subscribe process needs to acquire locks on
> all the tables--even tables that are not part of the replication set.

Unfortunately, nothing is holding it up, as far as I can see, and
there are no warnings or errors in the log -- it's all debug. I am
running this on a development machine with no other clients, so there
is no chance that the wait is being sabotaged by concurrent writes.

Thanks for trying to help :-)

Alexander.