Re: Usage of epoch in txid_current
От | Thomas Munro |
---|---|
Тема | Re: Usage of epoch in txid_current |
Дата | |
Msg-id | CAEepm=2atCqhfS=uvYjr=Q_tykoqGd2G+o80G0fRM29QMfF0iw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Usage of epoch in txid_current (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Usage of epoch in txid_current
|
Список | pgsql-hackers |
On Tue, Jul 10, 2018 at 12:08 PM, Andres Freund <andres@anarazel.de> wrote: > On 2018-07-09 19:56:25 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.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
Вложения
В списке pgsql-hackers по дате отправления: