Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?

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. +