Re: Subtle bug in clog.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Subtle bug in clog.c
Date: 2004-07-03 00:33:31
Message-ID: 4035.1088814811@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> I'm wondering about the following statement in TransactionIdSetStatus():
> *byteptr |= (status << bshift);

> When the status is SUBCOMMITTED, the bytemask will have 11 for those two
> bytes; therefore, when OR-ing a 10 or 01 mask (committed or aborted),

Um. That code is assuming that the initial state was either 00 or the
target value (per the former state of the Assert above it). You're
right, we need to change that.

At one time this behavior was important because there wasn't
synchronization between writers and readers of clog; so transformations
could only set bits and not clear them. That doesn't matter anymore
though, because there are page-level locks taken in clog.c.

> I wonder why this works.

It doesn't --- the state remains SUBCOMMITTED.

> My theory is that the current code is a no-op and that it works because
> the server recurses up the subtrans tree to find the parent state ...

Right.

I'm off to dinner but will commit a fix for this when I return.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeroen T. Vermeulen 2004-07-03 01:43:10 Re: [Re] Re: PREPARE and transactions
Previous Message Oliver Jowett 2004-07-03 00:16:50 Re: [Re] Re: PREPARE and transactions