Re: [HACKERS] Early locking option to parallel backup

2018-03-02 Thread Andres Freund
On 2018-03-02 11:42:06 -0500, Robert Haas wrote: > On Fri, Mar 2, 2018 at 2:29 AM, Andres Freund wrote: > > 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.

Re: [HACKERS] Early locking option to parallel backup

2018-03-02 Thread Robert Haas
On Fri, Mar 2, 2018 at 2:29 AM, Andres Freund wrote: > 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

Re: [HACKERS] Early locking option to parallel backup

2018-03-01 Thread Andres Freund
On 2018-01-15 12:12:26 -0500, Robert Haas wrote: > On Thu, Jan 11, 2018 at 9:02 AM, Stephen Frost 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

Re: [HACKERS] Early locking option to parallel backup

2018-01-15 Thread Robert Haas
On Thu, Jan 11, 2018 at 9:02 AM, Stephen Frost 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

Re: [HACKERS] Early locking option to parallel backup

2018-01-11 Thread Stephen Frost
Lucas, Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Nov 6, 2017 at 4:43 AM, Tom Lane wrote: > > I wonder if we couldn't somehow repurpose the work that was done for > > parallel workers' locks. Lots of security-type issues to be handled > > if we're to