Postgres Pro
Downloads
Home   >   mailing lists

Thread: Draft release notes for next week's releases are up

Draft release notes for next week's releases are up

From
Tom Lane
Date:
See

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164

As usual, please send corrections/comments by Sunday.

            regards, tom lane

Re: Draft release notes for next week's releases are up

From
Melanie Plageman
Date:
On Fri, Aug 2, 2024 at 4:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164
>
> As usual, please send corrections/comments by Sunday.

For the "Prevent infinite loop in VACUUM" item, I noticed two things

1) In REL_17_STABLE, the behavior is an ERROR -- not an infinite loop.
Perhaps it is not worth mentioning the differing behavior because 17
hasn't GA'd yet, but I just wanted to bring this up since I wasn't
sure of the convention.

2) The note says <command>VACUUM</command>. This issue is, of course,
not limited to explicitly issued vacuum commands (i.e.
autovacuum-initiated vacuums can also encounter it). Again, I don't
know if this matters or what the convention is here.

- Melanie

Re: Draft release notes for next week's releases are up

From
Tom Lane
Date:
Melanie Plageman <melanieplageman@gmail.com> writes:
> For the "Prevent infinite loop in VACUUM" item, I noticed two things

Thanks for looking!

> 1) In REL_17_STABLE, the behavior is an ERROR -- not an infinite loop.
> Perhaps it is not worth mentioning the differing behavior because 17
> hasn't GA'd yet, but I just wanted to bring this up since I wasn't
> sure of the convention.

Right, at this point v17 is not a target of these notes, so I just
documented what happens in <= 16.  I did include the commit hashes
for v17/master in the comments, but that's mostly to reassure anyone
who looks that the issue was addressed in those branches.

> 2) The note says <command>VACUUM</command>. This issue is, of course,
> not limited to explicitly issued vacuum commands (i.e.
> autovacuum-initiated vacuums can also encounter it). Again, I don't
> know if this matters or what the convention is here.

I think we usually just say VACUUM.  If it affected autovacuum
differently, that might be worth documenting; but IIUC it's the
same.

            regards, tom lane