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