Обсуждение: Why does txid_current() assign new transaction-id?
Hi,hackers! I have a question about txid_current(). it is "Why does txid_current() assign new transaction-id?". When we executes txid_current() outside of transaction block, it assigns new transaction-id. I guess it doesn't need to assign a new txid because txid_current() is just a read-only function. I found a replaceable function by walking through pg-code, that is GetStableLatestTransactionId(void). I attached a patch which changing just 1-line. Could you please check the code? Regards, Naoya --- Naoya Anzai Engineering Department NEC Solution Inovetors, Ltd. E-Mail: nao-anzai@xc.jp.nec.com ---
Вложения
Naoya Anzai <nao-anzai@xc.jp.nec.com> writes: > I have a question about txid_current(). > it is "Why does txid_current() assign new transaction-id?". Consider begin;select txid_current();insert into my_table ...;commit; If we changed the code as you propose, the result of the SELECT would no longer have anything to do with the XID used for the insertion. regards, tom lane
Re: Tom Lane 2015-05-26 <14207.1432650862@sss.pgh.pa.us> > Naoya Anzai <nao-anzai@xc.jp.nec.com> writes: > > I have a question about txid_current(). > > it is "Why does txid_current() assign new transaction-id?". > > Consider > > begin; > select txid_current(); > insert into my_table ...; > commit; > > If we changed the code as you propose, the result of the SELECT would > no longer have anything to do with the XID used for the insertion. Still, exposing GetStableLatestTransactionId() on the SQL level would make sense for monitoring transaction throughput. Currently if you do that with txid_current(), you'll generate an (low, but measurable) transaction load of 1/monitoring interval. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Christoph Berg <myon@debian.org> writes: > Still, exposing GetStableLatestTransactionId() on the SQL level would > make sense for monitoring transaction throughput. Perhaps, though I wonder why we should expose that and not just report the result of ReadNewTransactionId() --- or in txid.c's case, the result of GetNextXidAndEpoch(). In either case it would have to be a new function, not unilaterally redefining what txid_current() does. regards, tom lane
Re: Tom Lane 2015-05-26 <18863.1432661905@sss.pgh.pa.us> > Christoph Berg <myon@debian.org> writes: > > Still, exposing GetStableLatestTransactionId() on the SQL level would > > make sense for monitoring transaction throughput. > > Perhaps, though I wonder why we should expose that and not just report the > result of ReadNewTransactionId() --- or in txid.c's case, the result of > GetNextXidAndEpoch(). Whatever is most suitable, yes. > In either case it would have to be a new function, > not unilaterally redefining what txid_current() does. Sure. I think the OP's point was (or should have been), to make txid_current not draw a new xid when run outside a transaction block, though it's questionable if that wouldn't just add a POLA-violating layer. Christoph -- cb@df7cb.de | http://www.df7cb.de/
Christoph Berg <myon@debian.org> writes: > I think the OP's point was (or should have been), to make txid_current > not draw a new xid when run outside a transaction block, though it's > questionable if that wouldn't just add a POLA-violating layer. Well, the patch as proposed failed to do that, but in any case I don't see much argument for changing the long-established behavior of that function. Better to add another one if you want a read-only monitoring probe. regards, tom lane