Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.
От | Jeff Janes |
---|---|
Тема | Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica. |
Дата | |
Msg-id | CAMkU=1x748MTbhhALyr4xGJnk5duaqTuDriJicQfmW65pNSLPg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica. (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #13657: Some kind of undetected deadlock between query
and "startup process" on replica.
|
Список | pgsql-bugs |
On Thu, Oct 1, 2015 at 9:48 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > > > On Thu, Oct 1, 2015 at 9:52 PM, Maxim Boguk <maxim.boguk@gmail.com> wrote: > >> So wal replay got AccessExclusiveLock on relation 17987 and waiting for > >> something. > >> And query waiting for AccessShareLock on the same relation. > >> > > gdb backtrace from stuck startup process: > > (gdb) bt > > #0 0x00007f04ad862633 in select () from /lib/x86_64-linux-gnu/libc.so.6 > > #1 0x00007f04af86488e in pg_usleep (microsec=<optimized out>) at > > /tmp/buildd/postgresql-9.4-9.4.4/build/../src/port/pgsleep.c:53 > > #2 0x00007f04af7328ac in WaitExceedsMaxStandbyDelay () at > > > /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/storage/ipc/standby.c:171 > > #3 ResolveRecoveryConflictWithVirtualXIDs > > (reason=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, waitlist=0x7f04b13ba2f0) at > > > /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/storage/ipc/standby.c:232 > > #4 ResolveRecoveryConflictWithVirtualXIDs (waitlist=0x7f04b13ba2f0, > > reason=PROCSIG_RECOVERY_CONFLICT_SNAPSHOT) at > > > /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/storage/ipc/standby.c:191 > > #5 0x00007f04af544445 in heap_xlog_clean (record=0x7f04b1395b80, > > lsn=107351881751648) at > > > /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/access/heap/heapam.c:7329 > > This backtrace is not indicating that this process is waiting on a > relation lock, it is resolving a recovery conflict while removing tuples, > killing the virtual transaction depending on if max_standby_streaming_delay > or max_standby_archive_delay are set if the conflict gets longer. Did you > change the default of those parameters, which is 30s, to -1? This would > mean that the standby waits indefinitely. > While setting it to -1 gives the startup process permission to wait indefinitely for another back-end which is doing something, I don't think that that means it should have permission to deadlock indefinitely. A deadlock is a different kind of thing that "someone started a transaction and then left on vacation for a month without closing it" Cheers, Jeff
В списке pgsql-bugs по дате отправления: