Re: Assertion failure on hot standby

On 26.11.2010 17:28, Robert Haas wrote:
> On Fri, Nov 26, 2010 at 7:41 AM, Andres Freund<andres(at)anarazel(dot)de> wrote:
>> On Friday 26 November 2010 13:32:18 Robert Haas wrote:
>>> On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Simon Riggs<simon(at)2ndQuadrant(dot)com> writes:
>>>>> That would mean running GetCurrentTransactionId() inside LockAcquire()
>>>>>
>>>>> if (lockmode>= AccessExclusiveLock&&
>>>>> locktag->locktag_type == LOCKTAG_RELATION&&
>>>>> !RecoveryInProgress())
>>>>> (void) GetCurrentTransactionId();
>>>>>
>>>>> Any objections to that fix?
>>>>
>>>> Could we have a wal level test in there too please? It's pretty awful
>>>> in any case...
>>> Incidentally, I haven't been able to wrap my head around why we need
>>> to propagate AccessExclusiveLocks to the standby in the first place.
>>> Can someone explain?
>> To make the standby stop applying WAL when a local transaction on the standby
>> uses an object.
>> E.g. dropping a table on the master need the standby top stop applying wal (or
>> kill the local client using the table).
>> How would you want to protect against something like that otherwise?
>
> Hmm. But it seems like that it would be enough to log any exclusive
> locks held at commit time, rather than logging them as they're
> acquired. By then, the XID will be assigned (if you need it - if you
> don't then you probably don't need to XLOG it anyway) and you avoid
> holding the lock for more than a moment on the standby.
>
> But it seems like an even better idea would be to actually XLOG the
> operations that are problematic specifically. Because, for example,
> if a user session on the master does LOCK TABLE ... IN ACCESS
> EXCLUSIVE MODE, AFAICS there's no reason for the standby to care. Or
> am I confused?

Let's approach this from a different direction:

If you have operation A in the master that currently acquires an
AccessExclusiveLock on a table, do you think it's safe for another
transaction to peek at the table at the same time? Say, run a heap scan
simultaneously. If yes, why did you take an AccessExclusiveLock in the
first place. If not, then surely it's not safe to have a heap scan
running against the table in the standby either. The read-only query in
the standby sees the same actions as a read-only query on the master
would see.

You can only take AccessShareLocks on the standby, and the only locks
that conflict with an AccessShareLock is the AccessExclusiveLock. (Hmm,
looking at the code, we also allow RowShareLock and RowExclusiveLock in
the standby. You can't actually insert/update/delete tuples or set xmax
as SELECT FOR SHARE does on standby, though, so why do we allow that? )

As a concrete example, VACUUM acquires an AccessExclusiveLock when it
wants to truncate the relation. A sequential scan running against the
table in the standby will get upset, if the startup process replays a
truncation record on the table without warning.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com