Re: Segmentation fault - PostgreSQL 17.0

Hello.

After creating new database cluster (5433) in Postgresql 17 there was no problem with calling function
      select * from brin_page_items(
       get_raw_page(

On the pg_upgraded cluster I got this backtrace on sigsegv. Is this helpful or do I need to include any more information?

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00005627752205d5 in heap_compute_data_size (tupleDesc=tupleDesc(at)entry=0x5627a1df38c0, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/access/common/heaptuple.c:234
234 ./build/../src/backend/access/common/heaptuple.c: No such file or directory.
(gdb) bt
#0 0x00005627752205d5 in heap_compute_data_size (tupleDesc=tupleDesc(at)entry=0x5627a1df38c0, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/access/common/heaptuple.c:234
#1 0x0000562775221e4f in heap_form_minimal_tuple (tupleDescriptor=0x5627a1df38c0, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/access/common/heaptuple.c:1492
#2 0x00005627756f0e45 in tuplestore_putvalues (state=0x5627a1df3cc8, tdesc=<optimized out>, values=values(at)entry=0x7fff4744a450, isnull=isnull(at)entry=0x7fff4744a448)
at ./build/../src/backend/utils/sort/tuplestore.c:756
#3 0x00007fc7e2d0d9eb in brin_page_items (fcinfo=<optimized out>) at ./build/../contrib/pageinspect/brinfuncs.c:300
#4 0x00005627753d435c in ExecMakeTableFunctionResult (setexpr=0x5627a1df9370, econtext=0x5627a1df9258, argContext=<optimized out>, expectedDesc=0x5627a1dfa4e0, randomAccess=false)
at ./build/../src/backend/executor/execSRF.c:234
#5 0x00005627753e527a in FunctionNext (node=node(at)entry=0x5627a1df9050) at ./build/../src/backend/executor/nodeFunctionscan.c:93
#6 0x00005627753d4df9 in ExecScanFetch (recheckMtd=0x5627753e4f50 <FunctionRecheck>, accessMtd=0x5627753e4f80 <FunctionNext>, node=0x5627a1df9050)
at ./build/../src/backend/executor/execScan.c:131
#7 ExecScan (node=0x5627a1df9050, accessMtd=0x5627753e4f80 <FunctionNext>, recheckMtd=0x5627753e4f50 <FunctionRecheck>) at ./build/../src/backend/executor/execScan.c:180
#8 0x00005627753cb7bb in ExecProcNode (node=0x5627a1df9050) at ./build/../src/include/executor/executor.h:274
#9 ExecutePlan (execute_once=<optimized out>, dest=0x5627a1c89478, direction=<optimized out>, numberTuples=200, sendTuples=<optimized out>, operation=CMD_SELECT,
use_parallel_mode=<optimized out>, planstate=0x5627a1df9050, estate=0x5627a1df8e38) at ./build/../src/backend/executor/execMain.c:1648
#10 standard_ExecutorRun (queryDesc=0x5627a1cdeef0, direction=<optimized out>, count=200, execute_once=<optimized out>) at ./build/../src/backend/executor/execMain.c:365
#11 0x000056277557966e in PortalRunSelect (portal=0x5627a1d43188, forward=<optimized out>, count=200, dest=<optimized out>) at ./build/../src/backend/tcop/pquery.c:924
#12 0x000056277557a9b6 in PortalRun (portal=portal(at)entry=0x5627a1d43188, count=count(at)entry=200, isTopLevel=isTopLevel(at)entry=true, run_once=run_once(at)entry=false, dest=dest(at)entry=0x5627a1c89478,
altdest=altdest(at)entry=0x5627a1c89478, qc=0x7fff4744aa60) at ./build/../src/backend/tcop/pquery.c:768
#13 0x000056277557817e in exec_execute_message (max_rows=200, portal_name=0x5627a1c88fe8 "") at ./build/../src/backend/tcop/postgres.c:2255
#14 PostgresMain (dbname=<optimized out>, username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4834
#15 0x0000562775573423 in BackendMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ./build/../src/backend/tcop/backend_startup.c:105
#16 0x00005627754e366e in postmaster_child_launch (child_type=child_type(at)entry=B_BACKEND, startup_data=startup_data(at)entry=0x7fff4744ad70 "", startup_data_len=startup_data_len(at)entry=4,
client_sock=client_sock(at)entry=0x7fff4744ad90) at ./build/../src/backend/postmaster/launch_backend.c:277
#17 0x00005627754e7229 in BackendStartup (client_sock=0x7fff4744ad90) at ./build/../src/backend/postmaster/postmaster.c:3593
#18 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1674
#19 0x00005627754e8dbd in PostmasterMain (argc=<optimized out>, argv=0x5627a1c82f10) at ./build/../src/backend/postmaster/postmaster.c:1372
#20 0x0000562775212df0 in main (argc=5, argv=0x5627a1c82f10) at ./build/../src/backend/main/main.c:197
(gdb)

Best regards, Lubo

________________________________
From: Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk>
Sent: Monday, 11 November 2024 09:25
To: Peter Geoghegan <pg(at)bowt(dot)ie>; Tomas Vondra <tomas(at)vondra(dot)me>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Segmentation fault - PostgreSQL 17.0

Hello.

I am sending you the dump file from command:
      Postgres(at)hdoppxendb1:~$ PGOPTIONS="-c search_path=\"XEN_TS\"" psql -XAt -d "xtimeseries" -c "SELECT encode(get_raw_page('test_idxbrin', 2),'base64')" | base64 -d > dump_block_2.page

The steps for preparing table and index are:

CREATE TABLE test (
      cas int8 NULL
);

CREATE INDEX test_idxbrin ON test USING brin (cas) WITH (pages_per_range='32');

insert into test values (123)

analyse test

vacuum test

CREATE extension pageinspect;

SELECT brin_page_type(get_raw_page('test_idxbrin', 0));

select * from "XEN_TS".brin_metapage_info(get_raw_page('test_idxbrin',0));

select * from brin_revmap_data(get_raw_page('test_idxbrin',1)) limit 1000;

      [cid:8ee2db51-07e6-4d71-a134-5a6a5954a9d7]

select *
from brin_page_items(
get_raw_page('test_idxbrin',2),
'test_idxbrin'
);

Last select returns this error:

SQL Error [57P03]: FATAL: the database system is not yet accepting connections
Detail: Consistent recovery state has not been yet reached.

I am working on getting the backtrace.

Thank You.
 

Best regards, Lubo

________________________________
From: Peter Geoghegan <pg(at)bowt(dot)ie>
Sent: Saturday, 9 November 2024 16:53
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Ľuboslav Špilák <lspilak(at)microstep-hdo(dot)sk>; pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Segmentation fault - PostgreSQL 17.0

On Sat, Nov 9, 2024 at 7:01 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> Considering you're able to trigger the issue easily, it shouldn't be too
> difficult to attach GDB to a backend before running the query.
> Alternatively, you can enable core files, and generate the backtrace
> from that.

This query involves the use of a pageinspect function that accepts a
raw page image. There are some sanity checks of the page, but those
are quite lightweight. It's really not that hard to imagine it
segfaulting from a page image that passes those checks by mistake, but
is nevertheless not a valid BRIN page.

In any case this should be easy to debug: save the page image that the
function segfaults on, verify that it doesn't contain confidential
information, and then post it here. See:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#contrib.2Fpageinspect_page_dump

--
Peter Geoghegan
________________________________

Textom tejto emailovej správy odosielateľ nesľubuje ani neuzatvára za spoločnosť MicroStep – HDO s.r.o. žiadnu zmluvu, nakoľko naša spoločnosť uzatvára každú zmluvu výlučne v písomnej forme. Ak Vám bol tento e-mail zaslaný omylom, prosím upozornite odosielateľa a tento e-mail odstráňte.

The sender of this e-mail message does not promise nor shall conclude any contract on the behalf of the company MicroStep HDO s.r.o. as our company enters into any contract exclusively in writing. If you have been sent this email in error, please notify the sender and delete this email.