pgsql: ecpg: Avoid C99-ism in newly-added test for Oracle compat

[Michael Paquier]

ecpg: Avoid C99-ism in newly-added test for Oracle compat

Per buildfarm member mylodon.  As C99 declarations are allowed in v12~,
this is adjusted only on REL_11_STABLE.  Introduced by 9eb44bb.

Branch
--
REL_11_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/dbd25dd0b59c649981e0a26cc0f367b8c0368473

Modified Files
--
src/interfaces/ecpg/test/compat_oracle/char_array.pgc| 4 ++--
src/interfaces/ecpg/test/expected/compat_oracle-char_array.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

[Michael Paquier]

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: 
https://postgr.es/m/20230410.173500.440060475837236886.horikyota@gmail.com
Backpatch-through: 11

Branch
--
REL_14_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/02f0764546a9ce7f3d843e049bdfa790afa1cf4a

Modified Files
--
src/interfaces/ecpg/ecpglib/data.c |  19 +-
.../ecpg/test/compat_oracle/char_array.pgc |  31 ++-
.../ecpg/test/expected/compat_oracle-char_array.c  | 216 +++--
.../test/expected/compat_oracle-char_array.stderr  | 166 +---
.../test/expected/compat_oracle-char_array.stdout  |   5 +
5 files changed, 310 insertions(+), 127 deletions(-)

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

[Michael Paquier]

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: 
https://postgr.es/m/20230410.173500.440060475837236886.horikyota@gmail.com
Backpatch-through: 11

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/e9e457d22d264308bd709ac034b23a6c5716432a

Modified Files
--
src/interfaces/ecpg/ecpglib/data.c |  19 +-
.../ecpg/test/compat_oracle/char_array.pgc |  31 ++-
.../ecpg/test/expected/compat_oracle-char_array.c  | 216 +++--
.../test/expected/compat_oracle-char_array.stderr  | 166 +---
.../test/expected/compat_oracle-char_array.stdout  |   5 +
5 files changed, 310 insertions(+), 127 deletions(-)

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

[Michael Paquier]

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: 
https://postgr.es/m/20230410.173500.440060475837236886.horikyota@gmail.com
Backpatch-through: 11

Branch
--
REL_15_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/8c746be44002e8f95dcf8e98f58a47ac851563ee

Modified Files
--
src/interfaces/ecpg/ecpglib/data.c |  19 +-
.../ecpg/test/compat_oracle/char_array.pgc |  31 ++-
.../ecpg/test/expected/compat_oracle-char_array.c  | 216 +++--
.../test/expected/compat_oracle-char_array.stderr  | 166 +---
.../test/expected/compat_oracle-char_array.stdout  |   5 +
5 files changed, 310 insertions(+), 127 deletions(-)

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

[Michael Paquier]

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: 
https://postgr.es/m/20230410.173500.440060475837236886.horikyota@gmail.com
Backpatch-through: 11

Branch
--
REL_12_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/a28bd77136db486b081ef392c423c89a392b3aa0

Modified Files
--
src/interfaces/ecpg/ecpglib/data.c |  19 +-
.../ecpg/test/compat_oracle/char_array.pgc |  31 ++-
.../ecpg/test/expected/compat_oracle-char_array.c  | 216 +++--
.../test/expected/compat_oracle-char_array.stderr  | 166 +---
.../test/expected/compat_oracle-char_array.stdout  |   5 +
5 files changed, 310 insertions(+), 127 deletions(-)

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

[Michael Paquier]

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: 
https://postgr.es/m/20230410.173500.440060475837236886.horikyota@gmail.com
Backpatch-through: 11

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/f18029084784ec71a2e825cfcfd81b06d597ab93

Modified Files
--
src/interfaces/ecpg/ecpglib/data.c |  19 +-
.../ecpg/test/compat_oracle/char_array.pgc |  31 ++-
.../ecpg/test/expected/compat_oracle-char_array.c  | 216 +++--
.../test/expected/compat_oracle-char_array.stderr  | 166 +---
.../test/expected/compat_oracle-char_array.stdout  |   5 +
5 files changed, 310 insertions(+), 127 deletions(-)

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

[Michael Paquier]

ecpg: Fix handling of strings in ORACLE compat code with SQLDA

When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: 
https://postgr.es/m/20230410.173500.440060475837236886.horikyota@gmail.com
Backpatch-through: 11

Branch
--
REL_11_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/9eb44bb043af924d9fe567145a3c6510d584399b

Modified Files
--
src/interfaces/ecpg/ecpglib/data.c |  19 +-
.../ecpg/test/compat_oracle/char_array.pgc |  31 ++-
.../ecpg/test/expected/compat_oracle-char_array.c  | 216 +++--
.../test/expected/compat_oracle-char_array.stderr  | 166 +---
.../test/expected/compat_oracle-char_array.stdout  |   5 +
5 files changed, 310 insertions(+), 127 deletions(-)

pgsql: Fix some typos and some incorrectly duplicated words

[David Rowley]

Fix some typos and some incorrectly duplicated words

Author: Justin Pryzby
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/zd3d1qxoccnn8...@telsasoft.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/eef231e8161eb8031a928fe48134ef25ab81fe5e

Modified Files
--
contrib/test_decoding/expected/ddl.out| 2 +-
contrib/test_decoding/sql/ddl.sql | 2 +-
doc/src/sgml/user-manag.sgml  | 2 +-
src/backend/optimizer/path/allpaths.c | 2 +-
src/backend/optimizer/util/plancat.c  | 2 +-
src/backend/replication/pgoutput/pgoutput.c   | 2 +-
src/backend/utils/adt/xid8funcs.c | 2 +-
src/bin/pg_amcheck/t/002_nonesuch.pl  | 2 +-
src/bin/pg_basebackup/bbstreamer.h| 2 +-
src/bin/pg_dump/pg_dumpall.c  | 4 ++--
src/bin/pgbench/pgbench.c | 4 ++--
src/include/access/tableam.h  | 2 +-
src/include/backup/basebackup_target.h| 2 +-
src/include/replication/output_plugin.h   | 2 +-
src/include/storage/s_lock.h  | 2 +-
src/test/isolation/specs/serializable-parallel-3.spec | 2 +-
src/test/modules/unsafe_tests/expected/guc_privs.out  | 2 +-
src/test/modules/unsafe_tests/sql/guc_privs.sql   | 2 +-
src/tools/pg_bsd_indent/tests/elsecomment.0   | 2 +-
src/tools/pg_bsd_indent/tests/elsecomment.0.stdout| 2 +-
20 files changed, 22 insertions(+), 22 deletions(-)

pgsql: Fix various typos

[David Rowley]

Fix various typos

This fixes many spelling mistakes in comments, but a few references to
invalid parameter names, function names and option names too in comments
and also some in string constants

Also, fix an #undef that was undefining the incorrect definition

Author: Alexander Lakhin
Reviewed-by: Justin Pryzby
Discussion: https://postgr.es/m/d5f68d19-c0fc-91a9-118d-7c6a5a3f5...@gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/b4dbf3e924b2556acbe103dc61ac71f9985ff24f

Modified Files
--
contrib/amcheck/verify_heapam.c | 2 +-
contrib/pg_walinspect/pg_walinspect.c   | 2 +-
contrib/postgres_fdw/connection.c   | 2 +-
contrib/postgres_fdw/postgres_fdw.c | 2 +-
meson.build | 2 +-
src/backend/backup/basebackup.c | 2 +-
src/backend/executor/execUtils.c| 2 +-
src/backend/executor/nodeModifyTable.c  | 2 +-
src/backend/rewrite/rewriteManip.c  | 2 +-
src/backend/storage/buffer/bufmgr.c | 2 +-
src/backend/storage/lmgr/predicate.c| 2 +-
src/backend/storage/smgr/md.c   | 2 +-
src/backend/utils/adt/acl.c | 4 ++--
src/backend/utils/adt/array_userfuncs.c | 2 +-
src/backend/utils/misc/guc.c| 8 
src/backend/utils/misc/ps_status.c  | 2 +-
src/backend/utils/mmgr/mcxt.c   | 2 +-
src/backend/utils/resowner/resowner.c   | 2 +-
src/bin/pg_dump/compress_lz4.c  | 2 +-
src/bin/pg_dump/pg_dump_sort.c  | 2 +-
src/bin/pg_dump/pg_dumpall.c| 2 +-
src/bin/scripts/t/100_vacuumdb.pl   | 2 +-
src/include/access/rmgrdesc_utils.h | 2 +-
src/include/port/pg_iovec.h | 2 +-
src/include/regex/regcustom.h   | 2 +-
src/include/utils/memutils_memorychunk.h| 4 ++--
src/include/utils/tuplesort.h   | 4 ++--
src/interfaces/libpq/fe-secure-gssapi.c | 2 +-
src/interfaces/libpq/t/004_load_balance_dns.pl  | 8 
src/port/dirmod.c   | 2 +-
src/test/kerberos/t/001_auth.pl | 2 +-
src/test/ldap/LdapServer.pm | 4 ++--
src/test/modules/ldap_password_func/meson.build | 2 +-
src/test/perl/PostgreSQL/Test/BackgroundPsql.pm | 4 ++--
src/test/regress/pg_regress.c   | 2 +-
35 files changed, 46 insertions(+), 46 deletions(-)

Re: pgsql: Add grantable MAINTAIN privilege and pg_maintain role.

[Jeff Davis]

On Sat, 2023-04-15 at 20:47 +0200, Peter Eisentraut wrote:
> This commit removed RangeVarCallbackOwnsTable(), but there is still a
> mention of it in a comment in src/backend/commands/tablecmds.c. 
> Maybe 
> that mention can simply be removed, or the comment rephrased.

Thank you, fixed.


-- 
Jeff Davis
PostgreSQL Contributor Team - AWS

pgsql: Comment fix for 60684dd834.

[Jeff Davis]

Comment fix for 60684dd834.

Reported-by: Peter Eisentraut
Discussion: 
https://postgr.es/m/766f3799-0269-162f-ba63-4cae34a55...@enterprisedb.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/e39d512f3e9b1e34ffba77c8fe120c2675f6873b

Modified Files
--
src/backend/commands/tablecmds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

[Tom Lane]

Andrew Dunstan  writes:
> On 2023-04-17 Mo 15:53, Tom Lane wrote:
>> (This three-build-system business can't go away soon enough.)

>  From my POV we can remove it any time - I am still having Windows 
> issues with meson, but only with MSYS2. The MSVC meson build on drongo 
> is perfectly well behaved.

I think the outcome of the discussion a week or so ago was that
we want the MSVC scripts in v16, but we can nuke them from HEAD
as soon as the branch is made.

autoconf unfortunately will have to live a good bit longer ...
I don't think we're anywhere near the point where the meson
system is mature enough to drop that.

regards, tom lane

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

[Andrew Dunstan]

On 2023-04-17 Mo 15:53, Tom Lane wrote:

Andrew Dunstan  writes:

I think this also needs a fix in src/tools/msvc/Solution.pm, see


Argh, forgot about that.  Will fix.

(This three-build-system business can't go away soon enough.)





From my POV we can remove it any time - I am still having Windows 
issues with meson, but only with MSYS2. The MSVC meson build on drongo 
is perfectly well behaved.



cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

pgsql: Update Solution.pm for HAVE_GSSAPI[_GSSAPI]_EXT_H, too.

[Tom Lane]

Update Solution.pm for HAVE_GSSAPI[_GSSAPI]_EXT_H, too.

Commit d48ac0070 was still a brick shy of a load.
Per buildfarm (via Andrew Dunstan).

Discussion: 
https://postgr.es/m/08dd6053-deee-52e9-954b-eb6923290...@dunslane.net

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/38358aab9a09d6304eb78e309a3bb969b68d249c

Modified Files
--
src/tools/msvc/Solution.pm | 2 ++
1 file changed, 2 insertions(+)

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

[Tom Lane]

Andrew Dunstan  writes:
> I think this also needs a fix in src/tools/msvc/Solution.pm, see 
> 

Argh, forgot about that.  Will fix.

(This three-build-system business can't go away soon enough.)

regards, tom lane

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

[Andrew Dunstan]

On 2023-04-17 Mo 11:22, Tom Lane wrote:

Further cleanup of autoconf output files for GSSAPI changes.

Running autoheader was missed in f7431bca8.  This is cosmetic since
we aren't using these HAVE_ symbols, but let's get everything in
sync while we're looking at this.

Discussion:https://postgr.es/m/2422362.1681741...@sss.pgh.pa.us



I think this also needs a fix in src/tools/msvc/Solution.pm, see 




cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

[Tom Lane]

Avoid trying to write an empty WAL record in log_newpage_range().

If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs.  This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.

This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch.  log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.

Matthias van de Meent, per report from Justin Pryzby

Discussion: https://postgr.es/m/zd1daibg4rf50...@telsasoft.com

Branch
--
REL_14_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/72a914e9fb7353e17776a2692fb21cff49725400

Modified Files
--
src/backend/access/transam/xloginsert.c | 4 
1 file changed, 4 insertions(+)

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

[Tom Lane]

Avoid trying to write an empty WAL record in log_newpage_range().

If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs.  This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.

This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch.  log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.

Matthias van de Meent, per report from Justin Pryzby

Discussion: https://postgr.es/m/zd1daibg4rf50...@telsasoft.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/3e383f9b68f13502789b234c2dc3274958bdbf78

Modified Files
--
src/backend/access/transam/xloginsert.c | 4 
1 file changed, 4 insertions(+)

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

[Tom Lane]

Avoid trying to write an empty WAL record in log_newpage_range().

If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs.  This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.

This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch.  log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.

Matthias van de Meent, per report from Justin Pryzby

Discussion: https://postgr.es/m/zd1daibg4rf50...@telsasoft.com

Branch
--
REL_12_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/9b0c1f2137fba0292b772b98b5fbccb86aedb336

Modified Files
--
src/backend/access/transam/xloginsert.c | 4 
1 file changed, 4 insertions(+)

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

[Tom Lane]

Avoid trying to write an empty WAL record in log_newpage_range().

If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs.  This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.

This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch.  log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.

Matthias van de Meent, per report from Justin Pryzby

Discussion: https://postgr.es/m/zd1daibg4rf50...@telsasoft.com

Branch
--
REL_15_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/2207df7c34bfcecec33da2a47068e94d7882ffdb

Modified Files
--
src/backend/access/transam/xloginsert.c | 4 
1 file changed, 4 insertions(+)

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

[Tom Lane]

Avoid trying to write an empty WAL record in log_newpage_range().

If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs.  This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.

This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch.  log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.

Matthias van de Meent, per report from Justin Pryzby

Discussion: https://postgr.es/m/zd1daibg4rf50...@telsasoft.com

Branch
--
REL_11_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/c796d7296978e1ac09bcbb41c9230b6cc32b7d44

Modified Files
--
src/backend/access/transam/xloginsert.c | 4 
1 file changed, 4 insertions(+)

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

[Tom Lane]

Avoid trying to write an empty WAL record in log_newpage_range().

If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs.  This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.

This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch.  log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.

Matthias van de Meent, per report from Justin Pryzby

Discussion: https://postgr.es/m/zd1daibg4rf50...@telsasoft.com

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/86874a6dfc8b1878bede18437b1709fbe485a911

Modified Files
--
src/backend/access/transam/xloginsert.c | 4 
1 file changed, 4 insertions(+)

pgsql: Fix incorrect comment about nbtree WAL record.

[Peter Geoghegan]

Fix incorrect comment about nbtree WAL record.

The nbtree VACUUM WAL record stores its page offset number payload in
blk 0 (just like the closely related nbtree DELETE WAL record).  Commit
ebd551f5 fixed a similar issue with the DELETE WAL record, but missed
this one.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/cd7cdc550c2a00027d6ec1810d064ad636250b1f

Modified Files
--
src/include/access/nbtxlog.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)

pgsql: Further cleanup of autoconf output files for GSSAPI changes.

[Tom Lane]

Further cleanup of autoconf output files for GSSAPI changes.

Running autoheader was missed in f7431bca8.  This is cosmetic since
we aren't using these HAVE_ symbols, but let's get everything in
sync while we're looking at this.

Discussion: https://postgr.es/m/2422362.1681741...@sss.pgh.pa.us

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/d48ac0070cff197125088959e5644ed051322f5e

Modified Files
--
src/include/pg_config.h.in | 6 ++
1 file changed, 6 insertions(+)

pgsql: Update configure for ab969a376

[Stephen Frost]

Update configure for ab969a376

Commit ab969a376 updated configure.ac but neglected to update the actual
configure script.  Fix that.

Pointed out by Tom Lane

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/ca07a6e7bd2cb1d6ea38a036be8d60e196935428

Modified Files
--
configure | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)

pgsql: doc: Add additional SQL features codes from SQL:2023

[Peter Eisentraut]

doc: Add additional SQL features codes from SQL:2023

These were mysteriously omitted in c9f57541d9.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1c77de98017022e45a0b12ddb71e202d1f68

Modified Files
--
src/backend/catalog/sql_features.txt | 2 ++
1 file changed, 2 insertions(+)

pgsql: Update Kerberos/GSSAPI configure/meson check

[Stephen Frost]

Update Kerberos/GSSAPI configure/meson check

Instead of checking for the much older gss_init_sec_context, check for
gss_store_cred_into which was added in MIT Kerberos 1.11 (circa 2012).

Discussion: https://postgr.es/m/2313469.1681695223%40sss.pgh.pa.us

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1c52f9c042fb939ed55ff572daee71036720db57

Modified Files
--
configure.ac | 4 ++--
meson.build  | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

pgsql: Put new command-line option into sensible order in help output

[Peter Eisentraut]

Put new command-line option into sensible order in help output

We have two existing conventions for long options: either alphabetical
among short options, or all long options after all the short options.
But the convention apparently used here, next to a functionally
related option, is not one of them.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/2434d60a2ae977a460eda401fd9f99cf619f4743

Modified Files
--
doc/src/sgml/ref/pg_waldump.sgml | 62 
src/bin/pg_waldump/pg_waldump.c  |  3 +-
2 files changed, 32 insertions(+), 33 deletions(-)