Re: BUG #18545: \dt breaks transaction, calling error when executed in SET SESSION AUTHORIZATION

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Андрей Рачицкий <therealgofman@mail.ru>, pgsql-bugs@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2024-08-05T00:46:53Z
Lists: pgsql-bugs, pgsql-hackers
On Sun, Aug 4, 2024 at 3:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Any opinions about whether it's too late to do this in v17?
> Post-beta3 is pretty late, for sure, but maybe we could get
> away with it.  And we are fixing a bug here.
>
>
If this isn't going to appear in the beta3 build I'd say it's probably too
late given the target audience for waiting on this is extension authors.
If it is going into beta3 then I'd vote to allow it.

Feels like this dynamic should be covered as part of our recent attempt to
better communicate our policies to our extension authoring community.

https://www.postgresql.org/docs/devel/xfunc-c.html#XFUNC-GUIDANCE-ABI-MNINOR-VERSIONS

Something like:

Namely, beta releases do not constitute a minor release under our policies
and updates to our API/ABIs can happen during beta at any point - whether
for features newly added in the under- development major version or not.
Extension authors are thus encouraged to test their extensions against the
RC build at minimum should they wish for their extension to be ready when
the initial release comes out.  Tests against beta versions are very
helpful to all interested parties but there is no guarantee that tests that
pass any given beta release will pass when performed against the release
candidate.  For the release candidate we will use the same patching policy
as for a normal minor release.  Any exceptions will necessitate a second
release candidate.

The above wording allows us to put this patch into beta3, which I'd be fine
with.  But I'd also be fine with adding wording like: "Changes introduced
after the final beta is released for testing will [generally?] be limited
to fixing items conforming to the Open Item policy."  Probably favor the
latter too by a small margin.

David J.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix parallel worker tracking of new catalog relfilenumbers.

  2. Restore relmapper state early enough in parallel workers.

  3. Allow parallel workers to cope with a newly-created session user ID.

  4. Clean up handling of client_encoding GUC in parallel workers.

  5. Fix rd_firstRelfilenodeSubid for nailed relations, in parallel workers.

  6. Fix several mistakes around parallel workers and client_encoding.