| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, 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-09 23:56:25 |
| Message-ID: | 5284.1531180585@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-07-10 00:04:10 | Re: Simplify final sync in pg_rewind's target folder and add --no-sync |
| Previous Message | RK | 2018-07-09 23:44:51 | Costing bug in hash join logic for semi joins |