pgsql: Prevent write operations on large objects in read-only transacti

Prevent write operations on large objects in read-only transactions Attempting such an operation would already fail, but in various and confusing ways. For example, while in recovery, some elog() messages would be reported, but these should never be user-facing. This commit restricts any write o

pgsql: Fix for change timeline field of IDENTIFY_SYSTEM to int8

Fix for change timeline field of IDENTIFY_SYSTEM to int8 Amendment to ec40f3422412cfdc140b5d3f67db7fd2dac0f1e2: We also need to change the way the datum is supplied to int8. Otherwise, the value is still cut off as an int4, and it will crash on 32-bit platforms. Branch -- master Details ---

Re: pgsql: Change timeline field of IDENTIFY_SYSTEM to int8

I wrote: > To start with, just a few lines down in IdentifySystem() the column > is filled using Int32GetDatum not Int64GetDatum. I will get some > popcorn and await the opinions of the 32-bit buildfarm animals. Didn't need to wait long: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fl

Re: pgsql: Change timeline field of IDENTIFY_SYSTEM to int8

Peter Eisentraut writes: > Change timeline field of IDENTIFY_SYSTEM to int8 Surely this patch is far from complete? To start with, just a few lines down in IdentifySystem() the column is filled using Int32GetDatum not Int64GetDatum. I will get some popcorn and await the opinions of the 32-bit b

pgsql: Fix attlen in RowDescription of BASE_BACKUP response

Fix attlen in RowDescription of BASE_BACKUP response Should be 8 for int8, not -1. Reviewed-by: Nathan Bossart Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commit

pgsql: Change timeline field of IDENTIFY_SYSTEM to int8

Change timeline field of IDENTIFY_SYSTEM to int8 It was int4, but in the other replication commands, timelines are returned as int8. Reviewed-by: Nathan Bossart Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master De

pgsql: Use a short socket directory path in pg_upgrade testing.

Use a short socket directory path in pg_upgrade testing. Several buildfarm members are failing the pg_upgrade test in REL_15_STABLE, though the identical test is fine in HEAD. On thorntail it's possible to see that the problem is an overlength socket path name, and I bet the same is true on the ot

pgsql: Use a short socket directory path in pg_upgrade testing.

Use a short socket directory path in pg_upgrade testing. Several buildfarm members are failing the pg_upgrade test in REL_15_STABLE, though the identical test is fine in HEAD. On thorntail it's possible to see that the problem is an overlength socket path name, and I bet the same is true on the ot

pgsql: Remove %error-verbose directive from jsonpath parser

Remove %error-verbose directive from jsonpath parser None of the other bison parsers contains this directive, and it gives rise to some unfortunate and impenetrable messages, so just remove it. Backpatch to release 12, where it was introduced. Per gripe from Erik Rijkers Discussion: https://pos

pgsql: Remove %error-verbose directive from jsonpath parser

Remove %error-verbose directive from jsonpath parser None of the other bison parsers contains this directive, and it gives rise to some unfortunate and impenetrable messages, so just remove it. Backpatch to release 12, where it was introduced. Per gripe from Erik Rijkers Discussion: https://pos

pgsql: Remove %error-verbose directive from jsonpath parser

Remove %error-verbose directive from jsonpath parser None of the other bison parsers contains this directive, and it gives rise to some unfortunate and impenetrable messages, so just remove it. Backpatch to release 12, where it was introduced. Per gripe from Erik Rijkers Discussion: https://pos

pgsql: Remove %error-verbose directive from jsonpath parser

Remove %error-verbose directive from jsonpath parser None of the other bison parsers contains this directive, and it gives rise to some unfortunate and impenetrable messages, so just remove it. Backpatch to release 12, where it was introduced. Per gripe from Erik Rijkers Discussion: https://pos

pgsql: Remove %error-verbose directive from jsonpath parser

Remove %error-verbose directive from jsonpath parser None of the other bison parsers contains this directive, and it gives rise to some unfortunate and impenetrable messages, so just remove it. Backpatch to release 12, where it was introduced. Per gripe from Erik Rijkers Discussion: https://pos

pgsql: Allow makeaclitem() to accept multiple privilege names.

Allow makeaclitem() to accept multiple privilege names. Interpret its privileges argument as a comma-separated list of privilege names, as in has_table_privilege and other functions. This is actually net less code, since the support routine to parse that already exists, and we can drop convert_pri

pgsql: Add Windows file version information to libpq/test programs.

Add Windows file version information to libpq/test programs. Back-patch to v15, the first version to install these programs. Discussion: https://postgr.es/m/[email protected] Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8b042df51ea

pgsql: Add Windows file version information to libpq/test programs.

Add Windows file version information to libpq/test programs. Back-patch to v15, the first version to install these programs. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b6a5158f98fd5158f6

pgsql: Simplify tab completion of extension versions, redux.

Simplify tab completion of extension versions, redux. After commit 662dbe2c8, psql tab completion didn't conveniently support the case of "ALTER EXTENSION foo UPDATE". It'd always add "TO", which is fine if you want to specify a target version but not if you don't ... and surely the latter is the

pgsql: Simplify tab completion of extension versions, redux.

Simplify tab completion of extension versions, redux. After commit 662dbe2c8, psql tab completion didn't conveniently support the case of "ALTER EXTENSION foo UPDATE". It'd always add "TO", which is fine if you want to specify a target version but not if you don't ... and surely the latter is the

pgsql: Remove redundant null pointer checks before PQclear and PQconnin

Remove redundant null pointer checks before PQclear and PQconninfoFree These functions already had the free()-like behavior of handling null pointers as a no-op. But it wasn't documented, so add it explicitly to the documentation, too. Discussion: https://www.postgresql.org/message-id/flat/dac5

pgsql: Remove redundant null pointer checks before free()

Remove redundant null pointer checks before free() Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just

pgsql: Remove redundant null pointer checks before pg_free()

Remove redundant null pointer checks before pg_free() These are especially useless because the whole point of pg_free() was to do that very check before calling free(). pg_free() could be removed altogether, but I'm keeping it here to keep the API consistent. Discussion: https://www.postgresql.