Re: Test of PG7.3.2b2 on SGI Irix

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bruc(at)acm(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Test of PG7.3.2b2 on SGI Irix
Date: 2002-10-31 21:50:02
Message-ID: 19278.1036101002@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Robert E. Bruccoleri" <bruc(at)stone(dot)congenomics(dot)com> writes:
>> No, the code is correct, although no doubt too clever by half :-(

> How can it be correct? If the assertion checking is turned off, then
> saveState.currBucket will not be changed, but if assertion checking is
> on, it will be set to NULL. The only way that it would make no
> difference would be if the saveState.currBucket were NULL to begin
> with, but then, why make the assignment?

If assertion checking is off (and the code is otherwise correct) then
there's no need to reset saveState.currBucket to NULL, or so at least
I interpret the author's intent. Notice that an == test would be
completely redundant with the first part of the Assert, since the
local currBucket was just assigned from saveState.currBucket. What
is really being accomplished here is equivalent to
Assert(currBucket);
#ifdef USE_ASSERT_CHECKING
saveState.currBucket = NULL;
#endif

However, it's a tad silly to confuse readers this much in order to save
one lousy store instruction, so I'm inclined to change it to
Assert(currBucket);
saveState.currBucket = NULL;
IIRC, you're not the first to look at that code and think it's wrong.

>>> All the regression tests pass except for tests involving Savings Time
>>> which are off by one hour. --Bob
>>
>> Details? If you ran it today then the DST-boundary problems shouldn't
>> be there anymore.

> Here are the diffs:

It looks like your files match the solaris-1947 variants; would you
confirm that? If so, please send a patch with a resultmap addition
that matches your platform. There is already an entry

horology/.*-irix6=horology-no-DST-before-1970

but it looks like that's not triggering on your system.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-10-31 22:07:28 Re: pg_dump and large files - is this a problem?
Previous Message Jason Tishler 2002-10-31 21:33:57 Re: ipc-daemon