On 27/05/17 15:44, Petr Jelinek wrote: > 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. >
Actually, I guess it's the pid 47457 (COPY process) who is actually running the xid 73322726. In that case that's the same thing Masahiko Sawada reported [1]. Which basically is result of snapshot builder waiting for transaction to finish, that's normal if there is a long transaction running when the snapshot is being created (and the COPY is a long transaction). [1] https://www.postgresql.org/message-id/flat/CAD21AoC2KJdavS7MFffmSsRc1dn3Vg_0xmuc%3DUpBrZ-_MUxh-Q%40mail.gmail.com -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
