Re: [HACKERS] SERIALIZABLE with parallel query - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: [HACKERS] SERIALIZABLE with parallel query
Date
Msg-id CAJrrPGeMxjUe301gHQJpdW1T5mLAH7w2+TkDccK5qoUMfU_4Bw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SERIALIZABLE with parallel query  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: [HACKERS] SERIALIZABLE with parallel query  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Sep 26, 2017 at 4:41 PM, Haribabu Kommi wrote: > > > On Mon, Sep 25, 2017 at 6:57 PM, Thomas Munro < > thomas.munro@enterprisedb.com> wrote: > >> On Mon, Sep 25, 2017 at 8:37 PM, Haribabu Kommi >> wrote: >> > After I tune the GUC to go with sequence scan, still I am not getting >> the >> > error >> > in the session-2 for update operation like it used to generate an error >> for >> > parallel >> > sequential scan, and also it even takes some many commands until unless >> the >> > S1 >> > commits. >> >> Hmm. Then this requires more explanation because I don't expect a >> difference. I did some digging and realised that the error detail >> message "Reason code: Canceled on identification as a pivot, during >> write." was reached in a code path that requires >> SxactIsPrepared(writer) and also MySerializableXact == writer, which >> means that the process believes it is committing. Clearly something >> is wrong. After some more digging I realised that >> ParallelWorkerMain() calls EndParallelWorkerTransaction() which calls >> CommitTransaction() which calls >> PreCommit_CheckForSerializationFailure(). Since the worker is >> connected to the leader's SERIALIZABLEXACT, that finishes up being >> marked as preparing to commit (not true!), and then the leader get >> confused during that write, causing a serialization failure to be >> raised sooner (though I can't explain why it should be raised then >> anyway, but that's another topic). Oops. I think the fix here is >> just not to do that in a worker (the worker's CommitTransaction() >> doesn't really mean what it says). >> >> Here's a version with a change that makes that conditional. This way >> your test case behaves the same as non-parallel mode. >> > > The patch looks good, and I don't have any comments for the code. > The test that is going to add by the patch is not generating a true > parallelism scenario, I feel it is better to change the test that can > generate a parallel sequence/index/bitmap scan. > The latest patch is good. It lacks a test that verifies the serialize support with actual parallel workers, so in case if it broken, it is difficult to know. Regards, Hari Babu Fujitsu Australia

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] HASH_CHUNK_SIZE vs malloc rounding
Next
From: atorikoshi
Date:
Subject: Re: Failed to delete old ReorderBuffer spilled files