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

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.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services