pgsql: Silence meson warning about PG_TEST_EXTRA in src/Makefile.global
Silence meson warning about PG_TEST_EXTRA in src/Makefile.global.in Commit 99b937a44f introduced this warning when you run "meson setup": Configuring Makefile.global using configuration ../src/meson.build:31: WARNING: The variable(s) 'PG_TEST_EXTRA' in the input file 'src/Makefile.global.in' are not present in the given configuration data. To fix, add PG_TEST_EXTRA to the list of variables that are not needed in the makefiles generated by meson. In meson builds, the makefiles are only used for PGXS, not for building or testing the server itself. Reported-by: Peter Eisentraut Discussion: https://www.postgresql.org/message-id/5c380997-e270-425a-9542-e4ef36a28...@eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e54688030cfe6fd2b3f9b7f437f2f3a4b75a6b35 Modified Files -- src/makefiles/meson.build | 1 + 1 file changed, 1 insertion(+)
Re: pgsql: Make PG_TEST_EXTRA env var override the "meson setup" option
On 05/11/2024 11:16, Peter Eisentraut wrote: On 04.11.24 13:25, Heikki Linnakangas wrote: Make PG_TEST_EXTRA env var override the "meson setup" option I see this warning flying by: Configuring Makefile.global using configuration ../src/meson.build:31: WARNING: The variable(s) 'PG_TEST_EXTRA' in the input file 'src/Makefile.global.in' are not present in the given configuration data. Fixed in commit e54688030c, thanks! -- Heikki Linnakangas Neon (https://neon.tech)
pgsql: docs: Consistently use to indicate optional parameter
docs: Consistently use to indicate optional parameters Some functions were using square brackets instead, replace them all with . Author: Dagfinn Ilmari Mannsåker Reviewed-by: jian he Discussion: https://www.postgresql.org/message-id/flat/cacjufxffubsph5uusszbl4sitbupuw%3deccpkgeazrjtrppu...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0d829703363ba70844ff545ccc73befb2a7fed2e Modified Files -- doc/src/sgml/func.sgml | 48 1 file changed, 24 insertions(+), 24 deletions(-)
pgsql: Split ProcSleep function into JoinWaitQueue and ProcSleep
Split ProcSleep function into JoinWaitQueue and ProcSleep Split ProcSleep into two functions: JoinWaitQueue and ProcSleep. JoinWaitQueue is called while holding the partition lock, and inserts the current process to the wait queue, while ProcSleep() does the actual sleeping. ProcSleep() is now called without holding the partition lock, and it no longer re-acquires the partition lock before returning. That makes the wakeup a little cheaper. Once upon a time, re-acquiring the partition lock was needed to prevent a signal handler from longjmping out at a bad time, but these days our signal handlers just set flags, and longjmping can only happen at points where we explicitly run CHECK_FOR_INTERRUPTS(). If JoinWaitQueue detects an "early deadlock" before even joining the wait queue, it returns without changing the shared lock entry, leaving the cleanup of the shared lock entry to the caller. This makes the handling of an early deadlock the same as the dontWait=true case. One small user-visible side-effect of this refactoring is that we now only set the 'ps' title to say "waiting" when we actually enter the sleep, not when the lock is skipped because dontWait=true, or when a deadlock is detected early before entering the sleep. This eliminates the 'lockAwaited' global variable in proc.c, which was largely redundant with 'awaitedLock' in lock.c Note: Updating the local lock table is now the caller's responsibility. JoinWaitQueue and ProcSleep are now only responsible for modifying the shared state. Seems a little nicer that way. Based on Thomas Munro's earlier patch and observation that ProcSleep doesn't really need to re-acquire the partition lock. Reviewed-by: Maxim Orlov Discussion: https://www.postgresql.org/message-id/7c2090cd-a72a-4e34-afaa-6dd2ef314...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3c0fd64fec8ed6fa3987c33f076fcffbc3f268c3 Modified Files -- src/backend/storage/lmgr/lock.c | 216 +--- src/backend/storage/lmgr/proc.c | 144 +-- src/backend/tcop/postgres.c | 2 +- src/include/storage/lock.h | 2 + src/include/storage/proc.h | 7 +- 5 files changed, 185 insertions(+), 186 deletions(-)
pgsql: Move TRACE calls into WaitOnLock()
Move TRACE calls into WaitOnLock() LockAcquire is a long and complex function. Pushing more stuff to its subroutines makes it a little more manageable. Reviewed-by: Maxim Orlov Discussion: https://www.postgresql.org/message-id/7c2090cd-a72a-4e34-afaa-6dd2ef314...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ae0897e42416d8954f0340ba7eca6275ed8c8b7 Modified Files -- src/backend/storage/lmgr/lock.c | 29 ++--- 1 file changed, 14 insertions(+), 15 deletions(-)
pgsql: Set MyProc->heldLocks in ProcSleep
Set MyProc->heldLocks in ProcSleep Previously, ProcSleep()'s caller was responsible for setting MyProc->heldLocks, and we had comments to remind about that. But it seems simpler to make ProcSleep() itself responsible for it. ProcSleep() already set the other info about the lock its waiting for (waitLock, waitProcLock and waitLockMode), so it is natural for it to set heldLocks too. Reviewed-by: Maxim Orlov Discussion: https://www.postgresql.org/message-id/7c2090cd-a72a-4e34-afaa-6dd2ef314...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0464f25b6aa156228982efd46303e8c8dd25 Modified Files -- src/backend/storage/lmgr/lock.c | 8 src/backend/storage/lmgr/proc.c | 11 +++ 2 files changed, 7 insertions(+), 12 deletions(-)
pgsql: Fix comment in LockReleaseAll() on when locallock->nLock can be
Fix comment in LockReleaseAll() on when locallock->nLock can be zero We reach this case also e.g. when a deadlock is detected, not only when we run out of memory. Reviewed-by: Maxim Orlov Discussion: https://www.postgresql.org/message-id/7c2090cd-a72a-4e34-afaa-6dd2ef314...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1fe0466cf2cbb909b6553061620b6a6779319406 Modified Files -- src/backend/storage/lmgr/lock.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
pgsql: Make PG_TEST_EXTRA env var override the "meson setup" option
Make PG_TEST_EXTRA env var override the "meson setup" option "meson test" used to ignore the PG_TEST_EXTRA environment variable, which meant that in order to run additional tests, you had to run "meson setup -DPG_TEST_EXTRA=...". That's somewhat expensive, and not consistent with autoconf builds. Allow PG_TEST_EXTRA environment variable to override the setup-time option at run time, so that you can do "PG_TEST_EXTRA=... meson test". To implement this, the configuration time value is passed as an extra "--pg-test-extra" argument to testwrap instead of adding it to the test environment. If the environment variable is set at the time of running test, testwrap uses the value from the environment variable and ignores the --pg-test-extra option. Now that "meson test" obeys the environment variable, we can remove it from the "meson setup" steps in the CI script. It will now be picked up from the environment variable like with "make check". Author: Nazir Bilal Yavuzk, Ashutosh Bapat Reviewed-by: Ashutosh Bapat with inputs from Tom Lane and Andrew Dunstan Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3d1aec225ac4a1199079150dabfd0d34c5054127 Modified Files -- .cirrus.tasks.yml | 6 +- doc/src/sgml/installation.sgml | 10 +++--- meson.build| 10 +- meson_options.txt | 2 +- src/tools/testwrap | 10 ++ 5 files changed, 24 insertions(+), 14 deletions(-)
pgsql: Add PG_TEST_EXTRA configure option to the Make builds
Add PG_TEST_EXTRA configure option to the Make builds The Meson builds have PG_TEST_EXTRA as a configure-time variable, which was not available in the Make builds. To ensure both build systems are in sync, PG_TEST_EXTRA is now added as a configure-time variable. It can be set like this: ./configure PG_TEST_EXTRA="kerberos, ssl, ..." Note that to preserve the old behavior, this configure-time variable is overridden by the PG_TEST_EXTRA environment variable when you run the tests. Author: Jacob Champion Reviewed by: Ashutosh Bapat, Nazir Bilal Yavuz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/99b937a44f087c133c4db42e1bf4a8990ea417b9 Modified Files -- configure | 6 ++ configure.ac | 2 ++ src/Makefile.global.in | 10 ++ src/test/Makefile | 5 - 4 files changed, 18 insertions(+), 5 deletions(-)
pgsql: Rename two functions that wake up other processes
Rename two functions that wake up other processes Instead of talking about setting latches, which is a pretty low-level mechanism, emphasize that they wake up other processes. This is in preparation for replacing Latches with a new abstraction. That's still work in progress, but this seems a little tidier anyway, so let's get this refactoring out of the way already. Discussion: https://www.postgresql.org/message-id/391abe21-413e-4d91-a650-b663af49500c%40iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/368d8270c838a6c328fc24418603cb172b5e0390 Modified Files -- src/backend/access/transam/xlog.c | 4 ++-- src/backend/access/transam/xlogrecovery.c | 2 +- src/backend/access/transam/xlogwait.c | 2 +- src/backend/postmaster/walsummarizer.c| 4 ++-- src/include/access/xlogwait.h | 2 +- src/include/postmaster/walsummarizer.h| 2 +- 6 files changed, 8 insertions(+), 8 deletions(-)
pgsql: Use ProcNumbers instead of direct Latch pointers to address othe
Use ProcNumbers instead of direct Latch pointers to address other procs This is in preparation for replacing Latches with a new abstraction. That's still work in progress, but this seems a little tidier anyway, so let's get this refactoring out of the way already. Discussion: https://www.postgresql.org/message-id/391abe21-413e-4d91-a650-b663af49500c%40iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9c546a5a3783810a1b665f246fc6d0a596d0606 Modified Files -- src/backend/access/transam/xlog.c | 10 ++-- src/backend/access/transam/xlogwait.c | 15 ++-- src/backend/postmaster/checkpointer.c | 16 + src/backend/postmaster/walwriter.c | 6 ++--- .../libpqwalreceiver/libpqwalreceiver.c| 1 + src/backend/replication/walreceiver.c | 16 ++--- src/backend/replication/walreceiverfuncs.c | 11 + src/backend/storage/lmgr/proc.c| 4 ++-- src/include/access/xlogwait.h | 9 +++- src/include/replication/walreceiver.h | 27 +++--- src/include/storage/proc.h | 12 ++ 11 files changed, 72 insertions(+), 55 deletions(-)
pgsql: Fix refreshing physical relfilenumber on shared index
Fix refreshing physical relfilenumber on shared index Buildfarm member 'prion', which is configured with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE, failed with errors like this: ERROR: could not read blocks 0..0 in file "global/2672": read only 0 of 8192 bytes while running a parallel test group that includes VACUUM FULL on some catalog tables among other things. I was not able to reproduce that just by running the tests with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE, even though 'prion' hit it on first run after commit 2b9b8ebbf8, so there might be something else that makes it more susceptible to the race. However, I was able to reproduce it by adding another test to the same test group that runs "vacuum full pg_database" repeatedly. The problem is that RelationReloadIndexInfo() no longer calls RelationInitPhysicalAddr() on a nailed, shared index, when an invalidation happens early during backend startup, before the critical relcaches have been built. Before commit 2b9b8ebbf8, that was done by RelationReloadNailed(), but it went missing from that path. Add it back as an explicit step. Broken by commit 2b9b8ebbf8, which refactored these functions. Discussion: https://www.postgresql.org/message-id/db876575-8f5b-4193-a538-df7e1f92d47a%40iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b82c877e76e2398409e823773413079668cf1881 Modified Files -- src/backend/utils/cache/relcache.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)
pgsql: Simplify call to rebuild relcache entry for indexes
Simplify call to rebuild relcache entry for indexes RelationClearRelation(rebuild == true) calls RelationReloadIndexInfo() for indexes. We can rely on that in RelationIdGetRelation(), instead of calling RelationReloadIndexInfo() directly. That simplifies the code a little. In the passing, add a comment in RelationBuildLocalRelation() explaining why it doesn't call RelationInitIndexAccessInfo(). It's because at index creation, it's called before the pg_index row has been created. That's also the reason that RelationClearRelation() still needs a special case to go through the full-blown rebuild if the index support information in the relcache entry hasn't been populated yet. Reviewed-by: jian he Discussion: https://www.postgresql.org/message-id/9c9e8908-7b3e-4ce7-85a8-00c0e165a3d6%40iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8e2e2662214a0a6d0fb23a070ea78d691d8ced43 Modified Files -- src/backend/utils/cache/relcache.c | 41 -- 1 file changed, 17 insertions(+), 24 deletions(-)
pgsql: Split RelationClearRelation into three different functions
Split RelationClearRelation into three different functions The old RelationClearRelation function did different things depending on the arguments and circumstances. It could: a) remove the relation completely from relcache (rebuild == false), b) mark the entry as invalid (rebuild == true, but not in xact), or c) rebuild the entry (rebuild == true). Different callers used it for different purposes, and often assumed a particular behavior, which was confusing. Split it into three different functions, one for each of the above actions (one of them, RelationInvalidateRelation, was already added in commit e6cd857726). Move the responsibility of choosing the action and calling the right function to the callers. Reviewed-by: jian he Discussion: https://www.postgresql.org/message-id/9c9e8908-7b3e-4ce7-85a8-00c0e165a3d6%40iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2b9b8ebbf8a2f621d1cecc4db759700f9ce6ce66 Modified Files -- src/backend/utils/cache/relcache.c | 305 + 1 file changed, 136 insertions(+), 169 deletions(-)
pgsql: Fix overflow in bsearch_arg() with more than INT_MAX elements
Fix overflow in bsearch_arg() with more than INT_MAX elements This was introduced in commit bfa2cee784, which replaced the old bsearch_cmp() function we had in extended_stats.c with the current implementation. The original discussion or commit message of bfa2cee784 didn't mention where the new implementation came from, but based on some googling, I'm guessing *BSD or libiberty, all of which share this same code, with or without this fix. Author: Ranier Vilela Reviewed-by: Nathan Bossart Backpatch-through: 14 Discussion: https://www.postgresql.org/message-id/CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi%2Bw%40mail.gmail.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/22b914121ad898cd2f5f935240f9e1334479e25f Modified Files -- src/port/bsearch_arg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix overflow in bsearch_arg() with more than INT_MAX elements
Fix overflow in bsearch_arg() with more than INT_MAX elements This was introduced in commit bfa2cee784, which replaced the old bsearch_cmp() function we had in extended_stats.c with the current implementation. The original discussion or commit message of bfa2cee784 didn't mention where the new implementation came from, but based on some googling, I'm guessing *BSD or libiberty, all of which share this same code, with or without this fix. Author: Ranier Vilela Reviewed-by: Nathan Bossart Backpatch-through: 14 Discussion: https://www.postgresql.org/message-id/CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi%2Bw%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/07ca2d4110d474669fa03203782b5dae24f1c5c6 Modified Files -- src/port/bsearch_arg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix overflow in bsearch_arg() with more than INT_MAX elements
Fix overflow in bsearch_arg() with more than INT_MAX elements This was introduced in commit bfa2cee784, which replaced the old bsearch_cmp() function we had in extended_stats.c with the current implementation. The original discussion or commit message of bfa2cee784 didn't mention where the new implementation came from, but based on some googling, I'm guessing *BSD or libiberty, all of which share this same code, with or without this fix. Author: Ranier Vilela Reviewed-by: Nathan Bossart Backpatch-through: 14 Discussion: https://www.postgresql.org/message-id/CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi%2Bw%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/de5afddc3ba4aa41f341f62347ce40bb9ea9d78b Modified Files -- src/port/bsearch_arg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix overflow in bsearch_arg() with more than INT_MAX elements
Fix overflow in bsearch_arg() with more than INT_MAX elements This was introduced in commit bfa2cee784, which replaced the old bsearch_cmp() function we had in extended_stats.c with the current implementation. The original discussion or commit message of bfa2cee784 didn't mention where the new implementation came from, but based on some googling, I'm guessing *BSD or libiberty, all of which share this same code, with or without this fix. Author: Ranier Vilela Reviewed-by: Nathan Bossart Backpatch-through: 14 Discussion: https://www.postgresql.org/message-id/CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi%2Bw%40mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/55327256a049e3926d4d1cda39a7bb5886cbe03c Modified Files -- src/port/bsearch_arg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix overflow in bsearch_arg() with more than INT_MAX elements
Fix overflow in bsearch_arg() with more than INT_MAX elements This was introduced in commit bfa2cee784, which replaced the old bsearch_cmp() function we had in extended_stats.c with the current implementation. The original discussion or commit message of bfa2cee784 didn't mention where the new implementation came from, but based on some googling, I'm guessing *BSD or libiberty, all of which share this same code, with or without this fix. Author: Ranier Vilela Reviewed-by: Nathan Bossart Backpatch-through: 14 Discussion: https://www.postgresql.org/message-id/CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi%2Bw%40mail.gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/211e6a5b2b26ce99098146f67cd89220429b3613 Modified Files -- src/port/bsearch_arg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Restore missing line to copyright notice
Restore missing line to copyright notice Commit 12c9423832 in May 2003 accidentally removed the last line of the copyright notice in getopt.c. Put it back. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/22bb889f7080d5a2596df2276ccbdb1ace1e4673 Modified Files -- src/port/getopt.c | 1 + 1 file changed, 1 insertion(+)
Re: pgsql: Implement pg_wal_replay_wait() stored procedure
On 25/10/2024 14:56, Alexander Korotkov wrote:
I see that pg_wal_replay_wait_status() might look weird, but it seems
to me like the best of feasible solutions.
I haven't written many procedures, but our docs say:
> Procedures do not return a function value; hence CREATE PROCEDURE
lacks a RETURNS clause. However, procedures can instead return data to
their callers via output parameters.
Did you consider using an output parameter?
Given that
pg_wal_replay_wait() procedure can't work concurrently to a query
involving pg_wal_replay_wait_status() function, I think
pg_wal_replay_wait_status() should be stable and parallel safe.
If you call pg_wal_replay_wait() in the backend process, and
pg_wal_replay_wait_status() in a parallel worker process, it won't
return the result of the wait. Probably not what you'd expect. So I'd
argue that it should be parallel unsafe.
This is the brief answer. I will be able to come back with more
details on Monday.
Thanks. A few more minor issues I spotted while playing with this:
- If you pass a very high value as the timeout, e.g. INT_MAX-1, it wraps
around and doesn't wait at all
- You can pass NULLs as arguments. That should probably not be allowed,
or we need to document what it means.
This is disappointing:
postgres=# set default_transaction_isolation ='repeatable read';
SET
postgres=# call pg_wal_replay_wait('0/55DA24F');
ERROR: pg_wal_replay_wait() must be only called without an active or
registered snapshot
DETAIL: Make sure pg_wal_replay_wait() isn't called within a transaction with
an isolation level higher than READ COMMITTED, another procedure, or a function.
Is there any way we could make that work? Otherwise, the feature just
basically doesn't work if you use repeatable read.
--
Heikki Linnakangas
Neon (https://neon.tech)
Re: pgsql: Implement pg_wal_replay_wait() stored procedure
If you call this procedure on a stand-alone server, you get:
postgres=# call pg_wal_replay_wait('1234/0');
ERROR: recovery is not in progress
DETAIL: Recovery ended before replaying target LSN 1234/0; last replay
LSN 0/0.
The DETAIL seems a bit misleading. Recovery never ended, because it
never started in the first place. Last replay LSN is indeed 0/0, but
that's not helpful.
If a standby server has been promoted and you pass an LSN that's earlier
than the last replay LSN, it returns successfully. That makes sense I
guess; if you connect to a standby and wait for it to replay a commit
that you made in the primary, and the standby gets promoted, that seems
correct. But it's a little inconsistent: If the standby crashes
immediately after promotion, and you call pg_wal_replay_wait() after
recovery, it returns success. However, if you shut down the promoted
server and restart it, then last replay LSN is 0/0, and the call will
fail because no recovery happened.
What is the use case for the 'no_error' argument? Why would you ever
want to pass no_error=true ? The separate pg_wal_replay_wait_status()
function feels weird to me. Also it surely shouldn't be marked IMMUTABLE
nor parallel safe.
This would benefit from more documentation, explaining how you would use
this in practice. I believe the use case is that you want "read your
writes" consistency between a primary and a standby. You commit a
transaction in the primary, and you then want to run read-only queries
in a standby, and you want to make sure that you see your own commit,
but you're ok with slightly delayed results otherwise. It would be good
to add a chapter somewhere in the docs to show how to do that in
practice with these functions.
--
Heikki Linnakangas
Neon (https://neon.tech)
pgsql: Update outdated comment on WAL-logged locks with invalid XID
Update outdated comment on WAL-logged locks with invalid XID We haven't generated those for a long time. Discussion: https://www.postgresql.org/message-id/b439edfc-c5e5-43a9-802d-4cb51ec20...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3c7d78427ea9d92d346ee9aada4fa483bd1059e8 Modified Files -- src/backend/storage/ipc/standby.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e607a5a4be54f2d2bdfb7a53584d4b7ca1d2be3 Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/520ec2474b392805ca4d7f29205e245ac70ea0e1 Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e2ec3afebc238e281df7f3f435c243d9c300046d Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/22665f2106248793cfd8dd0a49fe3c5f7a4bfdfe Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d97419b851f87c318c2e188afa9c669b5538010e Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/234f6d09e531b3b5b021ce9574737219a6ac844b Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Fix race condition in committing a serializable transaction
Fix race condition in committing a serializable transaction The finished transaction list can contain XIDs that are older than the serializable global xmin. It's a short-lived state; ClearOldPredicateLocks() removes any such transactions from the list, and it's called whenever the global xmin advances. But if another backend calls SummarizeOldestCommittedSxact() in that window, it will call SerialAdd() on an XID that's older than the global xmin, or if there are no more transactions running, when global xmin is invalid. That trips the assertion in SerialAdd(). Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin for analysis. Backpatch to all versions. Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1a43de5e0a591b66ef3d92f3fac5aefcc2dc02fe Modified Files -- src/backend/storage/lmgr/predicate.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-)
pgsql: Mark consume_xids test functions VOLATILE and PARALLEL UNSAFE
Mark consume_xids test functions VOLATILE and PARALLEL UNSAFE Both functions advance the transaction ID, which modifies the system state. Thus, they should be marked as VOLATILE. Additionally, they call the AssignTransactionId function, which cannot be invoked in parallel mode, so they should be marked as PARALLEL UNSAFE. Author: Yushi Ogiwara Discussion: https://www.postgresql.org/message-id/18f01e4fd46448f88c7a1363050a9...@oss.nttdata.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/add77755ce851fae2f72be4b9c56a606f9362895 Modified Files -- src/test/modules/xid_wraparound/xid_wraparound--1.0.sql | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix typo and run pgperltidy on newly-added test
Fix typo and run pgperltidy on newly-added test From commit 85ec945b78. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/05d1b9b5c286424dea2a91cf906c49c9d22ff4bf Modified Files -- src/test/postmaster/t/001_connection_limits.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Add test for dead-end backends
Add test for dead-end backends The code path for launching a dead-end backend because we're out of slots was not covered by any tests, so add one. (Some tests did hit the case of launching a dead-end backend because the server is still starting up, though, so the gap in our test coverage wasn't as big as it sounds.) Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/85ec945b7880931cb506392101cb0b00209b78ba Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 78 ++ src/test/postmaster/t/001_connection_limits.pl | 42 +- 2 files changed, 119 insertions(+), 1 deletion(-)
pgsql: Add test for connection limits
Add test for connection limits Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6a1d0d470e84f960a50cbe0cd1e2eee4b8c9baa5 Modified Files -- src/test/Makefile | 2 +- src/test/meson.build | 1 + src/test/postmaster/Makefile | 23 src/test/postmaster/README | 27 + src/test/postmaster/meson.build| 12 src/test/postmaster/t/001_connection_limits.pl | 79 ++ 6 files changed, 143 insertions(+), 1 deletion(-)
pgsql: Use an shmem_exit callback to remove backend from PMChildFlags o
Use an shmem_exit callback to remove backend from PMChildFlags on exit This seems nicer than having to duplicate the logic between InitProcess() and ProcKill() for which child processes have a PMChildFlags slot. Move the MarkPostmasterChildActive() call earlier in InitProcess(), out of the section protected by the spinlock. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2bbc261ddbdfee2def5d14ee9fcc09c70bdf84e6 Modified Files -- src/backend/storage/ipc/pmsignal.c | 17 + src/backend/storage/lmgr/proc.c| 38 +- src/include/storage/pmsignal.h | 3 +-- 3 files changed, 27 insertions(+), 31 deletions(-)
pgsql: Remove unneeded #include
Remove unneeded #include Unneeded since commit d72731a704. Discussion: https://www.postgresql.org/message-id/391abe21-413e-4d91-a650-b663af495...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/094ae071605d938c46b440b4c27b11f73a241422 Modified Files -- src/include/storage/buf_internals.h | 1 - 1 file changed, 1 deletion(-)
pgsql: Clean up WaitLatch calls that passed latch without WL_LATCH_SET
Clean up WaitLatch calls that passed latch without WL_LATCH_SET The 'latch' argument is ignored if WL_LATCH_SET is not given. Clarify these calls by not pointlessly passing MyLatch. Discussion: https://www.postgresql.org/message-id/391abe21-413e-4d91-a650-b663af495...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f9ecb57a506ada358baa19287d2c438ad01cdbce Modified Files -- src/backend/libpq/be-secure-gssapi.c | 4 ++-- src/backend/libpq/be-secure-openssl.c | 2 +- src/backend/postmaster/walsummarizer.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)
pgsql: Remove unused latch
Remove unused latch It was left unused by commit bc971f4025, which replaced the latch usage with a condition variable Discussion: https://www.postgresql.org/message-id/391abe21-413e-4d91-a650-b663af495...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6c0c49f7d37dc29775947ac6edbc494c32f43fa6 Modified Files -- src/backend/replication/walsender.c | 3 --- src/include/replication/walsender_private.h | 7 --- 2 files changed, 10 deletions(-)
pgsql: Refactor lock manager initialization to make it a bit less speci
Refactor lock manager initialization to make it a bit less special Split the shared and local initialization to separate functions, and follow the common naming conventions. With this, we no longer create the LockMethodLocalHash hash table in the postmaster process, which was always pointless. Reviewed-by: Andreas Karlsson Discussion: https://www.postgresql.org/message-id/c09694ff-2453-47e5-b26c-32a16cd75...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fbce7dfc77eaa0d017dfee78c9d27b142d435e41 Modified Files -- src/backend/storage/ipc/ipci.c| 4 ++-- src/backend/storage/lmgr/lock.c | 35 +-- src/backend/utils/init/postinit.c | 3 +++ src/include/storage/lock.h| 5 +++-- 4 files changed, 25 insertions(+), 22 deletions(-)
pgsql: Rename some shared memory initialization routines
Rename some shared memory initialization routines To make them follow the usual naming convention where FoobarShmemSize() calculates the amount of shared memory needed by Foobar subsystem, and FoobarShmemInit() performs the initialization. I didn't rename CreateLWLocks() and InitShmmeIndex(), because they are a little special. They need to be called before any of the other ShmemInit() functions, because they set up the shared memory bookkeeping itself. I also didn't rename InitProcGlobal(), because unlike other Shmeminit functions, it's not called by individual backends. Reviewed-by: Andreas Karlsson Discussion: https://www.postgresql.org/message-id/c09694ff-2453-47e5-b26c-32a16cd75...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/478846e7688c9ab73d2695a66822e9ae0574b551 Modified Files -- src/backend/storage/buffer/buf_init.c | 6 +++--- src/backend/storage/buffer/bufmgr.c | 2 +- src/backend/storage/buffer/freelist.c | 2 +- src/backend/storage/ipc/ipci.c | 14 +++--- src/backend/storage/ipc/procarray.c | 4 ++-- src/backend/storage/ipc/sinvaladt.c | 10 +- src/backend/storage/lmgr/predicate.c| 6 +++--- src/backend/utils/activity/backend_status.c | 4 ++-- src/backend/utils/init/postinit.c | 2 +- src/include/storage/bufmgr.h| 6 +++--- src/include/storage/predicate.h | 2 +- src/include/storage/procarray.h | 2 +- src/include/storage/sinvaladt.h | 4 ++-- src/include/utils/backend_status.h | 2 +- 14 files changed, 33 insertions(+), 33 deletions(-)
pgsql: Fix garbled process name on backend crash
Fix garbled process name on backend crash The log message on backend crash used wrong variable, which could be uninitialized. Introduced in commit 28a520c0b7. Reported-by: Alexander Lakhin Discussion: https://www.postgresql.org/message-id/451b0797-83b8-cdbc-727f-8d7a7b0e3...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/56d23855c864b7384970724f3ad93fb0fc319e51 Modified Files -- src/backend/postmaster/postmaster.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Relax fsyncing at end of a bulk load that was not WAL-logged
Relax fsyncing at end of a bulk load that was not WAL-logged And improve the comments. Backpatch to v17 where this was introduced. Reviewed-by: Noah Misch Discussion: https://www.postgresql.org/message-id/cac7d1b6-8358-40be-af0b-21bc9b27d...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/077ad4bd76b12cd4144e40ef5fba3f49528fa5e4 Modified Files -- src/backend/storage/smgr/bulk_write.c | 72 +-- 1 file changed, 61 insertions(+), 11 deletions(-)
pgsql: Relax fsyncing at end of a bulk load that was not WAL-logged
Relax fsyncing at end of a bulk load that was not WAL-logged And improve the comments. Backpatch to v17 where this was introduced. Reviewed-by: Noah Misch Discussion: https://www.postgresql.org/message-id/cac7d1b6-8358-40be-af0b-21bc9b27d...@iki.fi Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/68f199cea3b190ba0bc2c83d92d17e7e1792a141 Modified Files -- src/backend/storage/smgr/bulk_write.c | 72 +-- 1 file changed, 61 insertions(+), 11 deletions(-)
pgsql: Refactor CopyOneRowTo
Refactor CopyOneRowTo The handling of binary and text formats are quite different here, so it's more clear to check for the format first and have two separate loops. Author: jian he Reviewed-by: Ilia Evdokimov, Junwang Zhao Discussion: https://www.postgresql.org/message-id/cacjufxfzhcefbqf0m%2bsgk_nwknwuq4ou7ts1isvebrbhcko...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3943da46bc54006ec4849bc7541cf4e674b700eb Modified Files -- src/backend/commands/copyto.c | 39 --- 1 file changed, 20 insertions(+), 19 deletions(-)
pgsql: Remove unused 'cur_skey' argument from IndexScanOK()
Remove unused 'cur_skey' argument from IndexScanOK() Commit a78fcfb51243 removed the last use of it. Author: Hugo Zhang, Aleksander Alekseev Reviewed-by: Daniel Gustafsson Discussion: https://www.postgresql.org/message-id/NT0PR01MB129459E243721B954611938F9CDD2%40NT0PR01MB1294.CHNPR01.prod.partner.outlook.cn Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1153422edac5d27eeffd61fca2be348fa0714ce9 Modified Files -- src/backend/utils/cache/catcache.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix bad indentation introduced in commit f011e82c2c
Fix bad indentation introduced in commit f011e82c2c Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8de5ca1dc9fa809102acd1983ee19159d0bc469f Modified Files -- src/backend/access/transam/xlogprefetcher.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Consolidate postmaster code to launch background processes
Consolidate postmaster code to launch background processes Much of the code in process_pm_child_exit() to launch replacement processes when one exits or when progressing to next postmaster state was unnecessary, because the ServerLoop will launch any missing background processes anyway. Remove the redundant code and let ServerLoop handle it. In ServerLoop, move the code to launch all the processes to a new subroutine, to group it all together. Reviewed-by: Thomas Munro Discussion: https://www.postgresql.org/message-id/8f2118b9-79e3-4af7-b2c9-bd5818193...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3354f85284dc5439c25b57e002e62a88490aca1e Modified Files -- src/backend/postmaster/postmaster.c | 279 1 file changed, 122 insertions(+), 157 deletions(-)
pgsql: Initialize HASHCTL differently, to suppress Coverity warning
Initialize HASHCTL differently, to suppress Coverity warning Coverity complained that the hash_create() call might access hash_table_ctl->hctl. That's a false alarm, hash_create() only accesses that field when passed the HASH_SHARED_MEM flag. Try to silence it by using a plain local variable instead of a const. That's how the HASHCTL is initialized in all the other hash_create() calls. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f011e82c2c886329245f821146c560a3607f7aba Modified Files -- src/backend/access/transam/xlogprefetcher.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-)
pgsql: Fix comment on processes being kept over a restart
Fix comment on processes being kept over a restart All child processes except the syslogger are killed on a restart. The archiver might be already running though, if it was started during recovery. The split in the comments between "other special children" and the first group of "background tasks" seemed really arbitrary, so I just merged them all into one group. Reviewed-by: Thomas Munro Discussion: https://www.postgresql.org/message-id/8f2118b9-79e3-4af7-b2c9-bd5818193...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a79ed10e6c6b43cc43a51a5f5bcc29252b4bb6dc Modified Files -- src/backend/postmaster/postmaster.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-)
pgsql: Refactor code to handle death of a backend or bgworker in postma
Refactor code to handle death of a backend or bgworker in postmaster Currently, when a child process exits, the postmaster first scans through BackgroundWorkerList, to see if it the child process was a background worker. If not found, then it scans through BackendList to see if it was a regular backend. That leads to some duplication between the bgworker and regular backend cleanup code, as both have an entry in the BackendList that needs to be cleaned up in the same way. Refactor that so that we scan just the BackendList to find the child process, and if it was a background worker, do the additional bgworker-specific cleanup in addition to the normal Backend cleanup. Change HandleChildCrash so that it doesn't try to handle the cleanup of the process that already exited, only the signaling of all the other processes. When called for any of the aux processes, the caller had already cleared the *PID global variable, so the code in HandleChildCrash() to do that was unused. On Windows, if a child process exits with ERROR_WAIT_NO_CHILDREN, it's now logged with that exit code, instead of 0. Also, if a bgworker exits with ERROR_WAIT_NO_CHILDREN, it's now treated as crashed and is restarted. Previously it was treated as a normal exit. If a child process is not found in the BackendList, the log message now calls it "untracked child process" rather than "server process". Arguably that should be a PANIC, because we do track all the child processes in the list, so failing to find a child process is highly unexpected. But if we want to change that, let's discuss and do that as a separate commit. Reviewed-by: Thomas Munro Discussion: https://www.postgresql.org/message-id/835232c0-a5f7-4f20-b95b-5b56ba57d...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/28a520c0b77325a97bafd0f57cc7bd0dd523b71e Modified Files -- src/backend/postmaster/bgworker.c | 4 - src/backend/postmaster/postmaster.c | 439 +++- src/include/postmaster/bgworker_internals.h | 7 +- 3 files changed, 170 insertions(+), 280 deletions(-)
pgsql: Make BackgroundWorkerList doubly-linked
Make BackgroundWorkerList doubly-linked This allows ForgetBackgroundWorker() and ReportBackgroundWorkerExit() to take a RegisteredBgWorker pointer as argument, rather than a list iterator. That feels a little more natural. But more importantly, this paves the way for more refactoring in the next commit. Reviewed-by: Thomas Munro Discussion: https://www.postgresql.org/message-id/835232c0-a5f7-4f20-b95b-5b56ba57d...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b43100fa71d7f21751b0b1b9b84833be95336386 Modified Files -- src/backend/postmaster/bgworker.c | 62 ++--- src/backend/postmaster/postmaster.c | 40 +-- src/include/postmaster/bgworker_internals.h | 10 ++--- 3 files changed, 54 insertions(+), 58 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e8240dbd86f70e268ebda57c07eb98bd80a4e6f0 Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c943e2aae7c59c673d502bbb243b57469be4c75f Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/49dc191bd1ae30180597c33e7f75a9950b896ccc Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bb5592caceded690451869ac098b55dbb2142dfc Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b5a5027c9796e2958392f4682928d47b5b0d0e47 Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8b86e289f7f0db1b1b95c33c880c26393ecd414e Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Fix pg_rewind debug output to print the source timeline history
Fix pg_rewind debug output to print the source timeline history getTimelineHistory() is called twice, to read the source and the target timeline history files. However, the loop to print the file with the --debug option used the wrong variable when dealing with the source. As a result, the source's history was always printed as empty. Spotted while debugging bug #18575, but this does not fix that bug, just the debugging output. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/092dd515-b7b4-4fd0-8407-ceca2f02f...@iki.fi Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a7bf3e66852743503eb32cb38d93c0740dcca00a Modified Files -- src/bin/pg_rewind/pg_rewind.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)
pgsql: Make fallback MD5 implementation thread-safe on big-endian syste
Make fallback MD5 implementation thread-safe on big-endian systems Replace a static scratch buffer with a local variable, because a static buffer makes the function not thread-safe. This function is used in client-code in libpq, so it needs to be thread-safe. It was until commit b67b57a966, which replaced the implementation with the one from pgcrypto. Backpatch to v14, where we switched to the new implementation. Reviewed-by: Robert Haas, Michael Paquier Discussion: https://www.postgresql.org/message-id/dfa2015d-ad21-4802-a4cc-3850fc5ff...@iki.fi Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7696b2ea52416cc2f4046a359d3b6f760e4c013d Modified Files -- src/common/md5.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
pgsql: Make fallback MD5 implementation thread-safe on big-endian syste
Make fallback MD5 implementation thread-safe on big-endian systems Replace a static scratch buffer with a local variable, because a static buffer makes the function not thread-safe. This function is used in client-code in libpq, so it needs to be thread-safe. It was until commit b67b57a966, which replaced the implementation with the one from pgcrypto. Backpatch to v14, where we switched to the new implementation. Reviewed-by: Robert Haas, Michael Paquier Discussion: https://www.postgresql.org/message-id/dfa2015d-ad21-4802-a4cc-3850fc5ff...@iki.fi Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a38f5f880d1e86fedf1616de5391df5f0d5e4239 Modified Files -- src/common/md5.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
pgsql: Make fallback MD5 implementation thread-safe on big-endian syste
Make fallback MD5 implementation thread-safe on big-endian systems Replace a static scratch buffer with a local variable, because a static buffer makes the function not thread-safe. This function is used in client-code in libpq, so it needs to be thread-safe. It was until commit b67b57a966, which replaced the implementation with the one from pgcrypto. Backpatch to v14, where we switched to the new implementation. Reviewed-by: Robert Haas, Michael Paquier Discussion: https://www.postgresql.org/message-id/dfa2015d-ad21-4802-a4cc-3850fc5ff...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2676040df0b2ebbcf8af759dbe5d34f393c3d5b5 Modified Files -- src/common/md5.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
pgsql: Make fallback MD5 implementation thread-safe on big-endian syste
Make fallback MD5 implementation thread-safe on big-endian systems Replace a static scratch buffer with a local variable, because a static buffer makes the function not thread-safe. This function is used in client-code in libpq, so it needs to be thread-safe. It was until commit b67b57a966, which replaced the implementation with the one from pgcrypto. Backpatch to v14, where we switched to the new implementation. Reviewed-by: Robert Haas, Michael Paquier Discussion: https://www.postgresql.org/message-id/dfa2015d-ad21-4802-a4cc-3850fc5ff...@iki.fi Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0583863e9e6e9ce412bf82658d691370336fa9c0 Modified Files -- src/common/md5.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
pgsql: Make fallback MD5 implementation thread-safe on big-endian syste
Make fallback MD5 implementation thread-safe on big-endian systems Replace a static scratch buffer with a local variable, because a static buffer makes the function not thread-safe. This function is used in client-code in libpq, so it needs to be thread-safe. It was until commit b67b57a966, which replaced the implementation with the one from pgcrypto. Backpatch to v14, where we switched to the new implementation. Reviewed-by: Robert Haas, Michael Paquier Discussion: https://www.postgresql.org/message-id/dfa2015d-ad21-4802-a4cc-3850fc5ff...@iki.fi Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ffac8ac48e409bbc7c2d9a4b37a1c39908ca24eb Modified Files -- src/common/md5.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)
pgsql: Mark misc static global variables as const
Mark misc static global variables as const Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/54c29fb0-edf2-48ea-9814-44e918bbd...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fe8dd65bf28db1a6ad690ffcd5124d1863b5a4c6 Modified Files -- contrib/btree_gist/btree_interval.c | 2 +- contrib/oid2name/oid2name.c | 2 +- src/backend/access/transam/xlogprefetcher.c | 2 +- src/common/sha1.c | 2 +- src/pl/plpython/plpy_cursorobject.c | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
pgsql: Make nullSemAction const, add 'const' decorators to related func
Make nullSemAction const, add 'const' decorators to related functions To make it more clear that these should never be modified. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/54c29fb0-edf2-48ea-9814-44e918bbd...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/85829c973cb33592dbc0b0f3aaf9132f5dea6953 Modified Files -- src/backend/utils/adt/jsonfuncs.c | 2 +- src/common/jsonapi.c | 26 +++--- src/include/common/jsonapi.h | 6 ++--- src/include/utils/jsonfuncs.h | 2 +- .../test_json_parser_incremental.c | 2 +- 5 files changed, 19 insertions(+), 19 deletions(-)
pgsql: Turn a few 'validnsps' static variables into locals
Turn a few 'validnsps' static variables into locals There was no need for these to be static buffers, local variables work just as well. I think they were marked as 'static' to imply that they are read-only, but 'const' is more appropriate for that, so change them to const. To make it possible to mark the variables as 'const', also add 'const' decorations to the transformRelOptions() signature. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/54c29fb0-edf2-48ea-9814-44e918bbd...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1e35951e71d37ab6716fa55ba399fbe6df4a7417 Modified Files -- src/backend/access/common/reloptions.c | 2 +- src/backend/commands/createas.c| 2 +- src/backend/commands/tablecmds.c | 4 ++-- src/backend/tcop/utility.c | 2 +- src/include/access/reloptions.h| 2 +- 5 files changed, 6 insertions(+), 6 deletions(-)
pgsql: Constify fields and parameters in spell.c
Constify fields and parameters in spell.c I started by marking VoidString as const, and fixing the fallout by marking more fields and function arguments as const. It proliferated quite a lot, but all within spell.c and spell.h. A more narrow patch to get rid of the static VoidString buffer would be to replace it with '#define VoidString ""', as C99 allows assigning "" to a non-const pointer, even though you're not allowed to modify it. But it seems like good hygiene to mark all these as const. In the structs, the pointers can point to the constant VoidString, or a buffer allocated with palloc(), or with compact_palloc(), so you should not modify them. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/54c29fb0-edf2-48ea-9814-44e918bbd...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d5f139cb6814f0af2d2e1106899361e45c305630 Modified Files -- src/backend/tsearch/spell.c | 58 +-- src/include/tsearch/dicts/spell.h | 16 +-- 2 files changed, 39 insertions(+), 35 deletions(-)
pgsql: Use psprintf to simplify gtsvectorout()
Use psprintf to simplify gtsvectorout()
The buffer allocation was correct, but looked archaic and scary:
- It was weird to calculate the buffer size before determining which
format string was used. With the same effort, we could've used the
right-sized buffer for each branch.
- Commit aa0d3504560 added one more possible return string ("all true
bits"), but didn't adjust the code at the top of the function to
calculate the returned string's max size. It was not a live bug,
because the new string was smaller than the existing ones, but
seemed wrong in principle.
- Use of sprintf() is generally eyebrow-raising these days
Switch to psprintf(). psprintf() allocates a larger buffer than what
was allocated before, 128 bytes vs 80 bytes, which is acceptable as
this code is not performance or space critical.
Reviewed-by: Andres Freund
Discussion:
https://www.postgresql.org/message-id/54c29fb0-edf2-48ea-9814-44e918bbd...@iki.fi
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3ab2668d48476e31d8809fbb36c9ee739cc444e1
Modified Files
--
src/backend/utils/adt/tsgistidx.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
pgsql: Fix datatypes in comments in instr_time.h
Fix datatypes in comments in instr_time.h The INSTR_TIME_GET_NANOSEC(t) and INSTR_TIME_GET_MICROSEC(t) macros return a signed int64. Discussion: https://www.postgresql.org/message-id/zrhkv3maqfwns...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a54d4ed183927f15e1853b83106acebe11c8 Modified Files -- src/include/portability/instr_time.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Revert "Fix comments in instr_time.h and remove an unneeded cast
Revert "Fix comments in instr_time.h and remove an unneeded cast to int64" This reverts commit 3dcb09de7b. Tom Lane pointed out that it broke the abstraction provided by the macros. The callers should not need to know what the internal type is. This commit is an exact revert, the next commit will fix the comments on the macros that incorrectly claim that they return uint64. Discussion: https://www.postgresql.org/message-id/zrhkv3maqfwns...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/39a138fbef87803ab7fe494243c1ba36a093a0e8 Modified Files -- src/include/portability/instr_time.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix comments in instr_time.h and remove an unneeded cast to int6
Fix comments in instr_time.h and remove an unneeded cast to int64 03023a2664 represented time as an int64 on all platforms but forgot to update the comment related to INSTR_TIME_GET_MICROSEC() and provided an incorrect comment for INSTR_TIME_GET_NANOSEC(). In passing remove an unneeded cast to int64. Author: Bertrand Drouvot Discussion: https://www.postgresql.org/message-id/zrhkv3maqfwns...@ip-10-97-1-34.eu-west-3.compute.internal Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3dcb09de7bb21c75d4df48263561af324fd099a4 Modified Files -- src/include/portability/instr_time.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Minor refactoring of assign_backendlist_entry()
Minor refactoring of assign_backendlist_entry() Make assign_backendlist_entry() responsible just for allocating the Backend struct. Linking it to the RegisteredBgWorker is the caller's responsibility now. Seems more clear that way. Discussion: https://www.postgresql.org/message-id/835232c0-a5f7-4f20-b95b-5b56ba57d...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/63bef4df975cd8b0a3fee1384a80c569043a6d72 Modified Files -- src/backend/postmaster/postmaster.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-)
pgsql: Fix outdated comment; all running bgworkers are in BackendList
Fix outdated comment; all running bgworkers are in BackendList Before commit 8a02b3d732, only bgworkers that connected to a database had an entry in the Backendlist. Commit 8a02b3d732 changed that, but forgot to update this comment. Discussion: https://www.postgresql.org/message-id/835232c0-a5f7-4f20-b95b-5b56ba57d...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ef4c35b4166e3c99558eba1bc324b2fde61d6ed5 Modified Files -- src/include/postmaster/bgworker_internals.h | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: Refactor getWeights to write to caller-supplied buffer
Refactor getWeights to write to caller-supplied buffer This gets rid of the static result buffer. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f822be39629cd24a8ad1f8f6aa444e0c9ae1eaad Modified Files -- src/backend/utils/adt/tsrank.c | 53 -- 1 file changed, 31 insertions(+), 22 deletions(-)
pgsql: Replace static buf with palloc in str_time()
Replace static buf with palloc in str_time() The function is used only once in the startup process, so the leak into current memory context is harmless. This is a tiny step in making the server thread-safe. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6151cb7876136ad23748f4f724309166bbfad3e0 Modified Files -- src/backend/access/transam/xlog.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Replace static buf with a stack-allocated one in ReadControlFile
Replace static buf with a stack-allocated one in ReadControlFile It's only used very locally within the function. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/da8a587e2e225be1ccf838a330e342bda6848874 Modified Files -- src/backend/access/transam/xlog.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Replace static bufs with a StringInfo in cash_words()
Replace static bufs with a StringInfo in cash_words() For clarity. The code was correct, and the buffer was large enough, but string manipulation with no bounds checking is scary. This incurs an extra palloc+pfree to every call, but in quick performance testing, it doesn't seem to be significant. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5bf948d564e36553d2a1cda3244a52d054238af4 Modified Files -- src/backend/utils/adt/cash.c | 85 +++- 1 file changed, 44 insertions(+), 41 deletions(-)
pgsql: Replace static buf with a stack-allocated one in 'seg' extension
Replace static buf with a stack-allocated one in 'seg' extension The buffer is used only locally within the function. Also, the initialization to '0' characters was unnecessary, the initial content were always overwritten with sprintf(). I don't understand why it was done that way, but it's been like that since forever. In the passing, change from sprintf() to snprintf(). The buffer was long enough so sprintf() was fine, but this makes it more obvious that there's no risk of a buffer overflow. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/7f86e06a-98c5-4ce3-8ec9-3885c8de0...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01e51ed78070703c7e078f1519ad59af38e2888a Modified Files -- contrib/seg/segparse.y | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-)
pgsql: Remove leftover function declaration
Remove leftover function declaration Commit 9d9b9d46f3 removed the function (or rather, moved it to a different source file and renamed it to SendCancelRequest), but forgot the declaration in the header file. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/47c98035c6fbff01724b9a646196c92b99faa6bf Modified Files -- src/include/postmaster/postmaster.h | 2 -- 1 file changed, 2 deletions(-)
Re: pgsql: Remove --disable-spinlocks.
On 30/07/2024 14:03, Thomas Munro wrote: Remove --disable-spinlocks. Sorry, spotted this only now: --- a/src/backend/postmaster/launch_backend.c +++ b/src/backend/postmaster/launch_backend.c @@ -108,9 +108,7 @@ typedef struct #ifdef USE_INJECTION_POINTS struct InjectionPointsCtl *ActiveInjectionPoints; #endif -#ifndef HAVE_SPINLOCKS PGSemaphore *SpinlockSemaArray; -#endif int NamedLWLockTrancheRequests; NamedLWLockTranche *NamedLWLockTrancheArray; LWLockPadded *MainLWLockArray; The SpinLockSemaArray field should be completely completely, nut just the #ifndef guard around it. -- Heikki Linnakangas Neon (https://neon.tech)
pgsql: Detach syslogger from shared memory
Detach syslogger from shared memory Commit aafc05de1b removed the calls to detach from shared memory from syslogger startup. That was not intentional, so put them back. Author: Rui Zhao Reviewed-by: Aleksander Alekseev Backpatch-through: 17 Discussion: https://www.postgresql.org/message-id/11505016-8cf3-4691-b996-7faed99b7877.xiyuan...@alibaba-inc.com Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f208a16035fc5d18cee0e7e2fbf176616905f9b0 Modified Files -- src/backend/postmaster/launch_backend.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-)
pgsql: Detach syslogger from shared memory
Detach syslogger from shared memory Commit aafc05de1b removed the calls to detach from shared memory from syslogger startup. That was not intentional, so put them back. Author: Rui Zhao Reviewed-by: Aleksander Alekseev Backpatch-through: 17 Discussion: https://www.postgresql.org/message-id/11505016-8cf3-4691-b996-7faed99b7877.xiyuan...@alibaba-inc.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6a1d8cef46e654bdc645e9c32412f707471aff2a Modified Files -- src/backend/postmaster/launch_backend.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-)
pgsql: Remove dead generators for cyrillic encoding conversion tables
Remove dead generators for cyrillic encoding conversion tables These tools were used to read the koi-iso.tab, koi-win.tab, and koi-alt.tab files, which contained the mappings between the single-byte cyrillic encodings. However, those data files were removed in commit 4c3c8c048d, back in 2003. These code generators have been unused and unusable ever since. The generated tables live in cyrillic_and_mic.c. There has been one change to the tables since they were generated in 1999, in commit f4b7624eb07a. So if we resurrected the original data tables, that change would need to be taken into account. So this code is very dead. The tables in cyrillic_and_mic.c, which were originally generated by these tools, are now the authoritative source for these mappings. Reviewed-by: Tom Lane, Aleksander Alekseev Discussion: https://www.postgresql.org/message-id/flat/a821c3dc-36ec-4cee-8b41-7ccaa17ad...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/679f940740f42f2401f72a6b95dc02b9c0ab3f30 Modified Files -- src/backend/utils/mb/README| 3 -- src/backend/utils/mb/iso.c | 74 -- src/backend/utils/mb/win1251.c | 74 -- src/backend/utils/mb/win866.c | 74 -- 4 files changed, 225 deletions(-)
Re: pgsql: Move cancel key generation to after forking the backend
On 29/07/2024 17:30, Heikki Linnakangas wrote: On 29/07/2024 16:25, Heikki Linnakangas wrote: On 29/07/2024 16:23, Daniel Gustafsson wrote: On 29 Jul 2024, at 15:18, Heikki Linnakangas wrote: Move cancel key generation to after forking the backend longfin seems a tad sad about this one: procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition] } ProcSignalHeader; ^ ../../../../src/include/storage/procsignal.h:77:33: note: previous definition is here typedef struct ProcSignalHeader ProcSignalHeader; ^ 1 error generated. make[4]: *** [procsignal.o] Error 1 Yep, thanks, just noticed and fixed it myself. I should add that to the list of compiler options I use... The --disable-spinlocks animals are still failing, however. Weird. I can reproduce it locally, and started to debug but I have no clue what's wrong. I'll keep debugging, but I'm all ears if anyone has ideas. Found & fixed. I released the spinlock twice in EmitProcSignalBarrier. Oops. I'm a little surprised there isn't an assertion for that. Would be useful. This might have gone unnoticed for a long time if not for the --disable-spinlocks implementation, and we've been talking about removing that. -- Heikki Linnakangas Neon (https://neon.tech)
pgsql: Fix double-release of spinlock
Fix double-release of spinlock Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal flags, but in EmitProcSignalBarrier(), the spinlock was released twice. With most spinlock implementations, releasing a lock that's not held is not easy to notice, because most of the time it does nothing, but if the spinlock was concurrently acquired by another process, it could lead to more serious issues. Fortunately, with the --disable-spinlocks emulation implementation, it caused more visible failures. In the passing, fix a type in comment and add an assertion that the procNumber passed to SendProcSignal looks valid. Discussion: https://www.postgresql.org/message-id/b8ce284c-18a2-4a79-afd3-1991a2e7d...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0393f542d72c6182271c392d9a83d0fc775113c7 Modified Files -- src/backend/storage/ipc/procsignal.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
Re: pgsql: Move cancel key generation to after forking the backend
On 29/07/2024 16:25, Heikki Linnakangas wrote: On 29/07/2024 16:23, Daniel Gustafsson wrote: On 29 Jul 2024, at 15:18, Heikki Linnakangas wrote: Move cancel key generation to after forking the backend longfin seems a tad sad about this one: procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition] } ProcSignalHeader; ^ ../../../../src/include/storage/procsignal.h:77:33: note: previous definition is here typedef struct ProcSignalHeader ProcSignalHeader; ^ 1 error generated. make[4]: *** [procsignal.o] Error 1 Yep, thanks, just noticed and fixed it myself. I should add that to the list of compiler options I use... The --disable-spinlocks animals are still failing, however. Weird. I can reproduce it locally, and started to debug but I have no clue what's wrong. I'll keep debugging, but I'm all ears if anyone has ideas. -- Heikki Linnakangas Neon (https://neon.tech)
Re: pgsql: Move cancel key generation to after forking the backend
On 29/07/2024 16:23, Daniel Gustafsson wrote: On 29 Jul 2024, at 15:18, Heikki Linnakangas wrote: Move cancel key generation to after forking the backend longfin seems a tad sad about this one: procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition] } ProcSignalHeader; ^ ../../../../src/include/storage/procsignal.h:77:33: note: previous definition is here typedef struct ProcSignalHeader ProcSignalHeader; ^ 1 error generated. make[4]: *** [procsignal.o] Error 1 Yep, thanks, just noticed and fixed it myself. I should add that to the list of compiler options I use... -- Heikki Linnakangas Neon (https://neon.tech)
pgsql: Fix compiler warning/error about typedef redefinitions
Fix compiler warning/error about typedef redefinitions Per buildfarm member 'sifaka': procsignal.c:87:3: error: redefinition of typedef 'ProcSignalHeader' is a C11 feature [-Werror,-Wtypedef-redefinition] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8bda213ec1628737b500b6b04ec164aec354eb04 Modified Files -- src/backend/storage/ipc/procsignal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Move cancel key generation to after forking the backend
Move cancel key generation to after forking the backend Move responsibility of generating the cancel key to the backend process. The cancel key is now generated after forking, and the backend advertises it in the ProcSignal array. When a cancel request arrives, the backend handling it scans the ProcSignal array to find the target pid and cancel key. This is similar to how this previously worked in the EXEC_BACKEND case with the ShmemBackendArray, just reusing the ProcSignal array. One notable change is that we no longer generate cancellation keys for non-backend processes. We generated them before just to prevent a malicious user from canceling them; the keys for non-backend processes were never actually given to anyone. There is now an explicit flag indicating whether a process has a valid key or not. I wrote this originally in preparation for supporting longer cancel keys, but it's a nice cleanup on its own. Reviewed-by: Jelte Fennema-Nio Discussion: https://www.postgresql.org/message-id/508d0505-8b7a-4864-a681-e7e5edfe3...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9d9b9d46f3c509c722ebbf2a1e7dc6296a6c711d Modified Files -- src/backend/postmaster/auxprocess.c | 2 +- src/backend/postmaster/launch_backend.c | 10 +- src/backend/postmaster/postmaster.c | 196 +--- src/backend/storage/ipc/ipci.c | 11 -- src/backend/storage/ipc/procsignal.c| 185 +++--- src/backend/tcop/backend_startup.c | 9 +- src/backend/tcop/postgres.c | 17 +++ src/backend/utils/init/globals.c| 3 +- src/backend/utils/init/postinit.c | 2 +- src/include/miscadmin.h | 1 + src/include/postmaster/postmaster.h | 9 -- src/include/storage/procsignal.h| 10 +- 12 files changed, 193 insertions(+), 262 deletions(-)
pgsql: Fix outdated comment in smgrtruncate()
Fix outdated comment in smgrtruncate() Commit c5315f4f44 replaced smgr_fsm_nblocks and smgr_vm_nblocks with smgr_cached_nblocks, but forgot to update this comment. Author: Kirill Reshke Discussion: https://www.postgresql.org/message-id/caldssph9va6sdsvjrcmspeyramf%2brfisk7gqjo1dtrnd3vd...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/19de089cdc23373e2f36916017a1e23e8ff4c2f8 Modified Files -- src/backend/storage/smgr/smgr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fallback to uuid for ossp-uuid with meson
Fallback to uuid for ossp-uuid with meson The upstream name for the ossp-uuid package / pkg-config file is "uuid". Many distributions change this to be "ossp-uuid" to not conflict with e2fsprogs. This lookup fails on distributions which don't change this name, for example NixOS / nixpkgs. Both "ossp-uuid" and "uuid" are also checked in configure.ac. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/469b97c52413adc85bab7d7ee6e0a9cb5adddf30 Modified Files -- meson.build | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Support absolute bindir/libdir in regression tests with meson
Support absolute bindir/libdir in regression tests with meson
Passing an absolute bindir/libdir will install the binaries and
libraries to /tmp_install/ and
/tmp_install/ respectively.
This path is correctly passed to the regression test suite via
configure/make, but not via meson, yet. This is because the "/"
operator in the following expression throws away the whole left side
when the right side is an absolute path:
test_install_location / get_option('libdir')
This was already correctly handled for dir_prefix, which is likely
absolute as well. This patch handles both bindir and libdir in the
same way - prefixing absolute paths with the tmp_install path
correctly.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion:
https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de
Backpatch: 16-, where meson support was added
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7f61882b638a7c4caa88137d964d04052829dd38
Modified Files
--
meson.build | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
pgsql: Fallback to clang in PATH with meson
Fallback to clang in PATH with meson Some distributions put clang into a different path than the llvm binary path. For example, this is the case on NixOS / nixpkgs, which failed to find clang with meson before this patch. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/23be5206327cc09a870db346545f7a6a9e2485b3 Modified Files -- meson.build | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Fallback to uuid for ossp-uuid with meson
Fallback to uuid for ossp-uuid with meson The upstream name for the ossp-uuid package / pkg-config file is "uuid". Many distributions change this to be "ossp-uuid" to not conflict with e2fsprogs. This lookup fails on distributions which don't change this name, for example NixOS / nixpkgs. Both "ossp-uuid" and "uuid" are also checked in configure.ac. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a00fae9d43e5adabc56e64a4df6d332062666501 Modified Files -- meson.build | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fallback to clang in PATH with meson
Fallback to clang in PATH with meson Some distributions put clang into a different path than the llvm binary path. For example, this is the case on NixOS / nixpkgs, which failed to find clang with meson before this patch. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4d8de281b5834c8f5e0be6ae21e884e69dffd4ce Modified Files -- meson.build | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Support falling back to non-preferred readline implementation wi
Support falling back to non-preferred readline implementation with meson To build with -Dreadline=enabled one can use either readline or libedit. The -Dlibedit_preferred flag is supposed to control the order of names to lookup. This works fine when either both libraries are present or -Dreadline is set to auto. However, explicitly enabling readline with only libedit present, but not setting libedit_preferred, or alternatively enabling readline with only readline present, but setting libedit_preferred, too, are both broken. This is because cc.find_library will throw an error for a not found dependency as soon as the first required dependency is checked, thus it's impossible to fallback to the alternative. Here we only check the second of the two dependencies for requiredness, thus we only fail when none of the two can be found. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/67427f10093a9c50c79e1dbfdcd1698433e8a88f Modified Files -- meson.build | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-)
pgsql: Support falling back to non-preferred readline implementation wi
Support falling back to non-preferred readline implementation with meson To build with -Dreadline=enabled one can use either readline or libedit. The -Dlibedit_preferred flag is supposed to control the order of names to lookup. This works fine when either both libraries are present or -Dreadline is set to auto. However, explicitly enabling readline with only libedit present, but not setting libedit_preferred, or alternatively enabling readline with only readline present, but setting libedit_preferred, too, are both broken. This is because cc.find_library will throw an error for a not found dependency as soon as the first required dependency is checked, thus it's impossible to fallback to the alternative. Here we only check the second of the two dependencies for requiredness, thus we only fail when none of the two can be found. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1091f8e0a48bf934e73260501799ce49405c67cf Modified Files -- meson.build | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-)
pgsql: Support absolute bindir/libdir in regression tests with meson
Support absolute bindir/libdir in regression tests with meson
Passing an absolute bindir/libdir will install the binaries and
libraries to /tmp_install/ and
/tmp_install/ respectively.
This path is correctly passed to the regression test suite via
configure/make, but not via meson, yet. This is because the "/"
operator in the following expression throws away the whole left side
when the right side is an absolute path:
test_install_location / get_option('libdir')
This was already correctly handled for dir_prefix, which is likely
absolute as well. This patch handles both bindir and libdir in the
same way - prefixing absolute paths with the tmp_install path
correctly.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion:
https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de
Backpatch: 16-, where meson support was added
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ff34ae368bdb11f9f66e22a4d79e2a179b3a6f0e
Modified Files
--
meson.build | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
pgsql: Support absolute bindir/libdir in regression tests with meson
Support absolute bindir/libdir in regression tests with meson
Passing an absolute bindir/libdir will install the binaries and
libraries to /tmp_install/ and
/tmp_install/ respectively.
This path is correctly passed to the regression test suite via
configure/make, but not via meson, yet. This is because the "/"
operator in the following expression throws away the whole left side
when the right side is an absolute path:
test_install_location / get_option('libdir')
This was already correctly handled for dir_prefix, which is likely
absolute as well. This patch handles both bindir and libdir in the
same way - prefixing absolute paths with the tmp_install path
correctly.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion:
https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de
Backpatch: 16-, where meson support was added
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/eb6765d57cfabc63bdb02375ec2e788783b88a0f
Modified Files
--
meson.build | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
pgsql: Fallback to uuid for ossp-uuid with meson
Fallback to uuid for ossp-uuid with meson The upstream name for the ossp-uuid package / pkg-config file is "uuid". Many distributions change this to be "ossp-uuid" to not conflict with e2fsprogs. This lookup fails on distributions which don't change this name, for example NixOS / nixpkgs. Both "ossp-uuid" and "uuid" are also checked in configure.ac. Author: Wolfgang Walther Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut Reviewed-by: Tristan Partin Discussion: https://www.postgresql.org/message-id/ca8f37e1-a2c3-40e2-91f6-59c3d3652...@technowledgy.de Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cc90d7823a6e888f5a50b98367b315a055d16895 Modified Files -- meson.build | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
