pgsql: Fix assertion failure with latch wait in single-user mode
Fix assertion failure with latch wait in single-user mode LatchWaitSetPostmasterDeathPos, the latch event position for the postmaster death event, is initialized under IsUnderPostmaster. WaitLatch() considered it as a valid wait target in single-user mode (!IsUnderPostmaster), which was incorrect. One code path found to fail with an assertion failure is a database drop in single-user mode while waiting in WaitForProcSignalBarrier() after the drop. Oversight in commit 84e5b2f07a5e. Author: Patrick Stählin Co-authored-by: Ronan Dunklau Discussion: https://postgr.es/m/18996-3a2744c814048...@postgresql.org Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f7dfccf9605dab54956321e236de3415a2ba2fa3 Modified Files -- src/backend/storage/ipc/latch.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Fix assertion failure with latch wait in single-user mode
Fix assertion failure with latch wait in single-user mode LatchWaitSetPostmasterDeathPos, the latch event position for the postmaster death event, is initialized under IsUnderPostmaster. WaitLatch() considered it as a valid wait target in single-user mode (!IsUnderPostmaster), which was incorrect. One code path found to fail with an assertion failure is a database drop in single-user mode while waiting in WaitForProcSignalBarrier() after the drop. Oversight in commit 84e5b2f07a5e. Author: Patrick Stählin Co-authored-by: Ronan Dunklau Discussion: https://postgr.es/m/18996-3a2744c814048...@postgresql.org Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/641f20d4c433b66df2928408fb2b44bd165c2329 Modified Files -- src/backend/storage/ipc/latch.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-)
pgsql: Fix background worker not restarting after crash-and-restart cyc
Fix background worker not restarting after crash-and-restart cycle. Previously, if a background worker crashed (e.g., due to a SIGKILL) and the server restarted due to restart_after_crash being enabled, the worker was not restarted as expected. Background workers without the never-restart flag should automatically restart in this case. This issue was introduced in commit 28a520c0b77, which failed to reset the rw_pid field in the RegisteredBgWorker struct for the crashed worker. This commit fixes the problem by resetting rw_pid for all eligible background workers during the crash-and-restart cycle. Back-patched to v18, where the bug was introduced. Bug fix patches were proposed by Andrey Rudometov and ChangAo Chen, but this commit uses a different approach. Reported-by: Andrey Rudometov Reported-by: ChangAo Chen Author: Andrey Rudometov Author: ChangAo Chen Co-authored-by: Fujii Masao Reviewed-by: ChangAo Chen Reviewed-by: Shveta Malik Discussion: https://postgr.es/m/CAF6JsWiO=i24qyitwe6ns1sxqcl86ryxdyu+pnyk-wuekps...@mail.gmail.com Discussion: https://postgr.es/m/tencent_e00a056b3953ee6440f0f40f80ec30427...@qq.com Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b5d084c5353f29e2e217dfa86f327e14d02998c1 Modified Files -- src/backend/postmaster/bgworker.c | 1 + src/backend/postmaster/postmaster.c | 7 +++ 2 files changed, 8 insertions(+)
pgsql: Refactor grammar to create opt_utility_option_list
Refactor grammar to create opt_utility_option_list This changes the grammar for REINDEX, CHECKPOINT, CLUSTER, ANALYZE/ANALYSE; they still accept the same options as before, but the grammar is written differently for convenience of future development. Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/202507231538.ir7pjzoow6oe@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1dfe3ef3f960d6924eb1f18facf4fbdae6e1cc1d Modified Files -- src/backend/parser/gram.y | 124 +- 1 file changed, 56 insertions(+), 68 deletions(-)
pgsql: Fix background worker not restarting after crash-and-restart cyc
Fix background worker not restarting after crash-and-restart cycle. Previously, if a background worker crashed (e.g., due to a SIGKILL) and the server restarted due to restart_after_crash being enabled, the worker was not restarted as expected. Background workers without the never-restart flag should automatically restart in this case. This issue was introduced in commit 28a520c0b77, which failed to reset the rw_pid field in the RegisteredBgWorker struct for the crashed worker. This commit fixes the problem by resetting rw_pid for all eligible background workers during the crash-and-restart cycle. Back-patched to v18, where the bug was introduced. Bug fix patches were proposed by Andrey Rudometov and ChangAo Chen, but this commit uses a different approach. Reported-by: Andrey Rudometov Reported-by: ChangAo Chen Author: Andrey Rudometov Author: ChangAo Chen Co-authored-by: Fujii Masao Reviewed-by: ChangAo Chen Reviewed-by: Shveta Malik Discussion: https://postgr.es/m/CAF6JsWiO=i24qyitwe6ns1sxqcl86ryxdyu+pnyk-wuekps...@mail.gmail.com Discussion: https://postgr.es/m/tencent_e00a056b3953ee6440f0f40f80ec30427...@qq.com Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/75f633f54aaae4d20ea0ade9a953afa73e3a66e8 Modified Files -- src/backend/postmaster/bgworker.c | 1 + src/backend/postmaster/postmaster.c | 7 +++ 2 files changed, 8 insertions(+)
pgsql: Reap the benefits of not having to avoid leaking PGresults.
Reap the benefits of not having to avoid leaking PGresults. Remove a bunch of PG_TRY constructs, de-volatilize related variables, remove some PQclear calls in error paths. Aside from making the code simpler and shorter, this should provide some marginal performance gains. For ease of review, I did not re-indent code within the removed PG_TRY constructs. That'll be done in a separate patch. Author: Tom Lane Reviewed-by: Matheus Alcantara Discussion: https://postgr.es/m/2976982.1748049...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/80aa9848befc13c188d2775a859deaf172fdd3a2 Modified Files -- contrib/dblink/dblink.c| 96 contrib/postgres_fdw/connection.c | 52 ++- contrib/postgres_fdw/postgres_fdw.c| 163 + contrib/postgres_fdw/postgres_fdw.h| 2 +- .../libpqwalreceiver/libpqwalreceiver.c| 31 +--- src/include/libpq/libpq-be-fe-helpers.h| 13 +- 6 files changed, 83 insertions(+), 274 deletions(-)
pgsql: Create infrastructure to reliably prevent leakage of PGresults.
Create infrastructure to reliably prevent leakage of PGresults. Commit 232d8caea fixed a case where postgres_fdw could lose track of a PGresult object, resulting in a process-lifespan memory leak. But I have little faith that there aren't other potential PGresult leakages, now or in future, in the backend modules that use libpq. Therefore, this patch proposes infrastructure that makes all PGresults returned from libpq act as though they are palloc'd in the CurrentMemoryContext (with the option to relocate them to another context later). This should greatly reduce the risk of careless leaks, and it also permits removal of a bunch of code that attempted to prevent such leaks via PG_TRY blocks. This patch adds infrastructure that wraps each PGresult in a "libpqsrv_PGresult" that provides a memory context reset callback to PQclear the PGresult. Code using this abstraction is inherently memory-safe to the same extent as we are accustomed to in most backend code. Furthermore, we add some macros that automatically redirect calls of the libpq functions concerned with PGresults to use this infrastructure, so that almost no source-code changes are needed to wheel this infrastructure into place in all the backend code that uses libpq. Perhaps in future we could create similar infrastructure for PGconn objects, but there seems less need for that. This patch just creates the infrastructure and makes relevant code use it, including reverting 232d8caea in favor of this mechanism. A good deal of follow-on simplification is possible now that we don't have to be so cautious about freeing PGresults, but I'll put that in a separate patch. Author: Tom Lane Reviewed-by: Matheus Alcantara Discussion: https://postgr.es/m/2976982.1748049...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7d8f5957792421ec3bb9d1b9b6ca25d689d974b7 Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 36 ++--- contrib/postgres_fdw/postgres_fdw.h | 2 +- src/backend/utils/mmgr/mcxt.c | 39 - src/include/libpq/libpq-be-fe-helpers.h | 27 ++-- src/include/libpq/libpq-be-fe.h | 259 src/include/utils/palloc.h | 2 + src/tools/pgindent/typedefs.list| 1 + 7 files changed, 322 insertions(+), 44 deletions(-)
pgsql: Silence leakage complaint about postgres_fdw's InitPgFdwOptions.
Silence leakage complaint about postgres_fdw's InitPgFdwOptions. Valgrind complains that the PQconninfoOption array returned by libpq is leaked. We apparently believed that we could suppress that warning by storing that array's address in a static variable. However, modern C compilers are bright enough to optimize the static variable away. We could escalate that arms race by making the variable global. But on the whole it seems better to revise the code so that it can free libpq's result properly. The only thing that costs us is copying the parameter-name keywords; which seems like a pretty negligible cost in a function that runs at most once per process. Author: Tom Lane Reviewed-by: Matheus Alcantara Discussion: https://postgr.es/m/2976982.1748049...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0f9d4d7c12dcebe951061763ca23ee3b6477e7ca Modified Files -- contrib/postgres_fdw/option.c | 33 - 1 file changed, 12 insertions(+), 21 deletions(-)
pgsql: Run pgindent on the changes of the previous patch.
Run pgindent on the changes of the previous patch. This step can be checked mechanically. Author: Tom Lane Reviewed-by: Matheus Alcantara Discussion: https://postgr.es/m/2976982.1748049...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/73873805fb3627cb23937c750fa83ffd8f16fc6c Modified Files -- contrib/dblink/dblink.c | 180 contrib/postgres_fdw/connection.c | 188 - contrib/postgres_fdw/postgres_fdw.c | 703 src/include/libpq/libpq-be-fe-helpers.h | 38 +- 4 files changed, 553 insertions(+), 556 deletions(-)
pgsql: Fix dynahash's HASH_FIXED_SIZE ("isfixed") option.
Fix dynahash's HASH_FIXED_SIZE ("isfixed") option.
This flag was effectively a no-op in EXEC_BACKEND (ie, Windows)
builds, because it was kept in the process-local HTAB struct,
and it could only ever become set in the postmaster's copy.
The simplest fix is to move it to the shared HASHHDR struct.
We could keep a copy in HTAB as well, as we do with keysize
and some other fields, but the "too much contention" argument
doesn't seem to apply here: we only examine isfixed during
element_alloc(), which had better not get hit very often for
a shared hashtable.
This oversight dates to 7c797e719 which invented the option.
But back-patching doesn't seem appropriate given the lack of
field complaints. If there is anyone running an affected
workload on Windows, they might be unhappy about the behavior
changing in a minor release.
Author: Aidar Imamov
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/4d0cb35ff01c5c74d2b9a582ecb73...@postgrespro.ru
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/5457ea46d181f8b8dbe1ae482720b23bff4029de
Modified Files
--
src/backend/utils/hash/dynahash.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
pgsql: Add commit 73873805f to .git-blame-ignore-revs.
Add commit 73873805f to .git-blame-ignore-revs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/db6461b1c9aae122b90bb52430f06efb306b371a Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)
