| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: recent deadlock regression test failures |
| Date: | 2017-04-10 18:17:22 |
| Message-ID: | 30775.1491848242@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 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.
Right, but do they record the master's PID rather than their own in
the SERIALIZABLEXACT data structure?
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Hernández Tortosa | 2017-04-10 18:28:27 | Re: Some thoughts about SCRAM implementation |
| Previous Message | Tom Lane | 2017-04-10 18:09:23 | Re: Compiler warning in costsize.c |