PG 16 draft release notes ready

On 5/18/23 4:49 PM, Bruce Momjian wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

Thanks for going through this. The release announcement draft will
follow shortly after in a different thread.

I learned a few things creating it this time:

* I can get confused over C function names and SQL function names in
commit messages.

* The sections and ordering of the entries can greatly clarify the
items.

* The feature count is slightly higher than recent releases:

release-10: 189
release-11: 170
release-12: 180
release-13: 178
release-14: 220
release-15: 184
--> release-16: 200

This definitely feels like a very full release. Personally I'm very excited.

Thanks,

Jonathan

On 5/18/23 4:49 PM, Bruce Momjian wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

Still reading, but saw this:

Allow incremental sorts in more cases, including DISTINCT (David
Rowley)window

I didn't realize we had a DISTINCT (David Rowley) window, but it sounds
like an awesome feature ;)

Thanks,

Jonathan

On Thu, May 18, 2023 at 05:39:08PM -0400, Jonathan Katz wrote:

On 5/18/23 4:49 PM, Bruce Momjian wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

Still reading, but saw this:

Allow incremental sorts in more cases, including DISTINCT (David
Rowley)window

I didn't realize we had a DISTINCT (David Rowley) window, but it sounds like
an awesome feature ;)

I have fixed this and several others. The URL will show the new text.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Thu, May 18, 2023 at 1:49 PM Bruce Momjian <bruce@momjian.us> wrote:

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

I learned a few things creating it this time:

* I can get confused over C function names and SQL function names in
commit messages.

The commit history covering pg_walinspect was complicated. Some of the
newly added stuff was revised multiple times, by multiple authors due
to changing ideas about the best UI. Here is some concrete feedback
about that:

* Two functions that were in 15 that each end in *_till_end_of_wal()
were removed for 16, since the same functionality is now provided
through a more intuitive UI: we now tolerate invalid end_lsn values
"from the future", per a new "Tip" in the pg_walinspect documentation
for 16.

In my opinion this should (at most) be covered as a compatibility
item. It's not really new functionality.

* There is one truly new pg_walinspect function added to 16:
pg_get_wal_block_info(). Its main purpose is to see how each
individual block changed -- it's far easier to track how blocks
changed over time using the new function. The original "record
orientated" functions made that very difficult (regex hacks were
required).

pg_get_wal_block_info first appeared under another name, and had
somewhat narrower functionality to the final version, all of which
shouldn't matter to users -- since they never saw a stable release
with any of that. There is no point in telling users about the commits
that changed the name/functionality of pg_get_wal_block_info that came
only a couple of months after the earliest version was commited -- to
users, it is simply a new function with new functionality.

I also suggest merging the pg_waldump items with the section you've
added covering pg_walinspect. A "pg_walinspect and pg_waldump" section
seems natural to me. Some of the enhancements in this area benefit
pg_walinspect and pg_waldump in exactly the same way, since
pg_walinspect is essentially a backend/SQL interface equivalent of
pg_waldump's frontend/CLI interface. Melanie's work on improving the
descriptions output for WAL records like Heap's PRUNE and VACUUM
records is a great example of this -- it does exactly the same thing
for pg_walinspect and pg_waldump, without directly targeting either
(it also affects the wal_debug developer option).

It might also make sense to say that the enhanced WAL record
descriptions from Melanie generally apply to records used by VACUUM
only.

Note also that the item "Add pg_waldump option --save-fullpage to dump
full page images (David Christensen)" is tangentially related to
pg_get_wal_block_info(), since you can also get FPIs using
pg_get_wal_block_info() (in fact, that was originally its main
purpose). I'm not saying that you necessarily need to connect them
together in any way, but you might consider it.

--
Peter Geoghegan

On Thu, May 18, 2023 at 02:53:25PM -0700, Peter Geoghegan wrote:

On Thu, May 18, 2023 at 1:49 PM Bruce Momjian <bruce@momjian.us> wrote:

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

I learned a few things creating it this time:

* I can get confused over C function names and SQL function names in
commit messages.

The commit history covering pg_walinspect was complicated. Some of the
newly added stuff was revised multiple times, by multiple authors due
to changing ideas about the best UI. Here is some concrete feedback
about that:

* Two functions that were in 15 that each end in *_till_end_of_wal()
were removed for 16, since the same functionality is now provided
through a more intuitive UI: we now tolerate invalid end_lsn values
"from the future", per a new "Tip" in the pg_walinspect documentation
for 16.

In my opinion this should (at most) be covered as a compatibility
item. It's not really new functionality.

So, I looked at this and the problem is that this is best as a single
release note entry because we are removing and adding, and if I moved it
to compatibility, I am concerned the new feature will be missed. Since
WAL inspection is a utility operation, inn general, I think having it in
the pg_walinspect section makes the most sense.

* There is one truly new pg_walinspect function added to 16:
pg_get_wal_block_info(). Its main purpose is to see how each
individual block changed -- it's far easier to track how blocks
changed over time using the new function. The original "record
orientated" functions made that very difficult (regex hacks were
required).

pg_get_wal_block_info first appeared under another name, and had
somewhat narrower functionality to the final version, all of which
shouldn't matter to users -- since they never saw a stable release
with any of that. There is no point in telling users about the commits
that changed the name/functionality of pg_get_wal_block_info that came
only a couple of months after the earliest version was commited -- to
users, it is simply a new function with new functionality.

Right.

I also suggest merging the pg_waldump items with the section you've
added covering pg_walinspect. A "pg_walinspect and pg_waldump" section
seems natural to me. Some of the enhancements in this area benefit
pg_walinspect and pg_waldump in exactly the same way, since
pg_walinspect is essentially a backend/SQL interface equivalent of
pg_waldump's frontend/CLI interface. Melanie's work on improving the
descriptions output for WAL records like Heap's PRUNE and VACUUM
records is a great example of this -- it does exactly the same thing
for pg_walinspect and pg_waldump, without directly targeting either
(it also affects the wal_debug developer option).

Well, pg_waldump is an installed binary while pg_walinspect is an
extension, so I am not sure where I would put a merged section.

It might also make sense to say that the enhanced WAL record
descriptions from Melanie generally apply to records used by VACUUM
only.

Okay, I went with:

Improve descriptions of pg_walinspect WAL record descriptions
(Melanie Plageman, Peter Geoghegan)

Note also that the item "Add pg_waldump option --save-fullpage to dump
full page images (David Christensen)" is tangentially related to
pg_get_wal_block_info(), since you can also get FPIs using
pg_get_wal_block_info() (in fact, that was originally its main
purpose). I'm not saying that you necessarily need to connect them
together in any way, but you might consider it.

Well, there is so much _new_ in that tool that listing everything new
seems confusing.

FYI, I have just added an item about more aggressing freezing:

<!--
Author: Peter Geoghegan <pg@bowt.ie>
2022-09-08 [d977ffd92] Instrument freezing in autovacuum log reports.
Author: Peter Geoghegan <pg@bowt.ie>
2022-11-15 [9e5405993] Deduplicate freeze plans in freeze WAL records.
Author: Peter Geoghegan <pg@bowt.ie>
2022-12-28 [1de58df4f] Add page-level freezing to VACUUM.
-->

<listitem>
<para>
During non-freeze operations, perform page freezing where appropriate
Peter Geoghegan)
</para>

<para>
This makes full-table freeze vacuums less necessary.
</para>
</listitem>

All changes committed.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Thu, May 18, 2023 at 3:52 PM Bruce Momjian <bruce@momjian.us> wrote:

So, I looked at this and the problem is that this is best as a single
release note entry because we are removing and adding, and if I moved it
to compatibility, I am concerned the new feature will be missed. Since
WAL inspection is a utility operation, inn general, I think having it in
the pg_walinspect section makes the most sense.

I don't understand what you mean by that. The changes to
*_till_end_of_wal() (the way that those duplicative functions were
removed, and more permissive end_lsn behavior was added) is unrelated
to all of the other changes. Plus it's just not very important.

Okay, I went with:

Improve descriptions of pg_walinspect WAL record descriptions
(Melanie Plageman, Peter Geoghegan)

Note also that the item "Add pg_waldump option --save-fullpage to dump
full page images (David Christensen)" is tangentially related to
pg_get_wal_block_info(), since you can also get FPIs using
pg_get_wal_block_info() (in fact, that was originally its main
purpose). I'm not saying that you necessarily need to connect them
together in any way, but you might consider it.

Well, there is so much _new_ in that tool that listing everything new
seems confusing.

There is pretty much one truly new piece of functionality added to
pg_walinspect (the function called pg_get_wal_block_info was added) --
since the enhancement to rmgr description output applies equally to
pg_waldump, no matter where you place it in the release notes. So not
sure what you mean.

All changes committed.

Even after these changes, the release notes still refer to a function
called "pg_get_wal_block". There is no such function, though -- not in
Postgres 16, and not in any other major version.

As I said, there is a new function called "pg_get_wal_block_info". It
should simply be presented as a whole new function that offers novel
new functionality compared to what was available in Postgres 15 --
without any further elaboration. (It happens to be true that
pg_get_wal_block_info only reached its final form following multiple
rounds of work in multiple commits, but that is of no consequence to
users -- even the earliest form of the function appeared in a commit
in the Postgres 16 cycle.)

--
Peter Geoghegan

On Thu, 18 May 2023 at 22:49, Bruce Momjian <bruce@momjian.us> wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

I'm not sure if bugfixes like these are considered for release notes,
but I'm putting it up here just in case:

As of 8fcb32db (new, only in PG16) we now enforce limits on the size
of WAL records during construction, where previously we hoped that the
WAL records didn't exceed those limits.
This change is immediately user-visible through a change in behaviour
of `pg_logical_emit_message(true, repeat('_', 2^30 - 10), repeat('_',
2^30 - 10))`, and extensions that implement their own rmgrs could also
see a change in behavior from this change.

Kind regards,

Matthias van de Meent
Neon, Inc.

On Thu, May 18, 2023 at 04:12:26PM -0700, Peter Geoghegan wrote:

On Thu, May 18, 2023 at 3:52 PM Bruce Momjian <bruce@momjian.us> wrote:

So, I looked at this and the problem is that this is best as a single
release note entry because we are removing and adding, and if I moved it
to compatibility, I am concerned the new feature will be missed. Since
WAL inspection is a utility operation, inn general, I think having it in
the pg_walinspect section makes the most sense.

I don't understand what you mean by that. The changes to
*_till_end_of_wal() (the way that those duplicative functions were
removed, and more permissive end_lsn behavior was added) is unrelated
to all of the other changes. Plus it's just not very important.

I see what you mean now. I have moved the function removal to the
incompatibilities section and kept the existing entry but remove the
text about the removed functions.

Okay, I went with:

Improve descriptions of pg_walinspect WAL record descriptions
(Melanie Plageman, Peter Geoghegan)

Note also that the item "Add pg_waldump option --save-fullpage to dump
full page images (David Christensen)" is tangentially related to
pg_get_wal_block_info(), since you can also get FPIs using
pg_get_wal_block_info() (in fact, that was originally its main
purpose). I'm not saying that you necessarily need to connect them
together in any way, but you might consider it.

Well, there is so much _new_ in that tool that listing everything new
seems confusing.

There is pretty much one truly new piece of functionality added to
pg_walinspect (the function called pg_get_wal_block_info was added) --
since the enhancement to rmgr description output applies equally to
pg_waldump, no matter where you place it in the release notes. So not
sure what you mean.

I see what you mean now. I have removed the mention of
pg_get_wal_block_info() and moved the three items back into the
extension section since there are only three pg_walinspect items now.

All changes committed.

Even after these changes, the release notes still refer to a function
called "pg_get_wal_block". There is no such function, though -- not in
Postgres 16, and not in any other major version.

Oh

As I said, there is a new function called "pg_get_wal_block_info". It
should simply be presented as a whole new function that offers novel
new functionality compared to what was available in Postgres 15 --
without any further elaboration. (It happens to be true that
pg_get_wal_block_info only reached its final form following multiple
rounds of work in multiple commits, but that is of no consequence to
users -- even the earliest form of the function appeared in a commit
in the Postgres 16 cycle.)

Done. Please see the URL for the updated text, diff attached.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Fri, May 19, 2023 at 01:33:17AM +0200, Matthias van de Meent wrote:

On Thu, 18 May 2023 at 22:49, Bruce Momjian <bruce@momjian.us> wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

I'm not sure if bugfixes like these are considered for release notes,
but I'm putting it up here just in case:

As of 8fcb32db (new, only in PG16) we now enforce limits on the size
of WAL records during construction, where previously we hoped that the
WAL records didn't exceed those limits.
This change is immediately user-visible through a change in behaviour
of `pg_logical_emit_message(true, repeat('_', 2^30 - 10), repeat('_',
2^30 - 10))`, and extensions that implement their own rmgrs could also
see a change in behavior from this change.

I saw that commit but I considered it sufficiently rare and sufficiently
internal that I did not include it.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Thu, May 18, 2023 at 6:44 PM Bruce Momjian <bruce@momjian.us> wrote:

I don't understand what you mean by that. The changes to
*_till_end_of_wal() (the way that those duplicative functions were
removed, and more permissive end_lsn behavior was added) is unrelated
to all of the other changes. Plus it's just not very important.

I see what you mean now. I have moved the function removal to the
incompatibilities section and kept the existing entry but remove the
text about the removed functions.

Your patch now has two separate items for "[5c1b66280] Rework design
of functions in pg_walinspect", but even one item is arguably one too
many. The "ending LSN" item (the second item for this same commit)
should probably be removed altogether. If you're going to keep the
sentences that appear under that second item, then it should at least
be consolidated with the first item, in order that commit 5c1b66280
isn't listed twice.

Note also that the patch doesn't remove a remaining reference to an
update in how pg_get_wal_block_info() works, which (as I've said) is a
brand new function as far as users are concerned. Users don't need to
hear that it has been updated, since these release notes will also be
the first time they've been presented with any information about
pg_get_wal_block_info(). (This isn't very important; again, I suggest
that you avoid saying anything about any specific function, even if
you feel strongly that the "ending LSN" issue must be spelled out like
this.)

There is pretty much one truly new piece of functionality added to
pg_walinspect (the function called pg_get_wal_block_info was added) --
since the enhancement to rmgr description output applies equally to
pg_waldump, no matter where you place it in the release notes. So not
sure what you mean.

I see what you mean now. I have removed the mention of
pg_get_wal_block_info() and moved the three items back into the
extension section since there are only three pg_walinspect items now.

The wording for this item as it appears in the patch is: "Improve
descriptions of pg_walinspect WAL record descriptions". I suggest the
following wording be used instead: "Provide more detailed descriptions
of certain WAL records in the output of pg_walinspect and pg_waldump".

--
Peter Geoghegan

On Fri, May 19, 2023 at 4:49 AM Bruce Momjian <bruce@momjian.us> wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

I learned a few things creating it this time:

* I can get confused over C function names and SQL function names in
commit messages.

* The sections and ordering of the entries can greatly clarify the
items.

* The feature count is slightly higher than recent releases:

release-10: 189
release-11: 170
release-12: 180
release-13: 178
release-14: 220
release-15: 184
--> release-16: 200

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

* When granting role membership, require the granted-by role to be a role

that has appropriate permissions (Robert Haas)
This is a requirement even when the superuser is granting role membership.

an exception would be the granted-by is the bootstrap superuser.

On Thu, May 18, 2023 at 07:15:26PM -0700, Peter Geoghegan wrote:

On Thu, May 18, 2023 at 6:44 PM Bruce Momjian <bruce@momjian.us> wrote:

I don't understand what you mean by that. The changes to
*_till_end_of_wal() (the way that those duplicative functions were
removed, and more permissive end_lsn behavior was added) is unrelated
to all of the other changes. Plus it's just not very important.

I see what you mean now. I have moved the function removal to the
incompatibilities section and kept the existing entry but remove the
text about the removed functions.

Your patch now has two separate items for "[5c1b66280] Rework design
of functions in pg_walinspect", but even one item is arguably one too
many. The "ending LSN" item (the second item for this same commit)

I see your point. pg_get_wal_block_info() doesn't exist in pre-PG 16,
so I have removed that text from the release note item, but kept the
other two functions.

should probably be removed altogether. If you're going to keep the
sentences that appear under that second item, then it should at least
be consolidated with the first item, in order that commit 5c1b66280
isn't listed twice.

We can list items twice if they have different focuses.

Note also that the patch doesn't remove a remaining reference to an
update in how pg_get_wal_block_info() works, which (as I've said) is a
brand new function as far as users are concerned. Users don't need to
hear that it has been updated, since these release notes will also be
the first time they've been presented with any information about
pg_get_wal_block_info(). (This isn't very important; again, I suggest
that you avoid saying anything about any specific function, even if
you feel strongly that the "ending LSN" issue must be spelled out like
this.)

Agreed.

There is pretty much one truly new piece of functionality added to
pg_walinspect (the function called pg_get_wal_block_info was added) --
since the enhancement to rmgr description output applies equally to
pg_waldump, no matter where you place it in the release notes. So not
sure what you mean.

I see what you mean now. I have removed the mention of
pg_get_wal_block_info() and moved the three items back into the
extension section since there are only three pg_walinspect items now.

The wording for this item as it appears in the patch is: "Improve
descriptions of pg_walinspect WAL record descriptions". I suggest the
following wording be used instead: "Provide more detailed descriptions
of certain WAL records in the output of pg_walinspect and pg_waldump".

I went with, "Add detailed descriptions of WAL records in pg_walinspect
and pg_waldump (Melanie Plageman, Peter Geoghegan)".

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Fri, May 19, 2023 at 10:41:59AM +0800, jian he wrote:

On Fri, May 19, 2023 at 4:49 AM Bruce Momjian <bruce@momjian.us> wrote:
* When granting role membership, require the granted-by role to be a role
that has appropriate permissions (Robert Haas)
This is a requirement even when the superuser is granting role membership.

an exception would be the granted-by is the bootstrap superuser.

Okay, updated text is:

<listitem>
<para>
When granting role membership, require the granted-by role to be a role that has appropriate permissions (Robert Haas)
</para>

<para>
This is a requirement even when a non-bootstrap superuser is granting role membership.
</para>
</listitem>

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

Hi,

On 5/18/23 10:49 PM, Bruce Momjian wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

Thanks!

"
This adds the function pg_log_standby_snapshot(). TEXT?:
"

My proposal:

This adds the function pg_log_standby_snapshot() to log details of the current snapshot
to WAL. If the primary is idle, the slot creation on a standby can take a while.
This function can be used on the primary to speed up the logical slot creation on
the standby.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

On Fri, May 19, 2023 at 09:49:18AM +0200, Drouvot, Bertrand wrote:

Thanks!

"
This adds the function pg_log_standby_snapshot(). TEXT?:
"

My proposal:

This adds the function pg_log_standby_snapshot() to log details of the current snapshot
to WAL. If the primary is idle, the slot creation on a standby can take a while.
This function can be used on the primary to speed up the logical slot creation on
the standby.

Yes, I got this concept from the commit message, but I am unclear on
what is actually happening so I can clearly explain it. Slot creation
on the standby needs a snapshot, and that is only created when there is
activity, or happens periodically, and this forces it to happen, or
something? And what snapshot is this? The current session's?

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Thu, May 18, 2023 at 04:49:47PM -0400, Bruce Momjian wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

Thanks!

Allow GRANT to give vacuum and analyze permission to users beyond the
table owner or superusers (Nathan Bossart)

This one was effectively reverted in favor of the MAINTAIN privilege.

Create a predefined role with permission to perform maintenance
operations (Nathan Bossart)

IMO this should also mention the grantable MAINTAIN privilege.
Alternatively, the item above about granting vacuum/analyze privileges
could be adjusted.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

The intro in "E.1.3. Changes" says "... between PostgreSQL 15 and the
previous major release".

That should be "... between PostgreSQL __16__ ..." right?

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

On Fri, May 19, 2023 at 07:31:40AM -0700, Nathan Bossart wrote:

On Thu, May 18, 2023 at 04:49:47PM -0400, Bruce Momjian wrote:

I have completed the first draft of the PG 16 release notes. You can
see the output here:

https://momjian.us/pgsql_docs/release-16.html

I will adjust it to the feedback I receive; that URL will quickly show
all updates.

Thanks!

Allow GRANT to give vacuum and analyze permission to users beyond the
table owner or superusers (Nathan Bossart)

This one was effectively reverted in favor of the MAINTAIN privilege.

Okay, removed.

Create a predefined role with permission to perform maintenance
operations (Nathan Bossart)

IMO this should also mention the grantable MAINTAIN privilege.
Alternatively, the item above about granting vacuum/analyze privileges
could be adjusted.

Very good point --- here is the new text:

<!--
Author: Jeff Davis <jdavis@postgresql.org>
2022-12-13 [60684dd83] Add grantable MAINTAIN privilege and pg_maintain role.
Author: Andrew Dunstan <andrew@dunslane.net>
2022-11-28 [4441fc704] Provide non-superuser predefined roles for vacuum and an
Author: Jeff Davis <jdavis@postgresql.org>
2023-01-14 [ff9618e82] Fix MAINTAIN privileges for toast tables and partitions.
-->

<listitem>
<para>
Create a predefined role and grantable privilege with permission to perform maintenance operations (Nathan Bossart)
</para>

<para>
The predefined role is is called pg_maintain.
</para>
</listitem>

I will commit this change now.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Fri, May 19, 2023 at 11:07:29AM -0400, Sehrope Sarkuni wrote:

The intro in "E.1.3. Changes" says "... between PostgreSQL 15 and the previous
major release".

That should be "... between PostgreSQL __16__ ..." right?

Oh, I thought I had changed all those --- fixed now, thanks!

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.