Re: BufFileRead() error signalling - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: BufFileRead() error signalling
Date
Msg-id CA+hUKG+weLZikdgd0TUZToG31Y9jFs2tCgKp4S+TNfwQWVvnbg@mail.gmail.com
Whole thread Raw
In response to Re: BufFileRead() error signalling  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BufFileRead() error signalling
List 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.



pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: New 'pg' consolidated metacommand patch
Next
From: Alvaro Herrera
Date:
Subject: Re: BufFileRead() error signalling