From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby: subxid cache changes |
Date: | 2009-02-13 08:14:27 |
Message-ID: | 1234512867.4500.1052.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2009-02-12 at 14:23 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-12 at 09:50 +0200, Heikki Linnakangas wrote:
> >> So far so good, but what about all the other callers of
> >> SubTransGetParent()? For example, XactLockTableWait will fail an
> >> assertion if asked to wait on a subtransaction which is then released.
> >
> > I agree that it could fail the assertion, though it is clear that the
> > assertion should now be removed.
>
> No, then you just get an infinite loop instead, trying to get the parent
> of 0 over and over again.
There is no infinite loop. Try it, or read TransactionIdIsInProgress().
> > The logic is: if there is no lock table entry for that xid *and* it is
> > not in progress *and* it is not in pg_subtrans, then it must have been
> > an aborted subtransaction of a currently active xact or it has otherwise
> > completed.
>
> Right, we got it right that far. But after the subtransaction has
> completed, the question is: what's its parent? That's what the patch got
> wrong.
We can find that out from procarray, since a subcommitted xid will still
be present in the subxid cache of its parent (by definition, otherwise
it will be marked in pg_subtrans).
It will be quicker to fix that than to make other changes.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | John Lister | 2009-02-13 08:20:03 | Database corruption help |
Previous Message | ITAGAKI Takahiro | 2009-02-13 01:57:25 | Re: fillfactor for toast tables is useless? |