From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: Assertion failure on hot standby |
Date: | 2010-11-26 12:41:58 |
Message-ID: | 201011261341.59331.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2010-11-26 13:48:39 | Re: improving foreign key locks |
Previous Message | Robert Haas | 2010-11-26 12:32:18 | Re: Assertion failure on hot standby |