On Fri, Jan 30, 2015 at 09:36:42PM +0100, Andres Freund wrote:
> On 2015-01-27 20:16:43 +0100, Andres Freund wrote:
> > Here's an alternative approach. I think it generally is superior and
> > going in the right direction, but I'm not sure it's backpatchable.
> >
> > It basically consists out of:
> > 1) Make GetLockConflicts() actually work.
>
> already commited as being a independent problem.
>
> > 2) Allow the startup process to actually acquire locks other than
> > AccessExclusiveLocks. There already is code acquiring other locks,
> > but it's currently broken because they're acquired in blocking mode
> > which isn't actually supported in the startup mode. Using this
> > infrastructure we can actually fix a couple small races around
> > database creation/drop.
> > 3) Allow session locks during recovery to be heavier than
> > RowExclusiveLock - since relation/object session locks aren't ever
> > taken out by the user (without a plain lock first) that's safe.
>
> merged and submitted independently.
>
> > 5) Make walsender actually react to recovery conflict interrupts
>
> submitted here. (0003)
>
> > 4) Perform streaming base backups from within a transaction command, to
> > provide error handling.
> > 6) Prevent access to the template database of a CREATE DATABASE during
> > WAL replay.
> > 7) Add an interlock to prevent base backups and movedb() to run
> > concurrently. What we actually came here for.
>
> combined, submitted here. (0004)
>
> I think this actually doesn't look that bad.
Where are we on this?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +