Обсуждение: Bogus assertion in multixact.c?

Поиск
Список
Период
Сортировка

Bogus assertion in multixact.c?

От
Heikki Linnakangas
Дата:
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
       Assert(!TransactionIdEquals(multi, xid));

where multi is a MultiXactId and xid is a TransactionId.

Isn't this bogus? If I understand the code correctly, multixactids and 
regular xids live in completely separate id spaces. Therefore a comparison 
between them makes no sense.

- Heikki


Re: Bogus assertion in multixact.c?

От
Tom Lane
Дата:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
>         Assert(!TransactionIdEquals(multi, xid));

> where multi is a MultiXactId and xid is a TransactionId.

> Isn't this bogus?

No.  Note the comment immediately above, as well as the header comment
for the function.
        regards, tom lane


Re: Bogus assertion in multixact.c?

От
Alvaro Herrera
Дата:
On Tue, May 03, 2005 at 09:33:30PM +0300, Heikki Linnakangas wrote:
> There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
> 
>        Assert(!TransactionIdEquals(multi, xid));
> 
> where multi is a MultiXactId and xid is a TransactionId.
> 
> Isn't this bogus? If I understand the code correctly, multixactids and 
> regular xids live in completely separate id spaces. Therefore a comparison 
> between them makes no sense.

Well :-)  actually that particular MultiXactId may be a TransactionId.
(See the isMulti param, and comments at the beggining of the function.)
This ugliness is there to support the notion of locking a tuple with
either a TransactionId (non-contention case) or a MultiXactId
(concurrent case.)

We require MultiXactId to be equivalent to TransactionId anyway, because
we store Multis on a tuple's Xmax.

Congratulations for spotting that :-)  (Are you using a source checker
tool?)

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"No hay cielo posible sin hundir nuestras raícesen la profundidad de la tierra"                        (Malucha Pinto)


Re: Bogus assertion in multixact.c?

От
Tom Lane
Дата:
I wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> Isn't this bogus?

> No.  Note the comment immediately above, as well as the header comment
> for the function.

OTOH, now that I think about it there's no reason whatever for that
bizarre call convention.  Let's split the function into two: one to
expand an existing multixact, and one to make a multixact from two
regular xids.
        regards, tom lane


Re: Bogus assertion in multixact.c?

От
Alvaro Herrera
Дата:
On Tue, May 03, 2005 at 02:48:20PM -0400, Tom Lane wrote:
> I wrote:
> > Heikki Linnakangas <hlinnaka@iki.fi> writes:
> >> Isn't this bogus?
> 
> > No.  Note the comment immediately above, as well as the header comment
> > for the function.
> 
> OTOH, now that I think about it there's no reason whatever for that
> bizarre call convention.  Let's split the function into two: one to
> expand an existing multixact, and one to make a multixact from two
> regular xids.

No problem ... shall I write a patch, or did you do it already?

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"No es bueno caminar con un hombre muerto"


Re: Bogus assertion in multixact.c?

От
Tom Lane
Дата:
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> No problem ... shall I write a patch, or did you do it already?

I'll take care of it --- wouldn't take much longer than applying
someone else's patch anyway ...
        regards, tom lane


Re: Bogus assertion in multixact.c?

От
Heikki Linnakangas
Дата:
Never mind. multi is in effect a TransactionId in that code path, and thus 
the assertion makes sense. Sorry for the noise.

On Tue, 3 May 2005, Heikki Linnakangas wrote:

> There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
>
>       Assert(!TransactionIdEquals(multi, xid));
>
> where multi is a MultiXactId and xid is a TransactionId.
>
> Isn't this bogus? If I understand the code correctly, multixactids and 
> regular xids live in completely separate id spaces. Therefore a comparison 
> between them makes no sense.
>
> - Heikki
>

- Heikki