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 improvements.
>
> Thanks.
Thanks Tom and Kevin.
After this commit hyrax ran the
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 snapshots, and SERIALIZABLE disables
> all parallel query p
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 lock code path. I'm not sure how
>>> big a deal that is...
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 lock code path. I'm not sure how
>>> big a deal that is...
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 workers in serializable transactions should
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
> parallel-query cases, unlike the lock code path.
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...
regards, tom
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 that functionality, and it does se
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 API like
isolation_test_is_waiting_for(int, int[]) returns bool
>>
>>> Good sugg
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 suggestion.
>
>> Thomas, would you like to produce a patch along t
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 pg_waiting_for_safe_snapshot(pid) and adds that the the
>> query. This was my "option
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
> should I?
I'll be happy to review/push if
... 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 ra
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 waits, but safe snapshots are not completely
> unrela
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 make it a separate function (that was option
>> 3).
>
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 principle-free change in the functio
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 correct link to be following?
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 wrote:
>>>
I'd rather fix the issue, than remove the tests entirely. Se
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 entirely. Seems quite
>>> possible to handle blocking on Safesnapshot in a
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
>> pg_blocking_pids?
>
> I'll see what I
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
--
Sent via pgsql-hacker
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 deadlock
> >>> detector behaviour?
> >
> >> Both these
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 CLOBBER_CACHE_ALWAYS set. And on both machines
>> re
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 the isolation tests run much much l
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&dt=2017-04-05%2018%3A58%3A04
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=friarbird&
Hi,
There's two machines that recently report changes in deadlock detector
output:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hyrax&dt=2017-04-05%2018%3A58%3A04
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=friarbird&dt=2017-04-07%2004%3A20%3A01
both just failed twice in a
26 matches
Mail list logo