From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | noah(at)leadboat(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de |
Subject: | Re: Wrong usage of RelationNeedsWAL |
Date: | 2021-01-18 08:30:22 |
Message-ID: | 20210118.173022.368003982900161878.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Sun, 17 Jan 2021 23:02:18 -0800, Noah Misch <noah(at)leadboat(dot)com> wrote in
> On Sun, Jan 17, 2021 at 10:36:31PM -0800, Noah Misch wrote:
> > I wrote the above based on the "PageGetLSN(page) > (snapshot)->lsn" check in
> > TestForOldSnapshot(). If the LSN isn't important, what else explains
> > RelationAllowsEarlyPruning() checking RelationNeedsWAL()?
>
> Thinking about it more, some RelationAllowsEarlyPruning() callers need
> different treatment. Above, I was writing about the case of deciding whether
> to do early pruning. The other RelationAllowsEarlyPruning() call sites are
> deciding whether the relation might be lacking old data. For that case, we
> should check RELPERSISTENCE_PERMANENT, not RelationNeedsWAL(). Otherwise, we
> could fail to report an old-snapshot error in a case like this:
>
> setup: CREATE TABLE t AS SELECT ...;
> xact1: BEGIN ISOLATION LEVEL REPEATABLE READ; SELECT 1; -- take snapshot
> xact2: DELETE FROM t;
> (plenty of time passes)
> xact3: SELECT count(*) FROM t; -- early pruning
> xact1: SAVEPOINT q; SELECT count(*) FROM t; ROLLBACK TO q; -- "snapshot too old"
> xact1: ALTER TABLE t SET TABLESPACE something; -- start skipping WAL
> xact1: SELECT count(*) FROM t; -- no error, wanted "snapshot too old"
>
> Is that plausible?
Thank you for the consideration and yes. But I get "snapshot too old"
from the last query with the patched version. maybe I'm missing
something. I'm going to investigate the case.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-01-18 08:33:20 | Re: Improve handling of parameter differences in physical replication |
Previous Message | Amit Kapila | 2021-01-18 08:28:03 | Re: Parallel INSERT (INTO ... SELECT ...) |