Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe? - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?
Date
Msg-id 20150428045654.GA15975@toroid.org
Whole thread Raw
In response to Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?
List pgsql-hackers
At 2015-01-30 21:36:42 +0100, andres@2ndquadrant.com 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.

Hi Andres. Do you intend to commit these patches? (I just verified that
they apply without trouble to HEAD.)

-- Abhijit



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Next
From: Alvaro Herrera
Date:
Subject: Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property?