On 2015-01-26 22:03:03 +0100, Andres Freund wrote:
> Attached is a patch trying to this. Doesn't look too bad and lead me to
> discover missing recovery conflicts during a AD ST.
>
> But: It doesn't actually work on standbys, because lock.c prevents any
> stronger lock than RowExclusive from being acquired. And we need need a
> lock that can conflict with WAL replay of DBASE_CREATE, to handle base
> backups that are executed on the primary. Those obviously can't detect
> whether any standby is currently doing a base backup...
>
> I currently don't have a good idea how to mangle lock.c to allow
> this. I've played with doing it like in the second patch, but that
> doesn't actually work because of some asserts around ProcSleep - leading
> to locks on database objects not working in the startup process (despite
> already being used).
>
> The easiest thing would be to just use a lwlock instead of a heavyweight
> lock - but those aren't canceleable...
As Stephen noticed on irc I forgot to attach those. Caused by the
generic HS issue mentioned in 20150126212458.GA29457@awork2.anarazel.de.
Attached now.
As mentioned above, this isn't really isn't ready (e.g. it'll Assert() on a
standby due to the HS issue).
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
