Re: [HACKERS] Early locking option to parallel backup

On 2018-01-15 12:12:26 -0500, Robert Haas wrote:
> On Thu, Jan 11, 2018 at 9:02 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Parallel pg_dump is based on synchronized transactions though and we
> > have a bunch of checks in ImportSnapshot() because a pg_dump parallel
> > worker also can't really be quite the same as a normal backend. Perhaps
> > we could add on more restrictions in ImportSnapshot() to match the
> > restrictions for parallel-mode workers? If we think there's other users
> > of SET TRANSACTION SNAPSHOT then we might need to extend that command
> > for this case, but that seems relatively straight-forward. I don't know
> > how reasonable the idea of taking a normally-started backend and making
> > it close enough to a parallel worker when a SET TRANSACTION SNAPSHOT
> > PARALLEL (or whatever) happens to allow it to skip the lock fairness is
> > though.
>
> It seems pretty tricky to me. I actually don't think this use case
> has all that much in common with the parallel query case. Both can be
> addressed by tweaking the lock manager, but I think this needs a
> different set of tweaks than that did.

There seems to to be consensus in this thread that the approach Lucas
proposed isn't what we want, and that instead some shared lock based
approach is desirable. As that has been the case for ~1.5 months, I
propose we mark this as returned with feedback?

Greetings,

Andres Freund