Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica. - Mailing list pgsql-bugs

From Jeff Janes
Subject Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.
Date
Msg-id CAMkU=1x748MTbhhALyr4xGJnk5duaqTuDriJicQfmW65pNSLPg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Maxim Boguk
Date:
Subject: Re: BUG #13657: Some kind of undetected deadlock between query and "startup process" on replica.
Next
From: James Coleman
Date:
Subject: Re: BUG #13659: Constraint names truncated without error