Re: pgsql: Add scripts for retrieving the cluster file encryption key
This script seems to have broken my instance. https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=massasauga&dt=2020-12-26%2006%3A20%3A19 - robins On Sat, 26 Dec 2020 at 17:19, Bruce Momjian wrote: > Add scripts for retrieving the cluster file encryption key > > Scripts are passphrase, direct, AWS, and two Yubikey ones. > > Backpatch-through: master > > Branch > -- > master > > Details > --- > > https://git.postgresql.org/pg/commitdiff/d7602afa2ef6d8b2018103dccd89e75b4985ac06 > > Modified Files > -- > src/backend/Makefile | 12 + > src/backend/crypto/ckey_aws.sh.sample| 50 ++ > src/backend/crypto/ckey_direct.sh.sample | 37 ++ > src/backend/crypto/ckey_passphrase.sh.sample | 33 > src/backend/crypto/ckey_piv_nopin.sh.sample | 63 +++ > src/backend/crypto/ckey_piv_pin.sh.sample| 76 > > src/backend/crypto/ssl_passphrase.sh.sample | 33 > 7 files changed, 304 insertions(+) > >
Re: pgsql: postgres_fdw: Fix assertion in estimate_path_cost_size().
Hi, I think this bugfix needs to be backpatched to v12 too. See backtrace / repro SQL here - https://www.postgresql.org/message-id/17713-92cce66de7e81c04%40postgresql.org - Robins Tharakan Amazon Web Services On Fri, 5 Feb 2021 at 17:05, Etsuro Fujita wrote: > > postgres_fdw: Fix assertion in estimate_path_cost_size(). > > Commit 08d2d58a2 added an assertion assuming that the retrieved_rows > estimate for a foreign relation, which is re-used to cost pre-sorted > foreign paths with local stats, is set to at least one row in > estimate_path_cost_size(), which isn't correct because if the relation > is a foreign table with tuples=0, the estimate would be set to 0 there > when not using remote estimates. > > Per bug #16807 from Alexander Lakhin. Back-patch to v13 where the > aforementioned commit went in. > > Author: Etsuro Fujita > Reviewed-by: Kyotaro Horiguchi > Discussion: https://postgr.es/m/16807-9fe4e08fbaa5c7ce%40postgresql.org > > Branch > -- > REL_13_STABLE > > Details > --- > https://git.postgresql.org/pg/commitdiff/984384129bb8a92481d4f7ddd5dede2d781b191f > > Modified Files > -- > contrib/postgres_fdw/expected/postgres_fdw.out | 18 ++ > contrib/postgres_fdw/postgres_fdw.c| 2 +- > contrib/postgres_fdw/sql/postgres_fdw.sql | 12 > 3 files changed, 31 insertions(+), 1 deletion(-) >
Re: pgsql: Make Vars be outer-join-aware.
Hi Tom,
On Tue, 31 Jan 2023 at 05:43, Tom Lane wrote:
>
> Make Vars be outer-join-aware.
>
Since this commit, my test setup is triggering asserts every few minutes.
The repro SQL itself doesn't make much sense, but it's the smallest I could
narrow it down to:
create table t1(a int);
create table t2(a int);
SELECT table_catalog AS c2
FROM public.t1
INNER JOIN (t2
LEFT JOIN information_schema.column_udt_usage ON NULL)
ON NULL;
Sample backtrace (can provide full backtrace if it helps):
Core was generated by `postgres: 8c1cd726c5@master@sqith: u76 postgres
127.0.0.1(55412) SELECT '.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7f4e32fbf859 in __GI_abort () at abort.c:79
#2 0x55bc9fb256bf in ExceptionalCondition (
conditionName=0x55bc9fcdaaf1 "phv->phnullingrels == NULL",
fileName=0x55bc9fcda72f "setrefs.c", lineNumber=2208) at assert.c:66
#3 0x55bc9f8147a4 in fix_scan_expr_mutator (node=0x55bca21c78b0,
context=0x7fff72760960) at setrefs.c:2208
#4 0x55bc9f768081 in expression_tree_mutator_impl (node=0x55bca21c9dc0,
mutator=0x55bc9f8144a2 , context=0x7fff72760960)
at nodeFuncs.c:3051
#5 0x55bc9f81482c in fix_scan_expr_mutator (node=0x55bca21c9dc0,
context=0x7fff72760960) at setrefs.c:2217
#6 0x55bc9f76848c in expression_tree_mutator_impl (node=0x55bca21c9e10,
mutator=0x55bc9f8144a2 , context=0x7fff72760960)
at nodeFuncs.c:3137
#7 0x55bc9f81482c in fix_scan_expr_mutator (node=0x55bca21c9e10,
context=0x7fff72760960) at setrefs.c:2217
#8 0x55bc9f814473 in fix_scan_expr (root=0x55bca217e358,
node=0x55bca21c9e10, rtoffset=1, num_exec=0) at setrefs.c:2127
TRAP: failed Assert("phv->phnullingrels == NULL"), File: "setrefs.c",
Line: 2208, PID: 1045580
Thanks to SQLSmith / SQLReduce for help on this.
-
Robins Tharakan
Amazon Web Services
Re: pgsql: Do assorted mop-up in the planner.
Hi Tom, On Tue, 31 Jan 2023 at 05:43, Tom Lane wrote: > > Do assorted mop-up in the planner. This commit is causing occasional Asserts in my testing. SQL / Backtrace / triaging below. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f6d091d0859 in __GI_abort () at abort.c:79 #2 0x55bf99f9d962 in ExceptionalCondition (conditionName=0x55bf9a153280 "bms_is_subset(rinfo->required_relids, both_input_relids)", fileName=0x55bf9a152faf "relnode.c", lineNumber=1314) at assert.c:66 #3 0x55bf99cc3689 in subbuild_joinrel_restrictlist (root=0x55bf9b35ec08, joinrel=0x55bf9b36bc38, input_rel=0x55bf9b367420, both_input_relids=0x55bf9b36c7f8, new_restrictlist=0x0) at relnode.c:1314 #4 0x55bf99cc33f9 in build_joinrel_restrictlist (root=0x55bf9b35ec08, joinrel=0x55bf9b36bc38, outer_rel=0x55bf9b367420, inner_rel=0x55bf9b3660e0) at relnode.c:1232 #5 0x55bf99cc2730 in build_join_rel (root=0x55bf9b35ec08, joinrelids=0x55bf9b36b2a8, outer_rel=0x55bf9b367420, inner_rel=0x55bf9b3660e0, sjinfo=0x55bf9b368068, restrictlist_ptr=0x7ffd89ee7560) at relnode.c:771 #6 0x55bf99c5eedf in make_join_rel (root=0x55bf9b35ec08, rel1=0x55bf9b367420, rel2=0x55bf9b3660e0) at joinrels.c:756 #7 0x55bf99c5e3bd in make_rels_by_clause_joins (root=0x55bf9b35ec08, old_rel=0x55bf9b367420, other_rels_list=0x55bf9b36b408, other_rels=0x55bf9b36b420) at joinrels.c:312 #8 0x55bf99c5dedd in join_search_one_level (root=0x55bf9b35ec08, level=3) at joinrels.c:123 #9 0x55bf99c3fbc7 in standard_join_search (root=0x55bf9b35ec08, levels_needed=3, initial_rels=0x55bf9b36b408) at allpaths.c:3387 #10 0x55bf99c3fb34 in make_rel_from_joinlist (root=0x55bf9b35ec08, joinlist=0x55bf9b367f18) at allpaths.c:3318 #11 0x55bf99c3aabd in make_one_rel (root=0x55bf9b35ec08, joinlist=0x55bf9b367f18) at allpaths.c:211 #12 0x55bf99c7aa5e in query_planner (root=0x55bf9b35ec08, qp_callback=0x55bf99c8112d , qp_extra=0x7ffd89ee79b0) at planmain.c:278 #13 0x55bf99c7d374 in grouping_planner (root=0x55bf9b35ec08, tuple_fraction=0) at planner.c:1488 #14 0x55bf99c7ca2f in subquery_planner (glob=0x55bf9b340e18, parse=0x55bf9b26f5b8, parent_root=0x0, hasRecursion=false, tuple_fraction=0) at planner.c:1057 #15 0x55bf99c7b137 in standard_planner (parse=0x55bf9b26f5b8, query_string=0x55bf9b26de28 "SELECT pg_catalog.avg(NULL::NUMERIC) OVER (ORDER BY ref_3.schemaname) AS c2\nFROM (SELECT) AS subq_0\n LEFT JOIN pg_catalog.pg_statio_all_sequences AS ref_3 ON NULL;", cursorOptions=2048, boundParams=0x0) at planner.c:411 SQL: SELECT pg_catalog.avg(NULL::NUMERIC) OVER (ORDER BY ref_3.schemaname) AS c2 FROM (SELECT) AS subq_0 LEFT JOIN pg_catalog.pg_statio_all_sequences AS ref_3 ON NULL; Checking (fb1a59de0c~10) - 8c1cd726c5d997d5d170505ec15a2dc1dfe81d6a - Crash Checking (fb1a59de0c~11) - 54e72b66ed1a55c2fa558bc60d534bdc61dbb62f - Crash Checking (fb1a59de0c~12) - 3bef56e11650a33f70adeb6dd442bc2b48bb9b72 - Crash Checking (fb1a59de0c~13) - b448f1c8d83f8b65e2f0080c556ee21a7076da25 - Crash Checking (fb1a59de0c~14) - 2489d76c4906f4461a364ca8ad7e0751ead8aa0d - Success Checking (fb1a59de0c~15) - ec7e053a98f39a9e3c7e6d35f0d2e83933882399 - Success Thanks to SQLSmith / SQLReduce. - Robins Tharakan Amazon Web Services
Re: pgsql: Do assorted mop-up in the planner.
Thanks for taking a look. To add, although a slightly different signature, it looks like Bug #17769 is also related to this commit b448f1c8d83f. https://www.postgresql.org/message-id/17769-e4f7a5c9d84a80a7%40postgresql.org === SQL SELECT FROM pg_catalog.pg_statio_all_tables AS ref_0, LATERAL (SELECT WHERE ref_0.schemaname = ref_0.relname) AS subq_0; Checking (0736fc1ceb~16) - 3bef56e11650a33f70adeb6dd442bc2b48bb9b72 - Crash Checking (0736fc1ceb~17) - b448f1c8d83f8b65e2f0080c556ee21a7076da25 - Crash Checking (0736fc1ceb~18) - 2489d76c4906f4461a364ca8ad7e0751ead8aa0d - Success Checking (0736fc1ceb~19) - ec7e053a98f39a9e3c7e6d35f0d2e83933882399 - Success Checking (0736fc1ceb~20) - fe9e658f4d7fbc12d2b6a74c4ee90c73e53d68ef - Success - robins On Thu, 2 Feb 2023 at 12:23, Tom Lane wrote: > > Robins Tharakan writes: > > This commit is causing occasional Asserts in my testing. > > Thanks! I'm tired now, but will have a look tomorrow. > > regards, tom lane
Re: pgsql: Do assorted mop-up in the planner.
Hi Tom, I'll probably switch off testing master for a day (and probably stop posting more on this thread), but thought I'd post one last (seemingly different) signature around the same commit, before I wrap up for the day. On Thu, 2 Feb 2023 at 23:25, Robins Tharakan wrote: > > To add, although a slightly different signature, it looks like Bug #17769 is > also related to this commit b448f1c8d83f. Core was generated by `postgres: 117d2604c2@master@sqith: ubuntu postgres 127.0.'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f7934a6f859 in __GI_abort () at abort.c:79 #2 0x55bea71e1dfe in ExceptionalCondition ( conditionName=0x55bea7398420 "nrm_match == NRM_SUBSET ? bms_is_subset(phv->phnullingrels, subphv->phnullingrels) : nrm_match == NRM_SUPERSET ? bms_is_subset(subphv->phnullingrels, phv->p hnullingrels) : bms_equal(subphv->phnullingr"..., fileName=0x55bea7397e4f "setrefs.c", lineNumber=2845) at assert.c:66 #3 0x55bea6ed2088 in search_indexed_tlist_for_phv (phv=0x55bea8845868, itlist=0x55bea884d3a0, newvarno=-2, nrm_match=NRM_SUPERSET) at setrefs.c:2845 #4 0x55bea6ed24ec in fix_join_expr_mutator (node=0x55bea8845868, context=0x7ffcabf84820) at setrefs.c:3057 #5 0x55bea6e0f1ea in expression_tree_mutator_impl (node=0x55bea8845928, mutator=0x55bea6ed2317 , context=0x7ffcabf84820) at nodeFuncs.c:3137 #6 0x55bea6ed269b in fix_join_expr_mutator (node=0x55bea8845928, context=0x7ffcabf84820) at setrefs.c:3104 #7 0x55bea6e0e055 in expression_tree_mutator_impl (node=0x55bea88457f8, mutator=0x55bea6ed2317 , context=0x7ffcabf84820) at nodeFuncs.c:2771 #8 0x55bea6ed269b in fix_join_expr_mutator (node=0x55bea88457f8, context=0x7ffcabf84820) at setrefs.c:3104 #9 0x55bea6e0f1ea in expression_tree_mutator_impl (node=0x55bea88457c8, mutator=0x55bea6ed2317 , context=0x7ffcabf84820) at nodeFuncs.c:3137 #10 0x55bea6ed269b in fix_join_expr_mutator (node=0x55bea88457c8, context=0x7ffcabf84820) at setrefs.c:3104 #11 0x55bea6e0e229 in expression_tree_mutator_impl (node=0x55bea88456c8, mutator=0x55bea6ed2317 , context=0x7ffcabf84820) at nodeFuncs.c:2811 #12 0x55bea6ed269b in fix_join_expr_mutator (node=0x55bea88456c8, context=0x7ffcabf84820) at setrefs.c:3104 #13 0x55bea6e0f1ea in expression_tree_mutator_impl (node=0x55bea884c330, === SQL rollback; begin; create table tn(i name); create table rc(cname text); SELECT FROM (select '' a) AS sample_1 LEFT JOIN ((SELECT '(429.25491125213796,40.254082597002764)'::point p) AS sample_2 RIGHT JOIN ((SELECT 'int2col'::name colname, 'int2'::text typ) AS sample_3 RIGHT JOIN rc AS sample_4 ON sample_4.cname IS NOT NULL) ON NULL RIGHT JOIN tn AS ref_0 ON sample_2.p IS NULL OR sample_3.colname !~~ sample_3.typ) ON sample_1.a ^@ sample_4.cname; rollback; Checking (0736fc1ceb~16) - 3bef56e11650a33f70adeb6dd442bc2b48bb9b72 - Crash Checking (0736fc1ceb~17) - b448f1c8d83f8b65e2f0080c556ee21a7076da25 - Crash Checking (0736fc1ceb~18) - 2489d76c4906f4461a364ca8ad7e0751ead8aa0d - Success Checking (0736fc1ceb~19) - ec7e053a98f39a9e3c7e6d35f0d2e83933882399 - Success - Robins Tharakan Amazon Web Services
Re: pgsql: Do assorted mop-up in the planner.
On Mon, 6 Feb 2023 at 05:57, Tom Lane wrote: > I'd hoped that some of these failures shared a root cause, but nope > they were really four different bugs :-(. I've now pushed fixes > for all four, and I hope you'll turn your fuzzer back on. This > is very valuable testing. Thanks Tom for fixing these promptly but more importantly for confirming that this was helpful... allows for similar effort going forward. - robins
Re: pgsql: Remove support for OpenSSL older than 1.1.0
Hi Daniel, On Mon, 2 Sept 2024 at 21:54, Daniel Gustafsson wrote: > > Remove support for OpenSSL older than 1.1.0 > I am trying to update my buildfarm animals for this, and although I fixed massasauga (essentially by skipping the test for now), I am unclear why snakefly still fails (now, much later into the cycle). Could you point me on how to fix snakefly? (I've tried to disable SSL tests, but that doesn't seem to be helping). https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snakefly&dt=2024-09-03%2009%3A56%3A46 - Thanks Robins
Re: pgsql: Use extended stats for precise estimation of bucket size in hash
Hi, On Mon, 10 Mar 2025 at 22:18, Alexander Korotkov wrote: > > Use extended stats for precise estimation of bucket size in hash join After this commit, I see a recurrence of an error similar to the one fixed in e28033fe1af8037e0fec8bb3a32fabbe18ac06b1 https://www.postgresql.org/message-id/18885-da51324078588253%40postgresql.org - robins https://robins.in
Re: pgsql: doc: Warn that ts_headline() output is not HTML-safe.
Hi, On Thu, 1 May 2025 at 19:43, Dean Rasheed wrote: > doc: Warn that ts_headline() output is not HTML-safe. > > Backpatch-through: 13 > > This commit looks harmless, but 2 separate machines are failing on this commit (at the same point). For now, it appears more like a compiler bug. I have requested a gcc account (to file a bug) but I wouldn't be surprised if these machines keep failing until that resolves (or until I fix a gcc compile flag etc). https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2025-05-01%2018%3A56%3A11 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snakefly&dt=2025-05-01%2019%3A21%3A05 (I'd expect v13 to fail soon too) Pasting the error here, in case someone can point me to something I'm doing wrong, or else, I'll revert once I have an update from GCC. postgres@dell:~/proj/postgres/src/backend/nodes$ gcc -v -save-temps -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-deprecated-non-prototype -Wno-format-truncation -Wno-stringop-truncation -g -O2 -std=gnu17 -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o nodeFuncs.o nodeFuncs.c Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: /opt/gcc/source/configure --prefix=/opt/gcc/target --disable-multilib : (reconfigured) /opt/gcc/source/configure --prefix=/opt/gcc/target --disable-multilib : (reconfigured) /opt/gcc/source/configure --prefix=/opt/gcc/target --disable-multilib --enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250501 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wmissing-prototypes' '-Wpointer-arith' '-Wdeclaration-after-statement' '-Werror=vla' '-Wendif-labels' '-Wsuggest-attribute=format' '-Wimplicit-fallthrough=3' '-Wcast-function-type' '-Wformat-security' '-fno-strict-aliasing' '-fwrapv' '-fexcess-precision=standard' '-Wno-deprecated-non-prototype' '-Wformat-truncation=0' '-Wno-stringop-truncation' '-g' '-O2' '-std=gnu17' '-I' '../../../src/include' '-D' '_GNU_SOURCE' '-I' '/usr/include/libxml2' '-c' '-o' 'nodeFuncs.o' '-mtune=generic' '-march=x86-64' /opt/gcc/prod/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/cc1 -E -quiet -v -I ../../../src/include -I /usr/include/libxml2 -imultiarch x86_64-linux-gnu -iprefix /opt/gcc/prod/bin/../lib/gcc/x86_64-pc-linux-gnu/16.0.0/ -D _GNU_SOURCE nodeFuncs.c -mtune=generic -march=x86-64 -std=gnu17 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wsuggest-attribute=format -Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -Wno-deprecated-non-prototype -Wformat-truncation=0 -Wno-stringop-truncation -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -fworking-directory -O2 -fpch-preprocess -o nodeFuncs.i ignoring nonexistent directory "/opt/gcc/prod/bin/../lib/gcc/x86_64-pc-linux-gnu/16.0.0/include-fixed/x86_64-linux-gnu" ignoring nonexistent directory "/opt/gcc/prod/bin/../lib/gcc/x86_64-pc-linux-gnu/16.0.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory "/opt/gcc/prod/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/16.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/opt/gcc/prod/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/16.0.0/include-fixed/x86_64-linux-gnu" ignoring duplicate directory "/opt/gcc/prod/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/16.0.0/include-fixed" ignoring nonexistent directory "/opt/gcc/prod/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/16.0.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: ../../../src/include /usr/include/libxml2 /opt/gcc/prod/bin/../lib/gcc/x86_64-pc-linux-gnu/16.0.0/include /opt/gcc/prod/bin/../lib/gcc/x86_64-pc-linux-gnu/16.0.0/include-fixed /usr/local/include /opt/gcc/prod/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wmissing-prototypes' '-Wpointer-arith' '-Wdeclaration-after-statement' '-Werror=vla' '-Wendif-labels' '-Wsuggest-attribute=format' '-Wimplicit-fallthrough=3' '-Wcast-function-type' '-Wformat-security' '-fno-strict-aliasing' '-fwrapv' '-fexcess-precision=standard' '-Wno-deprecated-non-prototype' '-Wformat-truncation=0' '-Wno-stringop-truncation' '-g' '-O2' '-std=gnu17' '-I' '../../../src/include' '-D' '_GNU_SOURCE' '-I' '/usr/include/libxml2' '-c' '-o' 'nodeFuncs.o' '-mtune=generic' '-march=x86-64' /opt/gcc/prod/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/cc1 -fpreprocessed nodeFuncs.i -quiet -dumpbase nodeFuncs.c -dumpbase-ext .c -mtune=generic -march=x86-64 -g -O2 -Wall -Wmissin
Re: pgsql: doc: Warn that ts_headline() output is not HTML-safe.
On Fri, 2 May 2025 at 07:28, Robins Tharakan wrote: > > So ideally if gcc fixes the issue (or if I fix something stupid in the way > I am > compiling gcc etc), the next buildfarm run should automatically go > green soon after. > Does look like a gcc bug. Ideally should go green automatically (once the proposed patch goes through). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 - robins
Re: pgsql: doc: Warn that ts_headline() output is not HTML-safe.
On Fri, 2 May 2025 at 06:57, Tom Lane wrote: > Robins Tharakan writes: > > On Thu, 1 May 2025 at 19:43, Dean Rasheed > wrote: > >> doc: Warn that ts_headline() output is not HTML-safe. > > > This commit looks harmless, but 2 separate machines are > > failing on this commit (at the same point). > > It's hardly likely that a docs-only commit is the cause. Did you > update the "experimental" compiler on those machines since their last > run? > > I agree. I did try to compile postgres (in a separate folder) with the recent-most gcc but this does seem to be happening even with the latest gcc commit (25921d66424) checked in ~40 min ago. For background, the machines are pretty aggressive [1] in updating gcc - retries every 15 min [2] . So ideally if gcc fixes the issue (or if I fix something stupid in the way I am compiling gcc etc), the next buildfarm run should automatically go green soon after. (I tried to auto-update the gcc string in postgres buildfarm programmatically - when recompiling gcc - but it just gets too noisy on the members page. Ideally it'd be just nicer if gcc -v could also give commit string, but I am not sure how to force that yet). - robins 1. https://github.com/robins/gcc_compile 2. robins@dell:/opt/gcc$ tail -20 build.log gcs09da 20250502_0615 - make successful gcs09da 20250502_0616 - make install successful. gcs09da 20250502_0616 - Postgres Buildfarm process not running (0). Good. gcs09da 20250502_0616 - gcc version string has changed from [16.0.0 20250501 (experimental) - b6d37ec1dd2] to [16.0.0 20250501 (experimental) - 87c4460024d] gcs2d5a 20250502_0630 - git checkout successful. gcs2d5a 20250502_0630 - git pull successful. gcs2d5a 20250502_0630 - No change in gcc version. Quitting. gcs6cc4 20250502_0645 - git checkout successful. gcs6cc4 20250502_0645 - git pull successful. gcs6cc4 20250502_0645 - gcc has changed - [87c4460024d] vs [25921d66424]. Recompiling. gcs6cc4 20250502_0647 - make successful gcs6cc4 20250502_0648 - make install successful. gcs6cc4 20250502_0648 - Postgres Buildfarm process not running (0). Good. gcs6cc4 20250502_0648 - gcc version string has changed from [16.0.0 20250501 (experimental) - 87c4460024d] to [16.0.0 20250501 (experimental) - 25921d66424] gcs0df0 20250502_0700 - git checkout successful. gcs0df0 20250502_0700 - git pull successful. gcs0df0 20250502_0700 - No change in gcc version. Quitting.
Re: pgsql: Track unpruned relids to avoid processing pruned relations
Hi Amit, On Fri, 7 Feb 2025 at 18:45, Amit Langote wrote: > Track unpruned relids to avoid processing pruned relations > > Since this change, the SQL in the bug-report #18830 [1] segfaults reliably. The SQL was tested with commits as recent as 15a79c7311 (2nd March), so it appears unrelated to the other Merge fixes that went in. Ref: 1. https://www.postgresql.org/message-id/18830-1f31ea1dc930d444%40postgresql.org - robins
Re: pgsql: Trial fix for old cross-version upgrades.
On Sat, 1 Mar 2025 at 03:42, Sami Imseih wrote: > I was running "make check-world" this morning on a machine that has an > old version of perl, 5.16, and the check-world was hung on > /usr/bin/perl t/002_pg_upgrade.pl. > FWIW, both massasauga / snakefly were stuck owing to this for the past few days. Force restarting, they're both back online. - robins
