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
---
Attachments:
txid_current.patchapplication/octet-stream; name=txid_current.patchDownload+1-1
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers