| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Usage of epoch in txid_current |
| Date: | 2019-03-25 10:49:42 |
| Message-ID: | CA+hUKGL4ixeiWyrvL-eaM5wLwdU6VsiveeE4uW6dGdgnG4ML8A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 25, 2019 at 5:01 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> New version attached. I'd like to commit this for PG12.
Here is a follow-up sketch patch that shows FullTransactionId being
used in the transaction stack, so you can call eg
GetCurrentFullTransactionId(). A table access method could use this
to avoid the need to freeze stuff later (eg zheap).
I suppose it's not strictly necessary, since you could use
GetCurrentTransactionId() and infer the epoch by comparing with
ReadNextFullTransactionId() (now that the epoch counting is reliable,
due to patch 0001 which I'm repeating again here just for cfbot). But
I suppose we want to get away from that sort of thing. Thoughts?
--
Thomas Munro
https://enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Track-the-next-transaction-ID-using-64-bits-v7.patch | application/x-patch | 48.0 KB |
| 0002-Use-64-bit-transaction-IDs-for-the-transaction-st-v7.patch | application/x-patch | 19.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2019-03-25 11:04:40 | Re: psql display of foreign keys |
| Previous Message | Dmitry Dolgov | 2019-03-25 10:48:00 | Re: libpq compression |