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

On 2015-01-27 19:24:24 -0500, Robert Haas wrote:
> On Tue, Jan 27, 2015 at 2:16 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > That'd end up essentially being a re-emulation of locks. Don't find that
> > all that pretty. But maybe we have to go there.
>
> The advantage of it is that it is simple. The only thing we're really
> giving up is the deadlock detector, which I think isn't needed in this
> case.

I think it's more than just the deadlock detector. Consider
pg_locks/pg_stat_activity.waiting, cancelling a acquisition, error
cleanup and recursive acquisitions. Acquiring session locks + a
surrounding transaction command deals with with cleanups without
introducing PG_ENSURE blocks in a couple places. And we need recursive
acquisition so a streaming base backup can acquire the lock over the
whole runtime, while a manual pg_start_backup() does only for its own
time.

Especially the visibility in the system views is something I'd not like
to give up in additional blocks we introduce in the backbranches.

> > 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.
>
> I tend think this is changing too many things to back-patch. It might
> all be fine, but it's pretty wide-reaching, so the chances of
> collateral damage seem non-trivial. Even in master, I'm not sure I
> see the point in rocking the apple cart to this degree.

It's big, true. But a fair amount of it stuff I think we have to do
anyway. The current code acquiring session locks in dbase_redo() is
borked - we either assert or segfault if there's a connection in the
wrong moment beause there's no deadlock handler. Plus it has races that
aren't that hard to hit :(. To fix the crashes (but not the race) we can
have a separate ResolveRecoveryConflictWithObjectLock that doesn't
record the existance of the lock, but doesn't ever do a ProcSleep(). Not
pretty either :(

Seems like a situation with no nice solutions so far :(

Greetings,

Andres Freund

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