From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new heapcheck contrib module |
Date: | 2020-04-20 20:40:20 |
Message-ID: | CA+TgmoY9T-EVe+SVF59XrBP+NT_T5yF52Y5_VRSim1Yq6A_8rA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 20, 2020 at 4:30 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> A few billion CLogTruncationLock acquisitions in short order will likely
> have at least as big an impact as ShareUpdateExclusiveLock held for the
> duration of the check. That's not really a relevant concern or
> txid_status(). Per-tuple lock acquisitions aren't great.
Yeah, that's true. Doing it for every tuple is going to be too much, I
think. I was hoping we could avoid that.
> I think it might be doable to not need either. E.g. we could set the
> checking backend's xmin to relfrozenxid, and set somethign like
> PROC_IN_VACUUM. That should, I think, prevent clog from being truncated
> in a problematic way (clog truncations look at PROC_IN_VACUUM backends),
> while not blocking vacuum.
Hmm, OK, I don't know if that would be OK or not.
> The similar concern for ReadNewTransactionId() can probably more easily
> be addressed, by only calling ReadNewTransactionId() when encountering
> an xid that's newer than the last value read.
Yeah, if we can cache some things to avoid repetitive calls, that would be good.
> I think it'd be good to set PROC_IN_VACUUM (or maybe a separate version
> of it) while checking anyway. Reading the full relation can take quite a
> while, and we shouldn't prevent hot pruning while doing so.
>
> There's some things we'd need to figure out to be able to use
> PROC_IN_VACUUM, as that's really only safe in some
> circumstances. Possibly it'd be easiest to address that if we'd make the
> check a procedure...
I think we sure want to set things up so that we do this check without
holding a snapshot, if we can. Not sure exactly how to get there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-04-20 21:10:18 | Re: design for parallel backup |
Previous Message | Peter Geoghegan | 2020-04-20 20:37:16 | Re: new heapcheck contrib module |