Re: [HACKERS] logical replication busy-waiting on a lock - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] logical replication busy-waiting on a lock
Date
Msg-id f2e68406-3e8a-1ddf-1a6c-e1a96a5165bf@2ndquadrant.com
Whole thread Raw
In response to [HACKERS] logical replication busy-waiting on a lock  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [HACKERS] logical replication busy-waiting on a lock  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On 27/05/17 01:25, Jeff Janes wrote:
> When I create a subscription in the disabled state, and then later doing
> "alter subscription sub enable;", on the master I sometimes get a tight
> loop of the deadlock detector:
> 
> (log_lock_waits is on, of course)
> 
> deadlock_timeout is set to 1s, so I don't know why it seems to be
> running several times per millisecond.
> 
> .....
> 
> And so on out to "after 9616.814", when it finally acquires the lock.
> 
> The other process, 47457, is doing the initial COPY of another table as
> part of the same publisher/subscriber set.
> 

We lock wait for running transactions in snapshot builder while the
snapshot is being built so I guess that's what you are seeing. I am not
quite sure why the snapshot builder would hold the xid lock for
prolonged period of time though, the XactLockTableWait releases the lock
immediately after acquiring it. In fact AFAICS everything that acquires
ShareLock on xid releases it immediately after acquiring as it's only
used for waits.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] ALTER SUBSCRIPTION ..SET PUBLICATION refreshis not throwing error.
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] logical replication busy-waiting on a lock