| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Naoya Anzai <nao-anzai(at)xc(dot)jp(dot)nec(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <aki-iwaasa(at)vt(dot)jp(dot)nec(dot)com> |
| Subject: | Re: Why does txid_current() assign new transaction-id? |
| Date: | 2015-05-26 17:47:50 |
| Message-ID: | 20150526174749.GK15206@msg.df7cb.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Re: Tom Lane 2015-05-26 <18863(dot)1432661905(at)sss(dot)pgh(dot)pa(dot)us>
> Christoph Berg <myon(at)debian(dot)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(at)df7cb(dot)de | http://www.df7cb.de/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-05-26 17:50:57 | Re: Why does txid_current() assign new transaction-id? |
| Previous Message | Tom Lane | 2015-05-26 17:38:25 | Re: Why does txid_current() assign new transaction-id? |