Re: BufFileRead() error signalling

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-27T21:58:43Z
Lists: pgsql-hackers
On Thu, May 28, 2020 at 4:16 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2020-Jan-27, Robert Haas wrote:
> > OK, now that I've waxed eloquent on that topic, let me have a go at
> > your actual questions. Regarding back-patching, I don't mind
> > back-patching error handling patches like this, but I don't feel it's
> > necessary if we have no evidence that data is actually getting
> > corrupted as a result of the problem and the chances of it actually
> > happening seems remote.
>
> I do have evidence of postgres crashes because of a problem that could
> be explained by this bug, so I +1 backpatching this to all supported
> branches.
>
> (The problem I saw is a hash-join spilling data to temp tablespace,
> which fills up but somehow goes undetected, then when reading the data
> back it causes heap_fill_tuple to crash.)

Ooh.

> Thomas, if you're no longer interested in seeing this done, please let
> me know and I can see to it.

My indecision on the back-patching question has been resolved by your
crash report and a search on codesearch.debian.org.  BufFileRead() and
BufFileWrite() aren't referenced by any of the extensions they
package, so by that standard it's OK to change this stuff in back
branches.  I'll post a rebased a patch with Robert and Ibrar's changes
for last reviews later today.



Commits

  1. Make BufFileWrite() void.

  2. Fix buffile.c error handling.

  3. Adjust WAL code so that checkpoints truncate the xlog at the previous