At 2015-01-30 21:36:42 +0100, and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers