Re: int8 sequences --- small implementation problem - Mailing list pgsql-hackers

From Serguei Mokhov
Subject Re: int8 sequences --- small implementation problem
Date
Msg-id 00ff01c124db$b9cc5b60$5dd9fea9@gunn
Whole thread Raw
In response to Re: Surviving transaction-ID wraparound, take 2  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
----- Original Message ----- 
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Tuesday, August 14, 2001 11:28 AM


> "Serguei Mokhov" <sa_mokho@alcor.concordia.ca> writes:
> >> This would work, I think, but my goodness it's an ugly solution.
> 
> > Is anything wrong with just having two int32 per value for this case?
> 
> Well, we do want it to be int64 on machines where int64 is properly
> defined.  Or are you suggesting
> 
> #ifdef INT64_IS_BUSTED
> int32 last_value;
> int32 pad1;
> #else
> int64 last_value;
> #endif
> 
> That does seem marginally more robust, now that you mention it...

Yes, this version is more robust, but you till have to cope with all
those #ifdef INT64_IS_BUSTED #else #endif. I guess if you want explicitly
int64 type in here for those platforms that do support it, then there is no
other way maybe. What I was thinking (for this particular struct only!) is just jave padded
int32's for every value, which will always be correct and no marginal problems.
And the accessor functions using the struct just employ int64 whatever it means.

S.






pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: OID unsigned long long
Next
From: Tom Lane
Date:
Subject: Re: Help with Vacuum Failure