Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane <tgl@sss.pgh.pa.us> 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 planning anyway.
> I did some early stage POC hacking to lift that restriction[1], and if
> we finish up doing it at all like that then all SERIALIZABLEXACT
> structures would be associated with leader processes and
> pg_safe_snapshot_blocking_pid() would automatically deal only in
> leader PIDs as arguments and results so there would be no problem
> here. The interlocking I proposed in that WIP patch may need work, to
> be discussed, but I'm fairly sure that sharing the leader's
> SERIALIZABLEXACT like that is the only sensible way forward.
OK, sounds good. I agree that it would only be sensible for a parallel
worker to be using a snapshot already acquired by the master, so far
as the parallelized query itself is concerned. What was worrying me
is snapshots acquired by, eg, volatile PL functions called by the query.
But on second thought, in SERIALIZABLE mode no such function would be
taking an actual new snapshot anyhow --- they'd just continue to use
the transaction snap.
regards, tom lane
