| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, a(dot)wicht(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Subject: | Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known snapshots" with PostGIS geometries |
| Date: | 2021-05-12 03:25:57 |
| Message-ID: | 1032535.1620789957@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> I think the bigger-picture question is, if we're trying to detoast
> as the first step in a new transaction of a procedure, where's the
> guarantee that the TOAST data still exists to be fetched? For sure
> we aren't holding any locks that would stop VACUUM from reclaiming
> recently-dead TOAST rows.
Yeah. So here's a patch I actually believe in to some extent, based
on Konstantin's idea.
> I'm still wondering why plpgsql-toast.spec is failing to show the
> problem, too.
The answer to that is that it's not testing commit-inside-a-cursor-loop,
and if it were, it'd still fail to show the problem because its test
table contains just one row.
Interestingly, if you try the test case added here without adding the
code patch, you get a "missing chunk number ... for toast value ..."
error, not "no known snapshots". I think that's because the test
case has additional commands after the COMMIT, causing the transaction
snapshot to get re-established.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| fix-commit-inside-cursor-loop.patch | text/x-diff | 3.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex F | 2021-05-12 10:04:13 | Re: BUG #16833: postgresql 13.1 process crash every hour |
| Previous Message | Tom Lane | 2021-05-12 02:01:11 | Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known snapshots" with PostGIS geometries |