<p dir="ltr">On 23 Aug 2016 16:02, "Petr Jelinek" <<a
href="mailto:petr@2ndquadrant.com">petr@2ndquadrant.com</a>>wrote:<br /> ><br /> > On 23/08/16 02:55, Craig
Ringerwrote:<br /> >><br /> >> On 23 August 2016 at 01:03, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a><br/> >> <mailto:<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>>wrote:<br /> >><br /> >><br />
>><br/> >> I think you should use underscores to separate all of the words<br /> >> instead
ofonly some of them.<br /> >><br /> >><br /> >> ifassigned => if_assigned<br /> >><br />
>>ifrecent=> if_recent<br /> >><br /> >> Updated patch series attached. As before, 0-4 intended
forcommit, 5<br /> >> just because it'll be handy to have around for people doing wraparound<br /> >>
relatedtesting.<br /> ><br /> ><br /> > I guess you mean 0-3 for commit and 4 is just handy?<p dir="ltr">Er.
Right.1-3. 4 just as handy test/tool.<p dir="ltr">1 most important and useful. Then 2. Then 3.<p dir="ltr">> From
thepoint of code this patch seems good to me.<p dir="ltr">Thanks.<p dir="ltr">> I do wonder about the 3rd patch
though.I wonder if it would not be better to have the opposite function instead - converting xid to txid as that will
alwayswork and does not have to have the NULL case and would be simpler in terms of code.<p dir="ltr">Yeah, but it
wouldn'tsolve the need to take txid_current() output and do stuff with it other than ordinal comparison. Like pass to
committs functions and others that take xid. If we extend all funcs that take xid to take bigint instead, they just get
touse the same epoch logic in them, complete with some way to deal with wrapped xids sensibly. It has to be done
somewhere.Though it's prettier if hidden from the user.<p dir="ltr">More importantly imo, txid => bigint has to
assumethe current epoch. We have no way to make sure the user doesn't try to use something already wrapped.<p
dir="ltr">Idon't mind if everyone decides it's better to make xid go away and use bigint everywhere user facing. Or
evena new bigxid type. More work than I can really afford but can manage; shouldn't block #1 and #2 though as they
alreadyuse bigint.