Re: Assertion failure on hot standby

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think it's not only useless from a performance standpoint, but
>> probably actually dangerous, to not take AccessExclusiveLock on the
>> standby when it's taken on the master.

> As far as I can see, that's complete nonsense. Deadlocks between what
> and what?

master locks table A, then table B. Some transaction on the standby
locks table A, then table B (perhaps only with AccessShareLock).
This will work reliably only as long as we don't change the order in
which replay acquires locks.

Now, if the standby process takes its locks in the other order, then
it's at risk anyway. But coding that works reliably against the master
should not randomly fail on the slave.

> In fact, now that I think about it, what I'm proposing would actually
> substantially REDUCE the risk of deadlock on the standby, because the
> master would only ever need to lock a backing file long enough to drop
> or truncate it, whereas under the present system the startup process
> might need to hold many locks at once.

Now you're the one spouting nonsense. Consider a master transaction
that does

begin;
lock table foo;
alter table foo --- some rewriting table operation;
alter table foo --- some rewriting table operation;
alter table foo --- some rewriting table operation;
alter table foo --- some rewriting table operation;
alter table foo --- some rewriting table operation;
alter table foo --- some rewriting table operation;
alter table foo --- some rewriting table operation;
commit;

On the master, no other transaction can see the intermediate states.
We don't want that property to disappear on the slave.

regards, tom lane