Re: Usage of epoch in txid_current

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Usage of epoch in txid_current
Date: 2018-07-10 01:20:52
Message-ID: CAEepm=2atCqhfS=uvYjr=Q_tykoqGd2G+o80G0fRM29QMfF0iw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 10, 2018 at 12:08 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2018-07-09 19:56:25 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>> > On 2018-07-10 11:35:59 +1200, Thomas Munro wrote:
>> >> I think it's probably a good idea to make it very explicit when moving
>> >> between big and small transaction IDs, hence the including of the word
>> >> 'big' in variable and function names and the use of a function-like
>> >> macro (rather than implicit conversion, which C doesn't give me a good
>> >> way to prevent). Otherwise there is a class of bug that is hidden for
>> >> the first 2^32 transactions.
>>
>> > You could have BigTransactionId (maybe renamed to FullTransactionId?) be
>> > a struct type. That'd prevent such issues. Most compilers these days
>> > should be more than good enough to optimize passing around an 8byte
>> > struct by value...
>>
>> Or, perhaps, use a struct in assert builds and int64 otherwise?
>> You could hide the ensuing notational differences in macros.
>
> That should be doable. But I'd like to check if it's necessary
> first. Optimizing passing an 8 byte struct shouldn't be hard for
> compilers these days - especially when most things dealing with them are
> inline functions. If we find that it's not a problem on contemporary
> compilers, it might be worthwhile to use a bit more type safety in other
> places too.
>
> ...
>
> IOW, exactly the same code generated. Note that the compiler does *not*
> see the callsites in this case, i.e. this is platform ABI conformant.

I like it. Here's a version that uses a struct named
FullTransactionId (yeah, that's a better name, thanks), defined in
transam.h because c.h didn't feel right.

Client code lost the ability to use operator < directly. I needed to
use a static inline function as a constructor. I lost the
interchangeability with the wide xids in txid.c, so I provided
U64FromFullTransactionId() (I think that'll be useful for
serialisation over the write too). I don't know what to think about
the encoding or meaning of non-normal xids in this thing.

--
Thomas Munro
http://www.enterprisedb.com

Attachment Content-Type Size
0001-Track-the-next-xid-using-64-bits-v2.patch application/octet-stream 43.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-10 01:29:59 Re: missing toast table for pg_policy
Previous Message Joe Conway 2018-07-10 01:19:35 Re: missing toast table for pg_policy