Re: [PATCH] Transaction traceability - txid_status(bigint)
| От | Craig Ringer |
|---|---|
| Тема | Re: [PATCH] Transaction traceability - txid_status(bigint) |
| Дата | |
| Msg-id | CAMsr+YGdOYbePLEzn8qzzVB6BDA63xfRXhrOW9vt+c5a-oTkLA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Transaction traceability - txid_status(bigint) (Petr Jelinek <petr@2ndquadrant.com>) |
| Ответы |
Re: [PATCH] Transaction traceability - txid_status(bigint)
|
| Список | pgsql-hackers |
<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.
В списке pgsql-hackers по дате отправления: