pgsql: Evaluate arguments of correlated SubPlans in the referencing Exp
Evaluate arguments of correlated SubPlans in the referencing ExprState Until now we generated an ExprState for each parameter to a SubPlan and evaluated them one-by-one ExecScanSubPlan. That's sub-optimal as creating lots of small ExprStates a) makes JIT compilation more expensive b) wastes memory c) is a bit slower to execute This commit arranges to evaluate parameters to a SubPlan as part of the ExprState referencing a SubPlan, using the new EEOP_PARAM_SET expression step. We emit one EEOP_PARAM_SET for each argument to a subplan, just before the EEOP_SUBPLAN step. It likely is worth using EEOP_PARAM_SET in other places as well, e.g. for SubPlan outputs, nestloop parameters and - more ambitiously - to get rid of ExprContext->domainValue/caseValue/ecxt_agg*. But that's for later. Author: Andres Freund Reviewed-by: Tom Lane Reviewed-by: Alena Rybakina Discussion: https://postgr.es/m/20230225214401.346ancgjqc3zm...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a7f107df2b700c859e4d9ad2ca66b07a465d6223 Modified Files -- src/backend/executor/execExpr.c | 103 +++--- src/backend/executor/execExprInterp.c | 26 + src/backend/executor/execProcnode.c | 5 ++ src/backend/executor/nodeSubplan.c| 29 -- src/backend/jit/llvm/llvmjit_expr.c | 6 ++ src/backend/jit/llvm/llvmjit_types.c | 1 + src/include/executor/execExpr.h | 6 +- src/include/nodes/execnodes.h | 1 - 8 files changed, 125 insertions(+), 52 deletions(-)
Re: pgsql: Fix double-release of spinlock
On 2024-07-29 12:45:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-07-29 12:33:13 -0400, Tom Lane wrote:
> >> I dunno, is that the only extra check that the --disable-spinlocks
> >> implementation is providing?
>
> > I think it also provides the (valuable!) check that spinlocks were actually
> > initialized. But that again seems like something we'd be better off adding
> > more general infrastructure for - nobody runs --disable-spinlocks locally,
> > we
> > shouldn't need to run this on the buildfarm to find problems like this.
>
> Hmm, but how?
I think there's a few ways:
> One of the things we gave up by nuking HPPA support
> was that that platform's representation of an initialized, free
> spinlock was not all-zeroes, so that it'd catch this type of problem.
> I think all the remaining platforms do use zeroes, so it's hard to
> see how anything short of valgrind would be likely to catch it.
1) There's nothing forcing us to use 0/1 for most of the spinlock
implementations. E.g. for x86-64 we could use 0 for uninitialized, 1 for free
and 2 for locked.
2) We could also change the layout of slock_t in assert enabled builds, adding
a dedicated 'initialized' field when assertions are enabled. But that might be
annoying from an ABI POV?
1) seems preferrable, so I gave it a quick try. Seems to work. There's a
*slight* difference in the instruction sequence:
old:
41f6: f0 86 10lock xchg %dl,(%rax)
41f9: 84 d2 test %dl,%dl
41fb: 75 1b jne4218
new:
4216: f0 86 10lock xchg %dl,(%rax)
4219: 80 fa 02cmp$0x2,%dl
421c: 74 22 je 4240
I.e. the version using 2 as the locked state uses a three byte instruction vs
a two byte instruction before.
*If* we are worried about this, we could
a) Change the representation only for assert enabled builds, but that'd have
ABI issues again.
b) Instead define the spinlock to have 1 as the unlocked state and 0 as the
locked state. That makes it a bit harder to understand that initialization
is missing, compared to a dedicated state, as the first use of the spinlock
just blocks.
To make 1) b) easier to understand it might be worth changing the slock_t
typedef to be something like
typedef struct slock_t
{
char is_free;
} slock_t;
which also might help catch some cases of type confusion - the char typedef is
too forgiving imo.
Greetings,
Andres Freund
Re: pgsql: Fix double-release of spinlock
Hi, On 2024-07-29 12:33:13 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-07-29 11:31:56 -0400, Tom Lane wrote: > >> There was some recent discussion about getting rid of > >> --disable-spinlocks on the grounds that nobody would use > >> hardware that lacked native spinlocks. But now I wonder > >> if there is a testing/debugging reason to keep it. > > > Seems it'd be a lot more straightforward to just add an assertion to the > > x86-64 spinlock implementation verifying that the spinlock isn't already > > free? FWIW, I quickly hacked that up, and it indeed quickly fails with 0393f542d72^ and passes with 0393f542d72. > I dunno, is that the only extra check that the --disable-spinlocks > implementation is providing? I think it also provides the (valuable!) check that spinlocks were actually initialized. But that again seems like something we'd be better off adding more general infrastructure for - nobody runs --disable-spinlocks locally, we shouldn't need to run this on the buildfarm to find problems like this. > I'm kind of allergic to putting Asserts into spinlocked code segments, > mostly on the grounds that it violates the straight-line-code precept. > I suppose it's not really that bad for tests that you don't expect > to fail, but still ... I don't think the spinlock implementation itself is really affected by that rule - after all, the --disable-spinlocks implementation actually consists out of several layers of external function calls (including syscalls in some cases!). Greetings, Andres Freund
Re: pgsql: Fix double-release of spinlock
Hi, On 2024-07-29 11:31:56 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > 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. > > There was some recent discussion about getting rid of > --disable-spinlocks on the grounds that nobody would use > hardware that lacked native spinlocks. But now I wonder > if there is a testing/debugging reason to keep it. Seems it'd be a lot more straightforward to just add an assertion to the x86-64 spinlock implementation verifying that the spinlock isn't already free? Greetings, Andres Freund
pgsql: meson: Add missing argument to gssapi.h check
meson: Add missing argument to gssapi.h check These were missing since the initial introduction of the meson based build, in e6927270cd18. As-is this is unlikely to cause an issue, but a future commit will add support for detecting gssapi without use of dependency(), which could fail due to this. Discussion: https://postgr.es/m/20240708225659.gmyqoosi7km6y...@awork3.anarazel.de Backpatch: 16-, where the meson based build was added Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5b707bb507bdc9b8bf120db1a0f7dad4cdb78e46 Modified Files -- meson.build | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: meson: Add support for detecting gss without pkg-config
meson: Add support for detecting gss without pkg-config This is required as MIT Kerberos does provide neither pkg-config nor cmake dependency information on windows. Reported-by: Dave Page Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a850701c7ddfebc5c2bd528a9423739458212bc1 Modified Files -- meson.build | 50 -- 1 file changed, 44 insertions(+), 6 deletions(-)
pgsql: meson: Add support for detecting ossp-uuid without pkg-config
meson: Add support for detecting ossp-uuid without pkg-config This is necessary as ossp-uuid on windows installs neither a pkg-config nor a cmake dependency information. Nor is there another supported uuid implementation available on windows. Reported-by: Dave Page Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/793a5bebebbedd925311ba95cb77e3fb9b704200 Modified Files -- meson.build | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: meson: Add missing argument to gssapi.h check
meson: Add missing argument to gssapi.h check These were missing since the initial introduction of the meson based build, in e6927270cd18. As-is this is unlikely to cause an issue, but a future commit will add support for detecting gssapi without use of dependency(), which could fail due to this. Discussion: https://postgr.es/m/20240708225659.gmyqoosi7km6y...@awork3.anarazel.de Backpatch: 16-, where the meson based build was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cc50694c8d9604374c27f7a1899c4721031fc008 Modified Files -- meson.build | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: meson: Add dependency lookups via names used by cmake
meson: Add dependency lookups via names used by cmake Particularly on windows it's useful to look up dependencies via cmake, instead of pkg-config. Meson supports doing so. Unfortunately the dependency names used by various projects often differs between their pkg-config and cmake files. This would look a lot neater if we could rely on meson >= 0.60.0... Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5ec2c529f5537a5f5d5c929c49a5a2af2e4feda7 Modified Files -- meson.build | 46 -- 1 file changed, 40 insertions(+), 6 deletions(-)
pgsql: meson: Add dependency lookups via names used by cmake
meson: Add dependency lookups via names used by cmake Particularly on windows it's useful to look up dependencies via cmake, instead of pkg-config. Meson supports doing so. Unfortunately the dependency names used by various projects often differs between their pkg-config and cmake files. This would look a lot neater if we could rely on meson >= 0.60.0... Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9ac6995d6b1f11eefbf69b61bc4378b814d46dec Modified Files -- meson.build | 46 -- 1 file changed, 40 insertions(+), 6 deletions(-)
pgsql: meson: Add support for detecting gss without pkg-config
meson: Add support for detecting gss without pkg-config This is required as MIT Kerberos does provide neither pkg-config nor cmake dependency information on windows. Reported-by: Dave Page Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7ed2ce0b257fcceb37bec8520eb293c0522d8681 Modified Files -- meson.build | 50 -- 1 file changed, 44 insertions(+), 6 deletions(-)
pgsql: meson: Add support for detecting gss without pkg-config
meson: Add support for detecting gss without pkg-config This is required as MIT Kerberos does provide neither pkg-config nor cmake dependency information on windows. Reported-by: Dave Page Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2b4593379b818ee81193b113dab3acdc3191f08d Modified Files -- meson.build | 50 -- 1 file changed, 44 insertions(+), 6 deletions(-)
pgsql: meson: Add dependency lookups via names used by cmake
meson: Add dependency lookups via names used by cmake Particularly on windows it's useful to look up dependencies via cmake, instead of pkg-config. Meson supports doing so. Unfortunately the dependency names used by various projects often differs between their pkg-config and cmake files. This would look a lot neater if we could rely on meson >= 0.60.0... Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/13c58ca51883da23e0884dfeedf5e172d5eea80c Modified Files -- meson.build | 46 -- 1 file changed, 40 insertions(+), 6 deletions(-)
pgsql: meson: Add support for detecting ossp-uuid without pkg-config
meson: Add support for detecting ossp-uuid without pkg-config This is necessary as ossp-uuid on windows installs neither a pkg-config nor a cmake dependency information. Nor is there another supported uuid implementation available on windows. Reported-by: Dave Page Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2416fdb3ee30bdd2810408f93f14d47bff840fea Modified Files -- meson.build | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: meson: Add missing argument to gssapi.h check
meson: Add missing argument to gssapi.h check These were missing since the initial introduction of the meson based build, in e6927270cd18. As-is this is unlikely to cause an issue, but a future commit will add support for detecting gssapi without use of dependency(), which could fail due to this. Discussion: https://postgr.es/m/20240708225659.gmyqoosi7km6y...@awork3.anarazel.de Backpatch: 16-, where the meson based build was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c3dafaaac389b23721e20f493580fddac7c95528 Modified Files -- meson.build | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: meson: Add support for detecting ossp-uuid without pkg-config
meson: Add support for detecting ossp-uuid without pkg-config This is necessary as ossp-uuid on windows installs neither a pkg-config nor a cmake dependency information. Nor is there another supported uuid implementation available on windows. Reported-by: Dave Page Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20240709065101.xhc74r3mdg2lm...@awork3.anarazel.de Backpatch: 16-, where meson support was added Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1213875b3a994bcede9c302ac85745e709afdfab Modified Files -- meson.build | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/69bdee12e4437d3681de584de8ecced1fda4bcb5 Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9d3a2b3cdfbd1d6edbc828feecf979cb35d74091 Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/212b0262d60e921d97f1b824734d2c607e49fa6d Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/11441ad48d09740efd99edb654534cc4662b6ecc Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3006fd8e6ececbb5662135da77a61af311edf81e Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ff3cae4875d3391c591ac5d22693f27f056e62d2 Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix bad indentation introduced in 43cd30bcd1c
Fix bad indentation introduced in 43cd30bcd1c Oops. Reported-by: Nathan Bossart Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan Backpatch: 12-, like 43cd30bcd1c Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/47ecbfdfcc71e41d7dcc35f0be04f8adbe88397f Modified Files -- src/backend/utils/misc/guc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: ci: Use newer LLVM version with gcc, to avoid compiler warnings
ci: Use newer LLVM version with gcc, to avoid compiler warnings gcc emits a warning for LLVM 14 code outside of our control. To avoid that, update to a newer LLVM version. Do so both in the CompilerWarnings and normal tasks - the latter don't fail, but the warnings make it more likely that we'd miss other warnings. We might want to backpatch this eventually. The higher priority right now is to unbreak CI though - which is only broken on master, due to 0c3930d0768 interacting badly with c8a6ec206a9 (mea culpa, I should have noticed this before pushing, but I missed it due to another, independent CI failure). Discussion: https://postgr.es/m/20240715193754.awdxgrzurxnww...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4128453003dc755d94dfd661fb04d741f08e7fc8 Modified Files -- .cirrus.tasks.yml | 21 - 1 file changed, 12 insertions(+), 9 deletions(-)
pgsql: ci: Upgrade to Debian Bookworm
ci: Upgrade to Debian Bookworm Bullseye is getting long in the tooth, upgrade to the current stable version. Backpatch to all versions with CI support, we don't want to generate CI images for multiple Debian versions. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/27004d671162283840972113dbc7a22960cbbb07 Modified Files -- .cirrus.tasks.yml | 8 1 file changed, 4 insertions(+), 4 deletions(-)
pgsql: ci: Upgrade to Debian Bookworm
ci: Upgrade to Debian Bookworm Bullseye is getting long in the tooth, upgrade to the current stable version. Backpatch to all versions with CI support, we don't want to generate CI images for multiple Debian versions. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd40ffd8afd28bea6768b8fd46d02b0ccab3c93a Modified Files -- .cirrus.tasks.yml | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2cf9bda76cfdef5b14345193e0d3abc5a43c9c31 Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: ci: Upgrade to Debian Bookworm
ci: Upgrade to Debian Bookworm Bullseye is getting long in the tooth, upgrade to the current stable version. Backpatch to all versions with CI support, we don't want to generate CI images for multiple Debian versions. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be0fa5ba003ce1fb955211bead796ae97afbd2a4 Modified Files -- .cirrus.tasks.yml | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: ci: Upgrade to Debian Bookworm
ci: Upgrade to Debian Bookworm Bullseye is getting long in the tooth, upgrade to the current stable version. Backpatch to all versions with CI support, we don't want to generate CI images for multiple Debian versions. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c8a6ec206a9940551f3de80a6e5a10377056781c Modified Files -- .cirrus.tasks.yml | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2ad3b9350f7338b9ba0327ccd307a0fbba2208dc Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/43cd30bcd1cd4f03bce207938f69a9dc190f1c48 Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b9f3db23b7b5c7f522162e16482b096d9c930f80 Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ee89c4fa4b184bd2cc2a2b48fc13f474e6aa2a24 Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/92f02c39c0facc817450a77bdff042dabe4aa6a3 Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: Fix type confusion in guc_var_compare()
Fix type confusion in guc_var_compare() Before this change guc_var_compare() cast the input arguments to const struct config_generic *. That's not quite right however, as the input on one side is often just a char * on one side. Instead just use char *, the first field in config_generic. This fixes a -Warray-bounds warning with some versions of gcc. While the warning is only known to be triggered for <= 15, the issue the warning points out seems real, so apply the fix everywhere. Author: Nazir Bilal Yavuz Reported-by: Erik Rijkers Suggested-by: Andres Freund Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b047cc0b2c22b667d5452124a381b33d5a9ff4a Modified Files -- src/backend/utils/misc/guc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: doc PG 17 relnotes: Fix sslnegotation typo
doc PG 17 relnotes: Fix sslnegotation typo I was confused with copy-pasting the parameter name didn't work... Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a6685c5e362eab5d04b8ffe65fff7cfbd21b6034 Modified Files -- doc/src/sgml/release-17.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: ci: windows: Use the same image for VS and MinGW tasks
ci: windows: Use the same image for VS and MinGW tasks The VS and MinGW Windows images have been merged, to reduce the space needed for images. Before 98811323c8e the split helped boot performance, but now that we are using VMs that doesn't appear to be the case anymore. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ2kWYjPd7uUC5QswrB3tfVJDiURqC%2BMGM6a3oeev%3DVgOA%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6b52e2298d8529eab777eaca339da3b04c862f9c Modified Files -- .cirrus.tasks.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: ci: windows: Use the same image for VS and MinGW tasks
ci: windows: Use the same image for VS and MinGW tasks The VS and MinGW Windows images have been merged, to reduce the space needed for images. Before 98811323c8e the split helped boot performance, but now that we are using VMs that doesn't appear to be the case anymore. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ2kWYjPd7uUC5QswrB3tfVJDiURqC%2BMGM6a3oeev%3DVgOA%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/83fc61ccfaf38aebe73eacdfc712106797d75b39 Modified Files -- .cirrus.tasks.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: ci: windows: Use the same image for VS and MinGW tasks
ci: windows: Use the same image for VS and MinGW tasks The VS and MinGW Windows images have been merged, to reduce the space needed for images. Before 98811323c8e the split helped boot performance, but now that we are using VMs that doesn't appear to be the case anymore. Author: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN55FZ2kWYjPd7uUC5QswrB3tfVJDiURqC%2BMGM6a3oeev%3DVgOA%40mail.gmail.com Backpatch: 15-, where CI was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3a2cc5a5b99ab04b9dc7e5f6c46b564739b5eb1b Modified Files -- .cirrus.tasks.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Avoid unnecessary "touch meson.build" in vpath builds
Avoid unnecessary "touch meson.build" in vpath builds In e6927270cd1 I added a 'touch meson.build' to configure.ac, to ensure conflicts between in-tree configure based builds and meson builds are automatically detected. Unfortunately I omitted spaces around the condition restricting this to in-tree builds, leading to touch meson.build to also be executed in vpath builds. While the only consequence of this buglet is an unnecessary empty file in build directories, it seems worth backpatching. Reported-by: Christoph Berg Discussion: https://postgr.es/m/20240417230002.mb2gv3hyetyn6...@awork3.anarazel.de Backpatch: 16-, where the meson based build was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6d4bc96eb77bca6277880f218cd7a2f9e44bddc0 Modified Files -- configure| 2 +- configure.ac | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Avoid unnecessary "touch meson.build" in vpath builds
Avoid unnecessary "touch meson.build" in vpath builds In e6927270cd1 I added a 'touch meson.build' to configure.ac, to ensure conflicts between in-tree configure based builds and meson builds are automatically detected. Unfortunately I omitted spaces around the condition restricting this to in-tree builds, leading to touch meson.build to also be executed in vpath builds. While the only consequence of this buglet is an unnecessary empty file in build directories, it seems worth backpatching. Reported-by: Christoph Berg Discussion: https://postgr.es/m/20240417230002.mb2gv3hyetyn6...@awork3.anarazel.de Backpatch: 16-, where the meson based build was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2209c70c652e57314961a25725266821721415b8 Modified Files -- configure| 2 +- configure.ac | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Remove GlobalVisTestNonRemovable[Full]Horizon, not used anymore
Remove GlobalVisTestNonRemovable[Full]Horizon, not used anymore GlobalVisTestNonRemovableHorizon() was only used for the implementation of snapshot_too_old, which was removed in f691f5b80a8. As using GlobalVisTestNonRemovableHorizon() is not particularly efficient, no new uses for it should be added. Therefore remove. Discussion: https://postgr.es/m/20240415185720.q4dg4dlcyvvra...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3ab8cf92754d5ee4390af4e4840fb45d5bc25007 Modified Files -- src/backend/storage/ipc/procarray.c | 30 -- src/include/utils/snapmgr.h | 2 -- 2 files changed, 32 deletions(-)
Re: pgsql: Teach radix tree to embed values at runtime
Hi, On 2024-04-08 11:57:01 +, John Naylor wrote: > Teach radix tree to embed values at runtime > > Previously, the decision to store values in leaves or within the child > pointer was made at compile time, with variable length values using > leaves by necessity. This commit allows introspecting the length of > variable length values at runtime for that decision. This requires > the ability to tell whether the last-level child pointer is actually > a value, so we use a pointer tag in the lowest level bit. > > Use this in TID store. This entails adding a byte to the header to > reserve space for the tag. Commit f35bd9bf3 stores up to three offsets > within the header with no bitmap, and now the header can be embedded > as above. This reduces worst-case memory usage when TIDs are sparse. This isn't quite C99 conformant, and thus breaks on the buildfarm animal set up to test that: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2024-04-08%2012%3A07%3A01 You can't have unnamed structs in C99, that's a C11 feature. I wish we'd move to C11, but ... Greetings, Andres
pgsql: Remove references to old function name
Remove references to old function name In a97bbe1f1df I accidentally referenced heapgetpage(), both in a function name and a comment. But since 44086b09753 the relevant function is named heap_prepare_pagescan(). Rename the new function to page_collect_tuples(). Reported-by: Melanie Plageman Reported-by: David Rowley Discussion: https://postgr.es/m/20240407172615.cocrsvboqm3tt...@awork3.anarazel.de Discussion: https://postgr.es/m/CAApHDvp4SniHopTrVeKWcEvNXFtdki0utAvO=5r7h6tnhtu...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e3b69be9515979c546fbfc51f9f801c7b198 Modified Files -- src/backend/access/heap/heapam.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)
pgsql: simplehash: Free collisions array in SH_STAT
simplehash: Free collisions array in SH_STAT While SH_STAT() is only used for debugging, the allocated array can be large, and therefore should be freed. It's unclear why coverity started warning now. Reported-by: Tom Lane Reported-by: Coverity Discussion: https://postgr.es/m/3005248.1712538...@sss.pgh.pa.us Backpatch: 12- Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4b179a47242993fe48b1bfa21b17dc9d5e2b35a2 Modified Files -- src/include/lib/simplehash.h | 3 +++ 1 file changed, 3 insertions(+)
pgsql: simplehash: Free collisions array in SH_STAT
simplehash: Free collisions array in SH_STAT While SH_STAT() is only used for debugging, the allocated array can be large, and therefore should be freed. It's unclear why coverity started warning now. Reported-by: Tom Lane Reported-by: Coverity Discussion: https://postgr.es/m/3005248.1712538...@sss.pgh.pa.us Backpatch: 12- Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/974374dcd394c80f37e20b692b7d8b122aa8ed33 Modified Files -- src/include/lib/simplehash.h | 3 +++ 1 file changed, 3 insertions(+)
pgsql: simplehash: Free collisions array in SH_STAT
simplehash: Free collisions array in SH_STAT While SH_STAT() is only used for debugging, the allocated array can be large, and therefore should be freed. It's unclear why coverity started warning now. Reported-by: Tom Lane Reported-by: Coverity Discussion: https://postgr.es/m/3005248.1712538...@sss.pgh.pa.us Backpatch: 12- Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/25ee58e8f26df9ce3037258206eb100a3fc55103 Modified Files -- src/include/lib/simplehash.h | 3 +++ 1 file changed, 3 insertions(+)
pgsql: simplehash: Free collisions array in SH_STAT
simplehash: Free collisions array in SH_STAT While SH_STAT() is only used for debugging, the allocated array can be large, and therefore should be freed. It's unclear why coverity started warning now. Reported-by: Tom Lane Reported-by: Coverity Discussion: https://postgr.es/m/3005248.1712538...@sss.pgh.pa.us Backpatch: 12- Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dcb7cf945c88eabce7f8350023b8184266d96a12 Modified Files -- src/include/lib/simplehash.h | 3 +++ 1 file changed, 3 insertions(+)
pgsql: simplehash: Free collisions array in SH_STAT
simplehash: Free collisions array in SH_STAT While SH_STAT() is only used for debugging, the allocated array can be large, and therefore should be freed. It's unclear why coverity started warning now. Reported-by: Tom Lane Reported-by: Coverity Discussion: https://postgr.es/m/3005248.1712538...@sss.pgh.pa.us Backpatch: 12- Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/af7e90a2778625d63add69165fb68c370509a199 Modified Files -- src/include/lib/simplehash.h | 3 +++ 1 file changed, 3 insertions(+)
pgsql: simplehash: Free collisions array in SH_STAT
simplehash: Free collisions array in SH_STAT While SH_STAT() is only used for debugging, the allocated array can be large, and therefore should be freed. It's unclear why coverity started warning now. Reported-by: Tom Lane Reported-by: Coverity Discussion: https://postgr.es/m/3005248.1712538...@sss.pgh.pa.us Backpatch: 12- Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eabf98e949e3a655494a32ceb8d146117cce0505 Modified Files -- src/include/lib/simplehash.h | 3 +++ 1 file changed, 3 insertions(+)
Re: pgsql: Send ALPN in TLS handshake, require it in direct SSL connections
Hi, On 2024-04-08 01:25:40 +, Heikki Linnakangas wrote: > Send ALPN in TLS handshake, require it in direct SSL connections > > libpq now always tries to send ALPN. With the traditional negotiated > SSL connections, the server accepts the ALPN, and refuses the > connection if it's not what we expect, but connecting without ALPN is > still OK. With the new direct SSL connections, ALPN is mandatory. > > NOTE: This uses "TBD-pgsql" as the protocol ID. We must register a > proper one with IANA before the release! > > Author: Greg Stark, Heikki Linnakangas > Reviewed-by: Matthias van de Meent, Jacob Champion My compiler complains: [396/992 42 39%] Compiling C object src/backend/postgres_lib.a.p/libpq_be-secure-openssl.c.o ../../../../../home/andres/src/postgresql/src/backend/libpq/be-secure-openssl.c: In function 'alpn_cb': ../../../../../home/andres/src/postgresql/src/backend/libpq/be-secure-openssl.c:1327:69: warning: ordered comparison of pointer with integer zero [-Wextra] 1327 | if (*out == NULL || *outlen > sizeof(alpn_protos) || outlen <= 0) | ^~ [991/992 1 99%] Linking target src/bin/pg_dump/pg_dump And I think it may show why the warning is a good idea - I assume "*outlen <= 0" was intended? Greetings, Andres Freund
Re: pgsql: Use bump memory context for tuplesorts
Hi,
On 2024-04-07 13:52:28 -0400, Tom Lane wrote:
> Melanie Plageman writes:
> > Looks like this assert is tripping on grison [1].
>
> > running bootstrap script ... TRAP: failed Assert("total_allocated ==
> > context->mem_allocated"), File: "bump.c", Line: 808, PID: 30248
>
> The same on mamba. However, I failed to duplicate it in an x86
> (32-bit) VM. I think the critical factor on the failing machines
> is that MAXALIGN is 8 which is more than their sizeof(pointer).
For posterity: I think the above is correct, and that I found the concrete
reason this causes issues on the thread related to the patch. I posted there
because I figured it out after looking at Tomas' gdb output:
https://postgr.es/m/20240407210924.fvwfwbzms3bvtfcd%40awork3.anarazel.de
- Andres
Re: pgsql: Reduce branches in heapgetpage()'s per-tuple loop
Hi, On 2024-04-07 09:14:57 -0400, Melanie Plageman wrote: > On Sun, Apr 7, 2024 at 3:29 AM Andres Freund wrote: > > > > Reduce branches in heapgetpage()'s per-tuple loop > > > > Until now, heapgetpage()'s loop over all tuples performed some conditional > > checks for each tuple, even though condition did not change across the loop. > > I haven't reviewed exactly what this does, but heapgetpage() was > removed (or split into two functions, rather) in 44086b097537, so I > find the naming of this function, or, at least the comments, commit > message and description a bit confusing. Oops. That name was so ingrained in my head that despite looking over these lines quite a few times, I couldn't spot that. Will send an update to the thread. Greetings, Andres Freund
pgsql: Reduce branches in heapgetpage()'s per-tuple loop
Reduce branches in heapgetpage()'s per-tuple loop Until now, heapgetpage()'s loop over all tuples performed some conditional checks for each tuple, even though condition did not change across the loop. This commit fixes that by moving the loop into an inline function. By calling it with different constant arguments, the compiler can generate an optimized loop for the different conditions, at the price of two per-page checks. For cases of all-visible tables and an isolation level other than serializable, speedups of up to 25% have been measured. Reviewed-by: John Naylor Reviewed-by: Zhang Mingli Tested-by: Quan Zongliang Discussion: https://postgr.es/m/20230716015656.xjvemfbp5fysj...@awork3.anarazel.de Discussion: https://postgr.es/m/2ef7ff1b-3d18-2283-61b1-bbd25fc6c...@yeah.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a97bbe1f1df9eba0b18207c321c67de80b33db16 Modified Files -- src/backend/access/heap/heapam.c | 102 --- 1 file changed, 74 insertions(+), 28 deletions(-)
pgsql: Fix headerscheck violation introduced in f8ce4ed78ca
Fix headerscheck violation introduced in f8ce4ed78ca Per ci. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9e7386924e837aef8d48895cf72a6a0b7f78cbe9 Modified Files -- src/bin/pg_combinebackup/reconstruct.h | 1 + 1 file changed, 1 insertion(+)
pgsql: Avoid edge case in pg_visibility test with small shared_buffers
Avoid edge case in pg_visibility test with small shared_buffers Since 82a4edabd27 we can bulk extend relations. The bulk relation extension logic has a heuristic component. Normally the heurstic does not trigger in the occasionally-failing test case, as the relation is only extended once. But with very small shared_buffers the limits for the number of buffers pinned at once prevent the extension from happening at once. With the second "bulk" extension, the heuristic kicks in, and the relation ends up one block bigger. That's ok from a correctness perspective, but changes the results of the test query due to one additional block. We discussed a few more expansive fixes, but for now have decided to avoid this by making the table a bit smaller. Author: Heikki Linnakangas Reported-by: Discussion: https://postgr.es/m/29c74104-210b-ef39-2522-27a6aa7a7...@iki.fi Discussion: https://postgr.es/m/2023091611.2ugpkkkp7bpp4...@awork3.anarazel.de Backpatch: 16-, where the new relation extension logic was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/408209d6a9ae90a822edd48ce3c173b8b7e04ab7 Modified Files -- contrib/pg_visibility/expected/pg_visibility.out | 3 +-- contrib/pg_visibility/sql/pg_visibility.sql | 6 -- 2 files changed, 1 insertion(+), 8 deletions(-)
pgsql: Avoid edge case in pg_visibility test with small shared_buffers
Avoid edge case in pg_visibility test with small shared_buffers Since 82a4edabd27 we can bulk extend relations. The bulk relation extension logic has a heuristic component. Normally the heurstic does not trigger in the occasionally-failing test case, as the relation is only extended once. But with very small shared_buffers the limits for the number of buffers pinned at once prevent the extension from happening at once. With the second "bulk" extension, the heuristic kicks in, and the relation ends up one block bigger. That's ok from a correctness perspective, but changes the results of the test query due to one additional block. We discussed a few more expansive fixes, but for now have decided to avoid this by making the table a bit smaller. Author: Heikki Linnakangas Reported-by: Discussion: https://postgr.es/m/29c74104-210b-ef39-2522-27a6aa7a7...@iki.fi Discussion: https://postgr.es/m/2023091611.2ugpkkkp7bpp4...@awork3.anarazel.de Backpatch: 16-, where the new relation extension logic was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3a4837fc809a8656374959049f3ac7a09a711334 Modified Files -- contrib/pg_visibility/expected/pg_visibility.out | 3 +-- contrib/pg_visibility/sql/pg_visibility.sql | 6 -- 2 files changed, 1 insertion(+), 8 deletions(-)
pgsql: ci: macos: Choose python version
ci: macos: Choose python version The CI base image used to have a python3 with headers etc installed in PATH, but doesn't anymore. Instead of relying on a specific version in the base image, explicitly install one ourselves. On 16 and HEAD this lead to a build without python support, but on 15 CI failed, due to explicitly enabled python3 support. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/90677b52126af98d40676cd379b56b52e1428188 Modified Files -- .cirrus.tasks.yml | 3 +++ 1 file changed, 3 insertions(+)
pgsql: ci: macos: Choose python version
ci: macos: Choose python version The CI base image used to have a python3 with headers etc installed in PATH, but doesn't anymore. Instead of relying on a specific version in the base image, explicitly install one ourselves. On 16 and HEAD this lead to a build without python support, but on 15 CI failed, due to explicitly enabled python3 support. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/897efe0f39bee8ced11871ac65cc8d28d9b8ea1e Modified Files -- .cirrus.tasks.yml | 3 +++ 1 file changed, 3 insertions(+)
pgsql: ci: macos: Choose python version
ci: macos: Choose python version The CI base image used to have a python3 with headers etc installed in PATH, but doesn't anymore. Instead of relying on a specific version in the base image, explicitly install one ourselves. On 16 and HEAD this lead to a build without python support, but on 15 CI failed, due to explicitly enabled python3 support. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c6f09e188bbc5df8fd96682ba19e96f19d137eb2 Modified Files -- .cirrus.tasks.yml | 3 +++ 1 file changed, 3 insertions(+)
pgsql: meson: macos: Avoid warnings on Sonoma
meson: macos: Avoid warnings on Sonoma Starting with the Sonoma toolchain macos' linker emits warnings when the same library is linked to twice. That's ill considered, as the same library can be used by multiple subsidiary libraries. Luckily there's a flag to suppress that warning. On Ventura meson's default of -Wl,-undefined,dynamic_lookup caused warnings, which we suppressed with -Wl,-undefined,error. Unfortunately that causes a warning on Sonoma, which is absurd, as it's documented linker default. To avoid that warning, only add -Wl,-undefined,error if it does not trigger warnings. Luckily dynamic_lookup doesn't trigger a warning on Sonoma anymore. Discussion: https://postgr.es/m/20231201040515.p5bshhhtfru7d...@awork3.anarazel.de Backpatch: 16-, where the meson build was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9158e4b9eb9916fa586feb26a6149b59566b78e1 Modified Files -- meson.build | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-)
pgsql: meson: macos: Avoid warnings on Sonoma
meson: macos: Avoid warnings on Sonoma Starting with the Sonoma toolchain macos' linker emits warnings when the same library is linked to twice. That's ill considered, as the same library can be used by multiple subsidiary libraries. Luckily there's a flag to suppress that warning. On Ventura meson's default of -Wl,-undefined,dynamic_lookup caused warnings, which we suppressed with -Wl,-undefined,error. Unfortunately that causes a warning on Sonoma, which is absurd, as it's documented linker default. To avoid that warning, only add -Wl,-undefined,error if it does not trigger warnings. Luckily dynamic_lookup doesn't trigger a warning on Sonoma anymore. Discussion: https://postgr.es/m/20231201040515.p5bshhhtfru7d...@awork3.anarazel.de Backpatch: 16-, where the meson build was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a3da95deee38ee067b0bead639c830eacbe894d5 Modified Files -- meson.build | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-)
Re: pgsql: meson: docs: Add {html,man} targets, rename install-doc-*
Hi,
On 2023-12-01 09:04:19 -0500, Andrew Dunstan wrote:
> On 2023-11-29 We 07:20, Andrew Dunstan wrote:
> > On 2023-11-28 Tu 21:28, Andres Freund wrote:
> > > On 2023-11-23 08:32:21 -0500, Andrew Dunstan wrote:
> > > > On 2023-11-20 Mo 20:53, Andres Freund wrote:
> > > > > meson: docs: Add {html,man} targets, rename install-doc-*
> > > > >
> > > > > We have toplevel html, man targets in the autoconf build as
> > > > > well. It'd be odd
> > > > > to have an 'html' target but have the install target be
> > > > > 'install-doc-html',
> > > > > thus rename the install targets to match.
> > > >
> > > > This commit of one of its nearby friends appears to have broken
> > > > crake's docs
> > > > build:
> > > >
> > > > ERROR: Can't invoke target `html`: ambiguous name.Add target
> > > > type and/or path:
> > > > - ./doc/src/sgml/html:custom
> > > > - ./doc/src/sgml/html:alias
> > > >
> > > > See<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2023-11-23%2012%3A52%3A04>
> > > >
> > > Ah, I realize now that this is from meson compile html, not 'ninja
> > > html'. That
> > > explains why I couldn't reproduce this initially and why CI didn't
> > > complain.
> > > I don't really understand why meson compile complains in this case.Â
> > > I assume
> > > you don't want to disambiguate as suggested, by building html:alias
> > > instead?
> > >
> >
> > I've done that as a temporary fix to get crake out of the hole, but it's
> > pretty ugly, and I don't want to do it in a release if at all possible.
>
>
> and doing this has broken the docs build for release 16.
If I can get somebody to comment on
https://postgr.es/m/20231129183619.3hrnwaexbrpygbxg%40awork3.anarazel.de
we can remove the need for the :$buildtype suffix.
Greetings,
Andres Freund
pgsql: meson: Stop using deprecated way getting path of files
meson: Stop using deprecated way getting path of files The just released meson 1.3 strongly deprecated a hack we were using, emitting a noisy warning (the hack basically depended on an implementation detail to work). Turns out there has been a better way available for a while, I just hadn't found it. 1.4 added a more convenient approach, but we can't rely on that. Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20231129185053.s6c7f73eg7b4z...@awork3.anarazel.de Backpatch: 16-, where the meson build was added. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/70516b8fc3ee77113013930efb7bfdbabcfed885 Modified Files -- meson.build | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-)
pgsql: meson: Stop using deprecated way getting path of files
meson: Stop using deprecated way getting path of files The just released meson 1.3 strongly deprecated a hack we were using, emitting a noisy warning (the hack basically depended on an implementation detail to work). Turns out there has been a better way available for a while, I just hadn't found it. 1.4 added a more convenient approach, but we can't rely on that. Reviewed-by: Tristan Partin Discussion: https://postgr.es/m/20231129185053.s6c7f73eg7b4z...@awork3.anarazel.de Backpatch: 16-, where the meson build was added. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa11a9c14902b7bcb1d73533a0403dc50361112a Modified Files -- meson.build | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-)
Re: pgsql: meson: docs: Add {html,man} targets, rename install-doc-*
Hi, On 2023-11-29 10:05:26 -0500, Andrew Dunstan wrote: > On 2023-11-29 We 08:49, Tom Lane wrote: > > Andrew Dunstan writes: > > > On 2023-11-28 Tu 21:28, Andres Freund wrote: > > > > I don't really understand why meson compile complains in this case. I > > > > assume > > > > you don't want to disambiguate as suggested, by building html:alias > > > > instead? > > > I've done that as a temporary fix to get crake out of the hole, but it's > > > pretty ugly, and I don't want to do it in a release if at all possible. > > Our documentation says specifically that "ninja html" will build the > > HTML format. I would expect that to work by analogy with the "make" > > target; having to spell it differently seems like clearly a bug. > > > > > > > "ninja html" does in fact work. What's not working is "meson compile html". > And it looks like the reason I used that in the buildfarm code is that ninja > doesn't know about other targets like "postgres-US.pdf". It does: ninja help|grep pdf doc/src/sgml/postgres-A4.pdf Build documentation in PDF format, with A4 pages doc/src/sgml/postgres-US.pdf Build documentation in PDF format, with US letter pages "ninja doc/src/sgml/postgres-US.pdf" works and has worked since day one. FWIW, you can continue to use meson compile, you just need to disambiguate the target name: meson compile html:alias Which isn't particularly pretty, but does work. Greetings, Andres Freund
Re: pgsql: meson: docs: Add {html,man} targets, rename install-doc-*
Hi,
On 2023-11-23 08:32:21 -0500, Andrew Dunstan wrote:
> On 2023-11-20 Mo 20:53, Andres Freund wrote:
> > meson: docs: Add {html,man} targets, rename install-doc-*
> >
> > We have toplevel html, man targets in the autoconf build as well. It'd be
> > odd
> > to have an 'html' target but have the install target be 'install-doc-html',
> > thus rename the install targets to match.
>
>
> This commit of one of its nearby friends appears to have broken crake's docs
> build:
>
> ERROR: Can't invoke target `html`: ambiguous name.Add target type and/or path:
> - ./doc/src/sgml/html:custom
> - ./doc/src/sgml/html:alias
>
> See<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2023-11-23%2012%3A52%3A04>
Ah, I realize now that this is from meson compile html, not 'ninja html'. That
explains why I couldn't reproduce this initially and why CI didn't complain.
I don't really understand why meson compile complains in this case. I assume
you don't want to disambiguate as suggested, by building html:alias instead?
Greetings,
Andres Freund
pgsql: meson: Document build targets, add 'help' target
meson: Document build targets, add 'help' target Currently important build targets are somewhat hard to discover. This commit documents important meson build targets in the sgml documentation. But it's awkward to have to lookup build targets in the docs when hacking, so this also adds a 'help' target, printing out the same information. To avoid having to duplicate information in two places, generate both docbook and interactive docs from a single source. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/20231108232121.ww542mt6lfo6f...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07cb29737a4ea9bd28e436eecb4016c3202e3928 Modified Files -- doc/src/sgml/Makefile | 5 ++- doc/src/sgml/docguide.sgml | 13 --- doc/src/sgml/filelist.sgml | 1 + doc/src/sgml/generate-targets-meson.pl | 63 ++ doc/src/sgml/installation.sgml | 15 doc/src/sgml/meson.build | 9 + doc/src/sgml/targets-meson.txt | 43 +++ meson.build| 7 8 files changed, 148 insertions(+), 8 deletions(-)
pgsql: docs: meson: Change what 'docs' target builds
docs: meson: Change what 'docs' target builds This undoes the change in what the 'docs' target builds 969509c3f2e. Tom was concerned with having a target to just build the html docs, which a prior commit now provided explicitly. A subsequent commit will overhaul the documentation for the documentation targets. While at it, move all target in doc/src/sgml/Makefile up to just after the default "html" target, and add a comment explaining "all" is *not* the default target. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/20230209203855.njrepiupc3rme...@awork3.anarazel.de Discussion: https://postgr.es/m/20231103163848.26egkh5qdgw3v...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9e5b2a091fd0d672b7b2ff8afcfc9e9a6e9a5ac8 Modified Files -- doc/src/sgml/Makefile | 4 ++-- doc/src/sgml/docguide.sgml | 2 +- doc/src/sgml/meson.build | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
pgsql: meson: Add 'world' target
meson: Add 'world' target We have this for make as well. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/20231103163848.26egkh5qdgw3v...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6614cfb43c8281feef5c4563ddc36ab04914014e Modified Files -- meson.build | 2 ++ 1 file changed, 2 insertions(+)
pgsql: meson: docs: Add {html,man} targets, rename install-doc-*
meson: docs: Add {html,man} targets, rename install-doc-*
We have toplevel html, man targets in the autoconf build as well. It'd be odd
to have an 'html' target but have the install target be 'install-doc-html',
thus rename the install targets to match.
Reviewed-by: Christoph Berg
Reviewed-by: Peter Eisentraut
Discussion:
https://postgr.es/m/20231103163848.26egkh5qdgw3v...@awork3.anarazel.de
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ddcab2a0329511e8872b62f2c77e5fa33547c277
Modified Files
--
doc/src/sgml/meson.build | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: meson: Fix missing dependency from install-quiet to sepgsql.sql
meson: Fix missing dependency from install-quiet to sepgsql.sql This could lead to an error like ERROR: File 'contrib/sepgsql/sepgsql.sql' could not be found Backpatch: 16-, where meson was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/823eb3db1c50a6b8a89ebedc1db96b14de140183 Modified Files -- contrib/sepgsql/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: meson: Fix missing dependency from install-quiet to sepgsql.sql
meson: Fix missing dependency from install-quiet to sepgsql.sql This could lead to an error like ERROR: File 'contrib/sepgsql/sepgsql.sql' could not be found Backpatch: 16-, where meson was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be08a359db7231f81f8d64975f4babf6dd24bfec Modified Files -- contrib/sepgsql/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: docs: Document --with-selinux/-Dselinux options centrally
Hi, On 2023-11-17 13:23:54 -0800, Andres Freund wrote: > On 2023-11-17 15:49:52 -0500, Tom Lane wrote: > > Andres Freund writes: > > > docs: Document --with-selinux/-Dselinux options centrally > > > > This appears to have broken building the INSTALL file: > > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2023-11-17%2020%3A20%3A03 > > > We have a mechanism for supplying alternate text for INSTALL, IIRC. > > Gah, will look at it. Pushed the fix. Greetings, Andres Freund
pgsql: docs: Fix standalone INSTALL, broken in 06c70849fb2
docs: Fix standalone INSTALL, broken in 06c70849fb2 We should probably check that INSTALL can be generated in CI. Reported-by: Tom Lane Discussion: https://postgr.es/m/795075.1700254...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a268a51de692c462e641a58ac842bbb0ac1e43ea Modified Files -- doc/src/sgml/standalone-profile.xsl | 4 1 file changed, 4 insertions(+)
Re: pgsql: docs: Document --with-selinux/-Dselinux options centrally
Hi, On 2023-11-17 15:49:52 -0500, Tom Lane wrote: > Andres Freund writes: > > docs: Document --with-selinux/-Dselinux options centrally > > This appears to have broken building the INSTALL file: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2023-11-17%2020%3A20%3A03 > We have a mechanism for supplying alternate text for INSTALL, IIRC. Gah, will look at it. Greetings, Andres Freund
pgsql: Release lock on heap buffer before vacuuming FSM
Release lock on heap buffer before vacuuming FSM When there are no indexes on a table, we vacuum each heap block after pruning it and then update the freespace map. Periodically, we also vacuum the freespace map. This was done while unnecessarily holding a lock on the heap page. Release the lock before calling FreeSpaceMapVacuumRange() and, while we're at it, ensure the range includes the heap block we just vacuumed. There are no known deadlocks or other similar issues, therefore don't backpatch. It's certainly not good to do all this work under a lock, but it's not frequently reached, making it not worth the risk of backpatching. Author: Melanie Plageman Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CAAKRu_YiL%3D44GvGnt1dpYouDSSoV7wzxVoXs8m3p311rp-TVQQ%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b2e237afddc56a4826121169a693412d8683d940 Modified Files -- src/backend/access/heap/vacuumlazy.c | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-)
pgsql: docs: Document --with-selinux/-Dselinux options centrally
docs: Document --with-selinux/-Dselinux options centrally Previously --with-selinux was documented only in the in the sepgsql documentation and there was no corresponding documentation for meson. There are further improvements that could be made, but this change seems worthwhile even on its own. Reviewed-by: Peter Eisentraut Reported-by: Christoph Berg Discussion: https://postgr.es/m/20231103163848.26egkh5qdgw3v...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/06c70849fb26ac431a722b1d10cffe1c65e728a4 Modified Files -- doc/src/sgml/installation.sgml | 21 + doc/src/sgml/sepgsql.sgml | 11 --- 2 files changed, 29 insertions(+), 3 deletions(-)
pgsql: meson: Change default of 'selinux' feature option to auto
meson: Change default of 'selinux' feature option to auto There is really no reason for selinux to behave differently than other options. Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/20231103211601.bgqx3cfq6pz2l...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c04f3de3dca3b54e16d7774885c8b64f90ca259b Modified Files -- meson_options.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: meson: docs: Install all manpages, not just ones in man1
meson: docs: Install all manpages, not just ones in man1 In f13eb16485f I made a mistake leading to only man1 being installed. I will report a bug suggesting that meson warn about mistakes of this sort. Reported-by: Christoph Berg Discussion: https://postgr.es/m/zuu5prqo6zueb...@msg.df7cb.de Backpatch: 16-, where the meson build was introduced Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a237a07d5351d7bb0afc6e0c41410d52915e47c8 Modified Files -- doc/src/sgml/meson.build | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: meson: docs: Install all manpages, not just ones in man1
meson: docs: Install all manpages, not just ones in man1 In f13eb16485f I made a mistake leading to only man1 being installed. I will report a bug suggesting that meson warn about mistakes of this sort. Reported-by: Christoph Berg Discussion: https://postgr.es/m/zuu5prqo6zueb...@msg.df7cb.de Backpatch: 16-, where the meson build was introduced Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f646ac6725672896d424e0ac46b3ba77a4063264 Modified Files -- doc/src/sgml/meson.build | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: meson: Make detection of python more robust
meson: Make detection of python more robust Previously we errored out if no python installation could be found (but we did handle not having enough of python installed to build plpython against). Presumably nobody hit this so far, as python is likely installed due to meson requiring python. Author: Tristan Partin Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po Backpatch: 16-, where meson support was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/41da94fd5c7418838ec7c49456b69c462013ea57 Modified Files -- meson.build | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-)
pgsql: meson: Make detection of python more robust
meson: Make detection of python more robust Previously we errored out if no python installation could be found (but we did handle not having enough of python installed to build plpython against). Presumably nobody hit this so far, as python is likely installed due to meson requiring python. Author: Tristan Partin Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po Backpatch: 16-, where meson support was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c79ca0485a62b2abefabd538ac896cd64f4e7a01 Modified Files -- meson.build | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-)
pgsql: Fix bulk table extension when copying into multiple partitions
Fix bulk table extension when copying into multiple partitions When COPYing into a partitioned table that does now permit the use of table_multi_insert(), we could error out with ERROR: could not read block NN in file "base/...": read only 0 of 8192 bytes because BulkInsertState->next_free was not reset between partitions. This problem occurred only when not able to use table_multi_insert(), as a dedicated BulkInsertState for each partition is used in that case. The bug was introduced in 00d1e02be24, but it was hard to hit at that point, as commonly bulk relation extension is not used when not using table_multi_insert(). It became more likely after 82a4edabd27, which expanded the use of bulk extension. To fix the bug, reset the bulk relation extension state in BulkInsertState in ReleaseBulkInsertStatePin(). That was added (in b1ecb9b3fcf) to tackle a very similar issue. Obviously the name is not quite correct, but there might be external callers, and bulk insert state needs to be reset in precisely in the situations that ReleaseBulkInsertStatePin() already needed to be called. Medium term the better fix likely is to disallow reusing BulkInsertState across relations. Add a test that, without the fix, reproduces #18130 in most configurations. The test also catches the problem fixed in b1ecb9b3fcf when run with small shared_buffers. Reported-by: Ivan Kolombet Analyzed-by: Tom Lane Analyzed-by: Andres Freund Bug: #18130 Discussion: https://postgr.es/m/18130-7a86a7356a75209d%40postgresql.org Discussion: https://postgr.es/m/257696.1695670946%40sss.pgh.pa.us Backpatch: 16- Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0002feb8209618e5a9e23e03fe4aa31bc4006f01 Modified Files -- src/backend/access/heap/heapam.c | 11 +++ src/test/regress/expected/copy.out | 37 + src/test/regress/sql/copy.sql | 37 + 3 files changed, 85 insertions(+)
pgsql: Fix bulk table extension when copying into multiple partitions
Fix bulk table extension when copying into multiple partitions When COPYing into a partitioned table that does now permit the use of table_multi_insert(), we could error out with ERROR: could not read block NN in file "base/...": read only 0 of 8192 bytes because BulkInsertState->next_free was not reset between partitions. This problem occurred only when not able to use table_multi_insert(), as a dedicated BulkInsertState for each partition is used in that case. The bug was introduced in 00d1e02be24, but it was hard to hit at that point, as commonly bulk relation extension is not used when not using table_multi_insert(). It became more likely after 82a4edabd27, which expanded the use of bulk extension. To fix the bug, reset the bulk relation extension state in BulkInsertState in ReleaseBulkInsertStatePin(). That was added (in b1ecb9b3fcf) to tackle a very similar issue. Obviously the name is not quite correct, but there might be external callers, and bulk insert state needs to be reset in precisely in the situations that ReleaseBulkInsertStatePin() already needed to be called. Medium term the better fix likely is to disallow reusing BulkInsertState across relations. Add a test that, without the fix, reproduces #18130 in most configurations. The test also catches the problem fixed in b1ecb9b3fcf when run with small shared_buffers. Reported-by: Ivan Kolombet Analyzed-by: Tom Lane Analyzed-by: Andres Freund Bug: #18130 Discussion: https://postgr.es/m/18130-7a86a7356a75209d%40postgresql.org Discussion: https://postgr.es/m/257696.1695670946%40sss.pgh.pa.us Backpatch: 16- Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/22655aa23132a0645fdcdce4b233a1fff0c0cf8f Modified Files -- src/backend/access/heap/heapam.c | 11 +++ src/test/regress/expected/copy.out | 37 + src/test/regress/sql/copy.sql | 37 + 3 files changed, 85 insertions(+)
pgsql: meson: macos: Correct -exported_symbols_list syntax for Sonoma c
meson: macos: Correct -exported_symbols_list syntax for Sonoma compat -exported_symbols_list=... works on Ventura and earlier, but not on Sonoma. The easiest way to fix it is to -Wl,-exported_symbols_list,@0@ which actually seems more appropriate anyway, it's obviously a linker argument. It is easier to use the -Wl,, syntax than passing multiple arguments, due to the way the export_fmt is used (a single string that's formatted), but if it turns out to be necessary, we can go for multiple arguments as well. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/2023092848.jw6s7yktpfsfc...@alap3.anarazel.de Backpatch: 16-, where the meson based buildsystem was added Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b1a8dc846da4d96d903dcb5733f68a1e02d82a23 Modified Files -- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: meson: macos: Correct -exported_symbols_list syntax for Sonoma c
meson: macos: Correct -exported_symbols_list syntax for Sonoma compat -exported_symbols_list=... works on Ventura and earlier, but not on Sonoma. The easiest way to fix it is to -Wl,-exported_symbols_list,@0@ which actually seems more appropriate anyway, it's obviously a linker argument. It is easier to use the -Wl,, syntax than passing multiple arguments, due to the way the export_fmt is used (a single string that's formatted), but if it turns out to be necessary, we can go for multiple arguments as well. Reviewed-by: Tom Lane Discussion: https://postgr.es/m/2023092848.jw6s7yktpfsfc...@alap3.anarazel.de Backpatch: 16-, where the meson based buildsystem was added Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d5c5312dc8b66b4ad652ec54ed32029d621e1e93 Modified Files -- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/6a3b19bbefd782605765c67990e9d8b4dd5e9f87
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/9dc3c5472ed99a1046a4d7884270a35cfad29d1d
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/4dfb610822d5ab4bea7820da9be02d83bad69fb5
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/849d367ff9a2875d4906fa110472462c4c95fad0
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/fd7a114dbb4e8b700b0b738bb9c513b5fa3198a3
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/d1c76fdec3751c724a25d449ea5aeeb33a27b3d3
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: pg_dump: tests: Correct test condition for invalid databases
pg_dump: tests: Correct test condition for invalid databases
For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test
condition of one of the tests added in in c66a7d75e65. That doesn't make sense
for two reasons: 1) not_like isn't a valid test condition 2) the database
should not be dumped in any of the tests. Due to 1), the test achieved its
goal, but clearly the formulation is confusing. Instead use like => {}, with
a comment explaining why.
Reported-by: Peter Eisentraut
Discussion:
https://postgr.es/m/3ddf79f2-8b7b-a093-11d2-5c739bc64...@eisentraut.org
Backpatch: 11-, like c66a7d75e65
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/881defde944c07d821d9658b1943d5ad5ef5bf37
Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
pgsql: docs: Clarify --with-segsize-blocks documentation
docs: Clarify --with-segsize-blocks documentation Without the added "relation" it's not immediately clear that the option relates to the relation segment size and not e.g. the WAL segment size. The option was added in d3b111e32. Reported-by: Tom Lane Discussion: https://postgr.es/m/837536.1695348...@sss.pgh.pa.us Backpatch: 16- Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/72bf3f0877fe7ae9a22c23f461d0fdafb6af5c4b Modified Files -- doc/src/sgml/installation.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: docs: Clarify --with-segsize-blocks documentation
docs: Clarify --with-segsize-blocks documentation Without the added "relation" it's not immediately clear that the option relates to the relation segment size and not e.g. the WAL segment size. The option was added in d3b111e32. Reported-by: Tom Lane Discussion: https://postgr.es/m/837536.1695348...@sss.pgh.pa.us Backpatch: 16- Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a2c2fbf740fcfdf75b76d589b8e85c1cdf725a46 Modified Files -- doc/src/sgml/installation.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix tracking of temp table relation extensions as writes
Fix tracking of temp table relation extensions as writes Karina figured out that I (Andres) confused BufferUsage.temp_blks_written with BufferUsage.local_blks_written in fcdda1e4b5. Tests in core PG can't easily test this, as BufferUsage is just used for EXPLAIN (ANALYZE, BUFFERS) and pg_stat_statements. Thus this commit adds tests for this to pg_stat_statements. Reported-by: Karina Litskevich Author: Karina Litskevich Author: Andres Freund Discussion: https://postgr.es/m/cacit8ibxxa6+0amgikbefhm8b84xdqvo6d0qfd1pq1s8zps...@mail.gmail.com Backpatch: 16-, where fcdda1e4b5 was merged Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c4758649b4db7d0c4b681985d24cc3e1e938047d Modified Files -- contrib/pg_stat_statements/expected/dml.out | 27 +++ contrib/pg_stat_statements/sql/dml.sql | 19 +++ src/backend/storage/buffer/localbuf.c | 2 +- 3 files changed, 47 insertions(+), 1 deletion(-)
pgsql: Fix tracking of temp table relation extensions as writes
Fix tracking of temp table relation extensions as writes Karina figured out that I (Andres) confused BufferUsage.temp_blks_written with BufferUsage.local_blks_written in fcdda1e4b5. Tests in core PG can't easily test this, as BufferUsage is just used for EXPLAIN (ANALYZE, BUFFERS) and pg_stat_statements. Thus this commit adds tests for this to pg_stat_statements. Reported-by: Karina Litskevich Author: Karina Litskevich Author: Andres Freund Discussion: https://postgr.es/m/cacit8ibxxa6+0amgikbefhm8b84xdqvo6d0qfd1pq1s8zps...@mail.gmail.com Backpatch: 16-, where fcdda1e4b5 was merged Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7369798a83c883a6314b8a8ed6d3063c508de784 Modified Files -- contrib/pg_stat_statements/expected/dml.out | 27 +++ contrib/pg_stat_statements/sql/dml.sql | 19 +++ src/backend/storage/buffer/localbuf.c | 2 +- 3 files changed, 47 insertions(+), 1 deletion(-)
pgsql: Avoid non-POSIX cp flags
Avoid non-POSIX cp flags Commit 252dcb32 used cp -a, but apparently Solaris doesn't like that. Use cp -RPp instead. Author: Thomas Munro Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/ca+hukgl10aoqvmmqgoj8ctjoz9mlidd8ik2e8pibzlnmz0+...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1a4fd77db85abac63e178506335aee74625f6499 Modified Files -- src/test/perl/PostgreSQL/Test/Cluster.pm | 2 +- src/test/regress/pg_regress.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Use "template" data directory in tests
Use "template" data directory in tests When running all (or just many) of our tests, a significant portion of both CPU time and IO is spent running initdb. Most of those initdb runs don't specify any options influencing properties of the created data directory. Avoid most of that overhead by creating a "template" data directory, alongside the temporary installation. Instead of running initdb, pg_regress and tap tests can copy that data directory. When a tap test specifies options to initdb, the template data directory is not used. That could be relaxed for some options, but it's not clear it's worth the effort. There unfortunately is some duplication between pg_regress.c and Cluster.pm, but there are no easy ways of sharing that code without introducing additional complexity. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20220120021859.3zpsfqn4z7ob7...@alap3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/252dcb32397f64a5e1ceac05b29a271ab19aa960 Modified Files -- .cirrus.tasks.yml| 3 +- meson.build | 30 + src/Makefile.global.in | 38 +--- src/test/perl/PostgreSQL/Test/Cluster.pm | 46 ++- src/test/regress/pg_regress.c| 76 +--- 5 files changed, 156 insertions(+), 37 deletions(-)
