Horton

Re: BufFileRead() error signalling

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-27T22:58:04Z
Lists: pgsql-hackers 
On 2020-May-28, Thomas Munro wrote:

> My indecision on the back-patching question has been resolved by your
> crash report and a search on codesearch.debian.org.

Great news!

> 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.

This makes me a bit uncomfortable.  For example,
https://inst.eecs.berkeley.edu/~cs186/fa03/hwk5/assign5.html (admittedly
a very old class) encourages students to use this API to create an
aggregate.  It might not be the smartest thing in the world, but I'd
prefer not to break such things if they exist proprietarily.  Can we
keep the API unchanged in stable branches and just ereport the errors?

> I'll post a rebased a patch with Robert and Ibrar's changes
> for last reviews later today.

... walks away wondering about BufFileSeekBlock's API ...

(BufFileSeek seems harder to change, due to tuplestore.c)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Make BufFileWrite() void.

  2. Fix buffile.c error handling.

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