Re: [HACKERS] recent deadlock regression test failures - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [HACKERS] recent deadlock regression test failures
Date
Msg-id CACjxUsOg5gDViLZSwjMqfW0bi+OfXc3-q2N5ZeyxQZ6beR==8Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] recent deadlock regression test failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] recent deadlock regression test failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] recent deadlock regression test failures  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> 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.  I'm not sure how
> big a deal that is...

Parallel workers in serializable transactions should be using the
transaction number of the "master" process to take any predicate
locks, and if parallel workers are doing any DML work against
tuples, that should be using the master transaction number for
xmin/xmax and serialization failure testing.  If either of those
rules are being violated, parallel processing should probably be
disabled within a serializable transaction.  I don't think
safe-snapshot processing needs to do anything special if the above
rules are followed, nor can I see anything special it *could* do.

--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] logical replication and SIGHUP
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] Variable substitution in psql backtick expansion