pgsql: Fix incorrect format placeholders
Fix incorrect format placeholders Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6612185883c6a43979693358423ee647421ff621 Modified Files -- src/bin/pg_combinebackup/pg_combinebackup.c | 4 ++-- src/bin/pg_combinebackup/reconstruct.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
pgsql: Add tests for more row patterns with COPY FROM .. (ON_ERROR igno
Add tests for more row patterns with COPY FROM .. (ON_ERROR ignore) While digging into the code of this feature, I got confused by the fact that a line is skipped when a value cannot be converted to its expected attribute even if the line has fewer attributes than the target relation. The tests had a check for the case of an empty line, this commit a couple more patterns where a line is incomplete, but skipped because of a conversion error. Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/ze_7kzqexdt0b...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a189ed49d6292979be1478292246be61c4563043 Modified Files -- src/test/regress/expected/copy2.out | 5 +++-- src/test/regress/sql/copy2.sql | 3 +++ 2 files changed, 6 insertions(+), 2 deletions(-)
pgsql: Fix a random failure in 038_save_logical_slots_shutdown.pl.
Fix a random failure in 038_save_logical_slots_shutdown.pl. The test ensures that all the WAL on the publisher is sent to the subscriber before shutdown by comparing the confirmed_flush_lsn of the associated slot with the shutdown_checkpoint WAL location. But if the shutdown_checkpoint location falls into a new page in the WAL then the check won't work. So, ensure that the shutdown_checkpoint WAL record doesn't fall into a new page. Reported-by: Bharath Rupireddy Author: Bharath Rupireddy Reviewed-by: Vignesh C, Kuroda Hayato, Amit Kapila Discussion: https://postgr.es/m/CALj2ACVLzH5CN-h9=s26mdrhpuj9ydluw70yh4joipw03wl...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0b84f5c419a300dc1b1a70cf63b9907208e52643 Modified Files -- src/test/recovery/t/038_save_logical_slots_shutdown.pl | 10 ++ 1 file changed, 10 insertions(+)
pgsql: ci: Use a RAM disk and more CPUs on FreeBSD.
ci: Use a RAM disk and more CPUs on FreeBSD. Run the tests in a RAM disk. It's still a UFS file system and is backed by 20GB of disk, but this avoids a lot of I/O. Even though we disable fsync, our tests do a lot of directory manipulations, some of which force file system meta-data to disk and flush slow device write caches on UFS. This was a bottleneck preventing effective scaling beyond 2 CPUs. Now we can use 4 CPUs like on other OSes, for a huge speedup. Reviewed-by: Maxim Orlov Discussion: https://postgr.es/m/CA%2BhUKG%2BFXLcEg1dyTqJjDiNQ8pGom4KrJj4wF38C90thti9dVA%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0265e5c120e0971a9c50a1e27ce4cb847c15a1bf Modified Files -- .cirrus.tasks.yml | 8 +++- src/tools/ci/gcp_freebsd_repartition.sh | 24 +++- 2 files changed, 14 insertions(+), 18 deletions(-)
pgsql: Add some asserts based on LWLockHeldByMe() for replication slot
Add some asserts based on LWLockHeldByMe() for replication slot statistics Two assertions checking that ReplicationSlotAllocationLock is acquired are added to pgstat_create_replslot() and pgstat_drop_replslot(), corresponding to the routines in charge of the creation and the drop of replication slot statistics. The code previously relied on this assumption and documented it in comments, but did not enforce this policy at runtime. Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/ze_p-hmd_yfev...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/77cf6a78de9fa48976d8c9152a48290beb06dc8b Modified Files -- src/backend/utils/activity/pgstat_replslot.c | 4 1 file changed, 4 insertions(+)
pgsql: Fix version check in 002_pg_upgrade.pl.
Fix version check in 002_pg_upgrade.pl. Commit f696c0cd5f tried to account for the version in a way that includes development versions, but it was broken. Fix with suggestion from Tom Lane. Discussion: https://postgr.es/m/1553991.1710191...@sss.pgh.pa.us Reported-by: Tom Lane Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/32dd2c1eff540e454d50a1d59d2d90ab6e70e0b6 Modified Files -- src/bin/pg_upgrade/t/002_pg_upgrade.pl | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-)
pgsql: Fix confusion about the return rowtype of SQL-language procedure
Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=y8t0fjp-_svssrsnrqt7...@mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6f66fadad91b61f2f3415aafe14f52c2e5e6ad88 Modified Files -- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 -- src/backend/optimizer/util/clauses.c | 14 ++- src/include/executor/functions.h | 6 + src/test/regress/expected/create_procedure.out | 14 ++- src/test/regress/sql/create_procedure.sql | 11 +++- 6 files changed, 69 insertions(+), 18 deletions(-)
pgsql: Fix confusion about the return rowtype of SQL-language procedure
Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=y8t0fjp-_svssrsnrqt7...@mail.gmail.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/28184f039e3364a4a8e341dcbd713372689728db Modified Files -- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 -- src/backend/optimizer/util/clauses.c | 14 ++- src/include/executor/functions.h | 6 + src/test/regress/expected/create_procedure.out | 14 ++- src/test/regress/sql/create_procedure.sql | 11 +++- 6 files changed, 69 insertions(+), 18 deletions(-)
pgsql: Fix confusion about the return rowtype of SQL-language procedure
Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=y8t0fjp-_svssrsnrqt7...@mail.gmail.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc1503d5b8b3a1565702dd13e8874f74211a8e09 Modified Files -- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 34 -- src/backend/optimizer/util/clauses.c | 12 + src/include/executor/functions.h | 6 + src/test/regress/expected/create_procedure.out | 14 ++- src/test/regress/sql/create_procedure.sql | 11 - 6 files changed, 67 insertions(+), 17 deletions(-)
pgsql: Fix confusion about the return rowtype of SQL-language procedure
Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=y8t0fjp-_svssrsnrqt7...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ee3261e9bb6f0aa30ec74896c57f69b0636bfdd Modified Files -- src/backend/catalog/pg_proc.c | 1 + src/backend/executor/functions.c | 11 +-- src/backend/optimizer/util/clauses.c | 2 ++ src/include/executor/functions.h | 1 + src/test/regress/expected/create_procedure.out | 14 +- src/test/regress/sql/create_procedure.sql | 11 ++- 6 files changed, 36 insertions(+), 4 deletions(-)
pgsql: Fix confusion about the return rowtype of SQL-language procedure
Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=y8t0fjp-_svssrsnrqt7...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/649bbba1134dce05998e26137fcb32d0e0cb6311 Modified Files -- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 -- src/backend/optimizer/util/clauses.c | 14 ++- src/include/executor/functions.h | 6 + src/test/regress/expected/create_procedure.out | 14 ++- src/test/regress/sql/create_procedure.sql | 11 +++- 6 files changed, 69 insertions(+), 18 deletions(-)
pgsql: Fix confusion about the return rowtype of SQL-language procedure
Fix confusion about the return rowtype of SQL-language procedures. There is a very ancient hack in check_sql_fn_retval that allows a single SELECT targetlist entry of composite type to be taken as supplying all the output columns of a function returning composite. (This is grotty and fundamentally ambiguous, but it's really hard to do nested composite-returning functions without it.) As far as I know, that doesn't cause any problems in ordinary functions. It's disastrous for procedures however. All procedures that have any output parameters are labeled with prorettype RECORD, and the CALL code expects it will get back a record with one column per output parameter, regardless of whether any of those parameters is composite. Doing something else leads to an assertion failure or core dump. This is simple enough to fix: we just need to not apply that rule when considering procedures. However, that requires adding another argument to check_sql_fn_retval, which at least in principle might be getting called by external callers. Therefore, in the back branches convert check_sql_fn_retval into an ABI-preserving wrapper around a new function check_sql_fn_retval_ext. Per report from Yahor Yuzefovich. This has been broken since we implemented procedures, so back-patch to all supported branches. Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=y8t0fjp-_svssrsnrqt7...@mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/40d1bdeb72b2d7dfa9e0d91785f0a056b719ebb1 Modified Files -- src/backend/catalog/pg_proc.c | 7 +++--- src/backend/executor/functions.c | 35 -- src/backend/optimizer/util/clauses.c | 14 ++- src/include/executor/functions.h | 6 + src/test/regress/expected/create_procedure.out | 14 ++- src/test/regress/sql/create_procedure.sql | 11 +++- 6 files changed, 69 insertions(+), 18 deletions(-)
pgsql: Fix incorrect filename reference in comment
Fix incorrect filename reference in comment Author: Cary Huang Discussion: https://postgr.es/m/18e34071af0.dbfc9663424635.8571906799773344...@highgo.ca Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fe4750effd61f5a37d18c48caa53892dbdcfb96d Modified Files -- src/include/optimizer/paths.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: Catalog changes preparing for builtin collation provider.
Jeff Davis writes:
> Patch attached, following the example in AdjustUpgrade.pm. It feels a
> bit inconsistent to sometimes use $oldnode->pg_version and sometimes
> use $old_major_version, but it's certainly better than what I had done
> in f696c0cd5f.
You're still doing it the hard way. I suggest the attached.
regards, tom lane
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
index 5ef78691cb..34a459496e 100644
--- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -92,10 +92,6 @@ my $oldnode =
PostgreSQL::Test::Cluster->new('old_node',
install_path => $ENV{oldinstall});
-# Numeric major version of old cluster, ignoring "devel" suffix.
-# Needed for testing upgrades from development version to itself.
-my $old_major_version = int($oldnode->pg_version =~ s/devel//rg);
-
my %node_params = ();
# To increase coverage of non-standard segment size and group access without
@@ -118,10 +114,10 @@ my $original_locale = "C";
my $original_datlocale = "";
my $provider_field = "'c' AS datlocprovider";
my $old_datlocale_field = "NULL AS datlocale";
-if ($old_major_version >= 15 && $ENV{with_icu} eq 'yes')
+if ($oldnode->pg_version >= 15 && $ENV{with_icu} eq 'yes')
{
$provider_field = "datlocprovider";
- if ($old_major_version >= 17)
+ if ($oldnode->pg_version >= '17devel')
{
$old_datlocale_field = "datlocale";
}
pgsql: libpq: Add encrypted and non-blocking query cancellation routine
libpq: Add encrypted and non-blocking query cancellation routines The existing PQcancel API uses blocking IO, which makes PQcancel impossible to use in an event loop based codebase without blocking the event loop until the call returns. It also doesn't encrypt the connection over which the cancel request is sent, even when the original connection required encryption. This commit adds a PQcancelConn struct and assorted functions, which provide a better mechanism of sending cancel requests; in particular all the encryption used in the original connection are also used in the cancel connection. The main entry points are: - PQcancelCreate creates the PQcancelConn based on the original connection (but does not establish an actual connection). - PQcancelStart can be used to initiate non-blocking cancel requests, using encryption if the original connection did so, which must be pumped using - PQcancelPoll. - PQcancelReset puts a PQcancelConn back in state so that it can be reused to send a new cancel request to the same connection. - PQcancelBlocking is a simpler-to-use blocking API that still uses encryption. Additional functions are - PQcancelStatus, mimicks PQstatus; - PQcancelSocket, mimicks PQcancelSocket; - PQcancelErrorMessage, mimicks PQerrorMessage; - PQcancelFinish, mimicks PQfinish. Author: Jelte Fennema-Nio Reviewed-by: Denis Laxalde Discussion: https://postgr.es/m/am5pr83mb0178d3b31ca1b6ec4a8ecc42f7...@am5pr83mb0178.eurprd83.prod.outlook.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/61461a300c1cb5d53955ecd792ad0ce75a104736 Modified Files -- doc/src/sgml/libpq.sgml | 507 +-- src/interfaces/libpq/exports.txt | 9 + src/interfaces/libpq/fe-cancel.c | 296 - src/interfaces/libpq/fe-connect.c| 129 +- src/interfaces/libpq/libpq-fe.h | 31 +- src/interfaces/libpq/libpq-int.h | 5 + src/test/modules/libpq_pipeline/libpq_pipeline.c | 121 ++ src/tools/pgindent/typedefs.list | 1 + 8 files changed, 1044 insertions(+), 55 deletions(-)
pgsql: Fix copying SockAddr struct
Fix copying SockAddr struct Valgrind alerted about accessing uninitialized bytes after commit 4945e4ed4a: ==700242== VALGRINDERROR-BEGIN ==700242== Conditional jump or move depends on uninitialised value(s) ==700242==at 0x6D8A2A: getnameinfo_unix (ip.c:253) ==700242==by 0x6D8BD1: pg_getnameinfo_all (ip.c:122) ==700242==by 0x4B3EB6: BackendInitialize (postmaster.c:4266) ==700242==by 0x4B684E: BackendStartup (postmaster.c:4114) ==700242==by 0x4B6986: ServerLoop (postmaster.c:1780) ==700242==by 0x4B80CA: PostmasterMain (postmaster.c:1478) ==700242==by 0x3F7424: main (main.c:197) ==700242== Uninitialised value was created by a stack allocation ==700242==at 0x4B6934: ServerLoop (postmaster.c:1737) ==700242== ==700242== VALGRINDERROR-END That was because the SockAddr struct was not copied correctly. Per buildfarm animal "skink". Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cb9663e20dc2ddc904660d12638f6c82af7b420e Modified Files -- src/backend/libpq/pqcomm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Set socket options in child process after forking
Set socket options in child process after forking Try to minimize the work done in the postmaster process for each accepted connection, so that postmaster can quickly proceed with its duties. These function calls are very fast so this doesn't make any measurable performance difference in practice, but it's nice to have all the socket options initialization code in one place for sake of readability too. This also paves the way for an upcoming commit that will move the initialization of the Port struct to the child process. Discussion: https://www.postgresql.org/message-id/7a59b073-5b5b-151e-7ed3-8b01ff7ce...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/73f7fb2a4c4480cfebc52dddf0049e69b830b214 Modified Files -- src/backend/libpq/pqcomm.c | 196 ++--- 1 file changed, 96 insertions(+), 100 deletions(-)
pgsql: Pass CAC as an argument to the backend process
Pass CAC as an argument to the backend process We used to smuggle it to the child process in the Port struct, but it seems better to pass it down as a separate argument. This paves the way for the next commit, which moves the initialization of the Port struct to the backend process, after forking. Reviewed-by: Tristan Partin, Andres Freund Discussion: https://www.postgresql.org/message-id/7a59b073-5b5b-151e-7ed3-8b01ff7ce...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d162c3a73bf14416ff4012de6f01c3d825610f70 Modified Files -- src/backend/postmaster/postmaster.c | 44 +++-- src/include/libpq/libpq-be.h| 12 -- 2 files changed, 32 insertions(+), 24 deletions(-)
pgsql: Move initialization of the Port struct to the child process
Move initialization of the Port struct to the child process In postmaster, use a more lightweight ClientSocket struct that encapsulates just the socket itself and the remote endpoint's address that you get from accept() call. ClientSocket is passed to the child process, which initializes the bigger Port struct. This makes it more clear what information postmaster initializes, and what is left to the child process. Rename the StreamServerPort and StreamConnection functions to make it more clear what they do. Remove StreamClose, replacing it with plain closesocket() calls. Reviewed-by: Tristan Partin, Andres Freund Discussion: https://www.postgresql.org/message-id/7a59b073-5b5b-151e-7ed3-8b01ff7ce...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4945e4ed4a72c3ff41560ccef722c3d70ae07dbb Modified Files -- src/backend/libpq/pqcomm.c | 65 -- src/backend/postmaster/postmaster.c | 229 +++- src/backend/tcop/postgres.c | 5 +- src/include/libpq/libpq-be.h| 20 +++- src/include/libpq/libpq.h | 7 +- src/tools/pgindent/typedefs.list| 1 + 6 files changed, 142 insertions(+), 185 deletions(-)
pgsql: Disconnect if socket cannot be put into non-blocking mode
Disconnect if socket cannot be put into non-blocking mode Commit 387da18874 moved the code to put socket into non-blocking mode from socket_set_nonblocking() into the one-time initialization function, pq_init(). In socket_set_nonblocking(), there indeed was a risk of recursion on failure like the comment said, but in pq_init(), ERROR or FATAL is fine. There's even another elog(FATAL) just after this, if setting FD_CLOEXEC fails. Note that COMMERROR merely logged the error, it did not close the connection, so if putting the socket to non-blocking mode failed we would use the connection anyway. You might not immediately notice, because most socket operations in a regular backend wait for the socket to become readable/writable anyway. But e.g. replication will be quite broken. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/d40a5cd0-2722-40c5-8755-12e9e811f...@iki.fi Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ad5cd55e675c6b55a521d9db5e57bba5a02a9208 Modified Files -- src/backend/libpq/pqcomm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
pgsql: Disconnect if socket cannot be put into non-blocking mode
Disconnect if socket cannot be put into non-blocking mode Commit 387da18874 moved the code to put socket into non-blocking mode from socket_set_nonblocking() into the one-time initialization function, pq_init(). In socket_set_nonblocking(), there indeed was a risk of recursion on failure like the comment said, but in pq_init(), ERROR or FATAL is fine. There's even another elog(FATAL) just after this, if setting FD_CLOEXEC fails. Note that COMMERROR merely logged the error, it did not close the connection, so if putting the socket to non-blocking mode failed we would use the connection anyway. You might not immediately notice, because most socket operations in a regular backend wait for the socket to become readable/writable anyway. But e.g. replication will be quite broken. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/d40a5cd0-2722-40c5-8755-12e9e811f...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f8c5317d001556a51441fad81e8f6c32994f2d79 Modified Files -- src/backend/libpq/pqcomm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
pgsql: Disconnect if socket cannot be put into non-blocking mode
Disconnect if socket cannot be put into non-blocking mode Commit 387da18874 moved the code to put socket into non-blocking mode from socket_set_nonblocking() into the one-time initialization function, pq_init(). In socket_set_nonblocking(), there indeed was a risk of recursion on failure like the comment said, but in pq_init(), ERROR or FATAL is fine. There's even another elog(FATAL) just after this, if setting FD_CLOEXEC fails. Note that COMMERROR merely logged the error, it did not close the connection, so if putting the socket to non-blocking mode failed we would use the connection anyway. You might not immediately notice, because most socket operations in a regular backend wait for the socket to become readable/writable anyway. But e.g. replication will be quite broken. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/d40a5cd0-2722-40c5-8755-12e9e811f...@iki.fi Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/539e328b1c3a4047c7ff525524edbcca2bac6e10 Modified Files -- src/backend/libpq/pqcomm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
pgsql: Disconnect if socket cannot be put into non-blocking mode
Disconnect if socket cannot be put into non-blocking mode Commit 387da18874 moved the code to put socket into non-blocking mode from socket_set_nonblocking() into the one-time initialization function, pq_init(). In socket_set_nonblocking(), there indeed was a risk of recursion on failure like the comment said, but in pq_init(), ERROR or FATAL is fine. There's even another elog(FATAL) just after this, if setting FD_CLOEXEC fails. Note that COMMERROR merely logged the error, it did not close the connection, so if putting the socket to non-blocking mode failed we would use the connection anyway. You might not immediately notice, because most socket operations in a regular backend wait for the socket to become readable/writable anyway. But e.g. replication will be quite broken. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/d40a5cd0-2722-40c5-8755-12e9e811f...@iki.fi Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf1f593e899ee9aa1de80164a3005b02474deb50 Modified Files -- src/backend/libpq/pqcomm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
pgsql: Disconnect if socket cannot be put into non-blocking mode
Disconnect if socket cannot be put into non-blocking mode Commit 387da18874 moved the code to put socket into non-blocking mode from socket_set_nonblocking() into the one-time initialization function, pq_init(). In socket_set_nonblocking(), there indeed was a risk of recursion on failure like the comment said, but in pq_init(), ERROR or FATAL is fine. There's even another elog(FATAL) just after this, if setting FD_CLOEXEC fails. Note that COMMERROR merely logged the error, it did not close the connection, so if putting the socket to non-blocking mode failed we would use the connection anyway. You might not immediately notice, because most socket operations in a regular backend wait for the socket to become readable/writable anyway. But e.g. replication will be quite broken. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/d40a5cd0-2722-40c5-8755-12e9e811f...@iki.fi Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4fce5f970d584114ba9f981b367eb7720621cc50 Modified Files -- src/backend/libpq/pqcomm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
pgsql: Disconnect if socket cannot be put into non-blocking mode
Disconnect if socket cannot be put into non-blocking mode Commit 387da18874 moved the code to put socket into non-blocking mode from socket_set_nonblocking() into the one-time initialization function, pq_init(). In socket_set_nonblocking(), there indeed was a risk of recursion on failure like the comment said, but in pq_init(), ERROR or FATAL is fine. There's even another elog(FATAL) just after this, if setting FD_CLOEXEC fails. Note that COMMERROR merely logged the error, it did not close the connection, so if putting the socket to non-blocking mode failed we would use the connection anyway. You might not immediately notice, because most socket operations in a regular backend wait for the socket to become readable/writable anyway. But e.g. replication will be quite broken. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/d40a5cd0-2722-40c5-8755-12e9e811f...@iki.fi Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/df27d76d32f2c1a2572983a5c6a874d003cd0321 Modified Files -- src/backend/libpq/pqcomm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)
pgsql: libpq: Move pg_cancel to fe-cancel.c
libpq: Move pg_cancel to fe-cancel.c No other files need to access this struct, so there is no need to have its definition in a header file. Author: Jelte Fennema-Nio Discussion: https://postgr.es/m/202403061822.spfzqbf7dsgg@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4dec98c2af64851b643af14c36c8b99215dfd70d Modified Files -- src/interfaces/libpq/fe-cancel.c | 20 src/interfaces/libpq/libpq-int.h | 18 -- 2 files changed, 20 insertions(+), 18 deletions(-)
