Add a test case related to the error "cannot fetch toast data without an active snapshot"

From: Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Add a test case related to the error "cannot fetch toast data without an active snapshot"
Date: 2023-01-27 12:56:28
Message-ID: CAMm1aWZ6uT72t8fZAK8mLiH0pDRuc_s9F=NXVbE8tO5oWRKfxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I was going through the comments [1] mentioned in
init_toast_snapshot() and based on the comments understood that the
error "cannot fetch toast data without an active snapshot" will occur
if a procedure fetches a toasted value into a local variable, commits,
and then tries to detoast the value. I would like to know the sample
query which causes such behaviour. I checked the test cases. Looks
like such a case is not present in the regression suit. It is better
to add one.

[1]:
/*
* GetOldestSnapshot returns NULL if the session has no active snapshots.
* We can get that if, for example, a procedure fetches a toasted value
* into a local variable, commits, and then tries to detoast the value.
* Such coding is unsafe, because once we commit there is nothing to
* prevent the toast data from being deleted. Detoasting *must* happen in
* the same transaction that originally fetched the toast pointer. Hence,
* rather than trying to band-aid over the problem, throw an error. (This
* is not very much protection, because in many scenarios the procedure
* would have already created a new transaction snapshot, preventing us
* from detecting the problem. But it's better than nothing, and for sure
* we shouldn't expend code on masking the problem more.)
*/

Thanks & Regards,
Nitin Jadhav

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Önder Kalacı 2023-01-27 13:02:13 Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Previous Message Amit Kapila 2023-01-27 12:15:57 Re: Deadlock between logrep apply worker and tablesync worker