Re: [HACKERS] recent deadlock regression test failures

On Tue, Apr 11, 2017 at 5:45 AM, Kevin Grittner wrote: > On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote: >> Thomas Munro writes: >>> Here's a pair of draft patches for review: > > Thanks. > >> Pushed with cosmetic

Re: [HACKERS] recent deadlock regression test failures

Thomas Munro writes: > On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane wrote: >> Maybe it's impossible for a parallel worker to acquire its own >> snapshot at all, in which case this is moot. But I'm nervous. > Parallel workers can't acquire

Re: [HACKERS] recent deadlock regression test failures

On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane wrote: > Kevin Grittner writes: >> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote: >>> I notice that the safe-snapshot code path is not paying attention to >>> parallel-query cases, unlike the

Re: [HACKERS] recent deadlock regression test failures

On Mon, Apr 10, 2017 at 1:17 PM, Tom Lane wrote: > Kevin Grittner writes: >> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote: >>> I notice that the safe-snapshot code path is not paying attention to >>> parallel-query cases, unlike the

Re: [HACKERS] recent deadlock regression test failures

Kevin Grittner writes: > On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote: >> I notice that the safe-snapshot code path is not paying attention to >> parallel-query cases, unlike the lock code path. I'm not sure how >> big a deal that is... > Parallel

Re: [HACKERS] recent deadlock regression test failures

On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote: > Thomas Munro writes: >> Here's a pair of draft patches for review: Thanks. > Pushed with cosmetic improvements. Thanks. > I notice that the safe-snapshot code path is not paying attention to

Re: [HACKERS] recent deadlock regression test failures

Thomas Munro writes: > Here's a pair of draft patches for review: Pushed with cosmetic improvements. I notice that the safe-snapshot code path is not paying attention to parallel-query cases, unlike the lock code path. I'm not sure how big a deal that is...

Re: [HACKERS] recent deadlock regression test failures

Thomas Munro writes: > Here's a pair of draft patches for review: I'll look at these in detail tomorrow, but: > 2. pg-safe-snapshot-blocking-pids.patch, to provide an end-user > function wrapping GetSafeSnapshotBlockingPids(). Kevin expressed an > interest in

Re: [HACKERS] recent deadlock regression test failures

On Sun, Apr 9, 2017 at 11:49 PM, Thomas Munro wrote: > On Sun, Apr 9, 2017 at 12:33 PM, Tom Lane wrote: >> Kevin Grittner writes: >>> On Sat, Apr 8, 2017 at 12:56 PM, Tom Lane wrote: I'm imagining an

Re: [HACKERS] recent deadlock regression test failures

On Sun, Apr 9, 2017 at 12:33 PM, Tom Lane wrote: > Kevin Grittner writes: >> On Sat, Apr 8, 2017 at 12:56 PM, Tom Lane wrote: >>> I'm imagining an API like >>> isolation_test_is_waiting_for(int, int[]) returns bool > >> Good

Re: [HACKERS] recent deadlock regression test failures

On Sat, Apr 8, 2017 at 12:56 PM, Tom Lane wrote: > Thomas Munro writes: >> On Sat, Apr 8, 2017 at 4:22 PM, Tom Lane wrote: >> Based on the above, here is a version that introduces a simple boolean >> function

Re: [HACKERS] recent deadlock regression test failures

Kevin Grittner writes: > On Sat, Apr 8, 2017 at 12:56 PM, Tom Lane wrote: >> I'm imagining an API like >> isolation_test_is_waiting_for(int, int[]) returns bool > Good suggestion. > Thomas, would you like to produce a patch along these lines, or >

Re: [HACKERS] recent deadlock regression test failures

... BTW, one other minor coding suggestion for GetSafeSnapshotBlockingPids(): it might be better to avoid doing so much palloc work while holding the SerializableXactHashLock. Even if it's only held shared, I imagine that it's a contention bottleneck. You could avoid that by returning an array

Re: [HACKERS] recent deadlock regression test failures

Thomas Munro writes: > On Sat, Apr 8, 2017 at 4:22 PM, Tom Lane wrote: >> It seems an entirely principle-free change in the function's definition. > You might say that pg_blocking_pid() is about locking only and not > arbitrary other kinds of

Re: [HACKERS] recent deadlock regression test failures

On Sat, Apr 8, 2017 at 4:22 PM, Tom Lane wrote: > Thomas Munro writes: >> Here is an attempt at option 2 from the menu I posted above. Questions: > >> 1. Does anyone object to this extension of pg_blocking_pids()'s >> remit? If so, I could

Re: [HACKERS] recent deadlock regression test failures

Thomas Munro writes: > Here is an attempt at option 2 from the menu I posted above. Questions: > 1. Does anyone object to this extension of pg_blocking_pids()'s > remit? If so, I could make it a separate function (that was option > 3). It seems an entirely

Re: [HACKERS] recent deadlock regression test failures

On Fri, Apr 7, 2017 at 9:24 PM, Thomas Munro wrote: > 2. Did I understand correctly that it is safe to scan the list of > SERIALIZABLEXACTs and access the possibleUnsafeConflicts list while > holding only SerializableXactHashLock, Yes. > and that 'inLink' is the

Re: [HACKERS] recent deadlock regression test failures

On Sat, Apr 8, 2017 at 9:47 AM, Kevin Grittner wrote: > On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro > wrote: >> On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner wrote: >>> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund

Re: [HACKERS] recent deadlock regression test failures

On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro wrote: > On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner wrote: >> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund wrote: >> >>> I'd rather fix the issue, than remove the tests

Re: [HACKERS] recent deadlock regression test failures

On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner wrote: > On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund wrote: > >> I'd rather fix the issue, than remove the tests entirely. Seems quite >> possible to handle blocking on Safesnapshot in a similar manner as

Re: [HACKERS] recent deadlock regression test failures

On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund wrote: > I'd rather fix the issue, than remove the tests entirely. Seems quite > possible to handle blocking on Safesnapshot in a similar manner as > pg_blocking_pids? I'll see what I can figure out. -- Kevin Grittner --

Re: [HACKERS] recent deadlock regression test failures

On 2017-04-07 12:49:22 -0500, Kevin Grittner wrote: > On Fri, Apr 7, 2017 at 12:28 PM, Tom Lane wrote: > > Andrew Dunstan writes: > >> On 04/07/2017 12:57 PM, Andres Freund wrote: > >>> I don't think any recent changes are supposed to affect

Re: [HACKERS] recent deadlock regression test failures

On Fri, Apr 7, 2017 at 12:28 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 04/07/2017 12:57 PM, Andres Freund wrote: >>> I don't think any recent changes are supposed to affect deadlock >>> detector behaviour? > >> Both these machines have

Re: [HACKERS] recent deadlock regression test failures

Andrew Dunstan writes: > On 04/07/2017 12:57 PM, Andres Freund wrote: >> I don't think any recent changes are supposed to affect deadlock >> detector behaviour? > Both these machines have CLOBBER_CACHE_ALWAYS set. And on both machines > recent changes have made

Re: [HACKERS] recent deadlock regression test failures

On 04/07/2017 12:57 PM, Andres Freund wrote: > Hi, > > There's two machines that recently report changes in deadlock detector > output: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax=2017-04-05%2018%3A58%3A04 >

[HACKERS] recent deadlock regression test failures

Hi, There's two machines that recently report changes in deadlock detector output: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax=2017-04-05%2018%3A58%3A04 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=friarbird=2017-04-07%2004%3A20%3A01 both just failed twice in a row: