From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Lionel Bouton <lionel(dot)bouton(at)jtek(dot)fr>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reconstructing transaction content after the fact |
Date: | 2020-09-02 19:35:41 |
Message-ID: | 427489.1599075341@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Sep-02, Tom Lane wrote:
>> See VACUUM FREEZE. You couldn't hide connections immediately after
>> insertion, but if the idea is to sanitize every so often, it'd help.
> Starting with 9.4 which introduced the use of HEAP_XMIN_FROZEN
> combination in infomask to replace rewriting the xmin value proper, the
> Xids will be preserved by freezing, so that won't help.
Ah, right.
> One option to hide the xids might be to recreate the tables every once
> in a while, with something like
Hmm. Expensive, but if you were willing to make it even more expensive,
you could also defeat the tuple-ordering attacks mentioned upthread:
CREATE TABLE votes_copy AS SELECT * FROM votes ORDER BY random();
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-09-03 05:01:17 | Re: SSL between Primary and Seconday PostgreSQL DBs |
Previous Message | Alvaro Herrera | 2020-09-02 19:26:20 | Re: Reconstructing transaction content after the fact |