Gordon Shannon wrote:
> 
> I am running Slony 2.0.2 replicating tables from an 8.3 cluster to an 8.4. 
> The following scenarios has happened consistently:
> 
> 1. Issue SUBSCRIBE SET
> 2. Slon log on receiver goes into loop due to "transactions earlier than
> XID nnnnnnn are still in progress".
> 3. A few minutes later, the long query on the provider node is finished.
> 4. Slon on receiver now tries to copy the set, but gets 
>    "ERROR remoteWorkerThread_7: Could not lock table "public"."abc" on
> subscriber"  where abc is the 1st table in the set.
> 
> It will loop like this indefinitely, until I bounce slon, then it works.
> Also, at the same time that error happens in the slon log, I see this in
> the Postgres log on the receiver:
>   LOCK TABLE can only be used in transaction blocks.
>   Statement: lock table "public"."abc"
> 
> This is very consistent.  It's not a show stopper, just annoying.  I don't
> remember this in 2.0.1.
> 

Here's what I think is happening.  I think Slony is attempting to lock the
table outside a transaction. Here's why.

In Postgres 8.3, if you lock a table outside a transaction, it silently does
nothing. This explains the message I always see against 8.3 in this
situation: "NOTICE:  there is no transaction in progress", and it continues
on.

In 8.4, however, Postgres throws an error, as explained above.

All of the messages I'm seeing consistently would be explained if this
theory is correct. :-)



-- 
View this message in context: http://www.nabble.com/%22Could-not-lock-table%22-errors-from-slony-tp24521158p24632675.html
Sent from the Slony-I -- General mailing list archive at Nabble.com.