RE: BUG #17906: Segmentation fault and database crash during procedure call

Good afternoon guys,

Our DB admin tryed reproduce the issue in OCP (single node, cluster similar to original environment), but everything was OK.

Regarding the tables which are used in the procedure -

apim_users - basic table at this time with cca 10 rows, 10 columns, datatypes varchar and 2 boolean

data_dictionary - small table with cca 10 columns and 150 rows, procedure use only 11 rows (cut by where condition) - datatypes varchar and 2 boolean

domains - materialized view with 11 columns and cca 3500 rows. Datatypes varchar.

I'm sorry for not so much details about data, but we have very strict rules...

And regarding logs and info - Db admin sayed that nothing more from crash time, only messages which I sent earlier.

If something come on your mind, where can be problem, what can solve the issue, it will be very helpful.

Thank you very much.

Vaclav

-----Original Message-----
From: Michael Paquier <michael(at)paquier(dot)xyz>
Sent: Monday, May 1, 2023 9:41 AM
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vaclav Pink <vaclav(dot)pink(at)tietoevry(dot)com>; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17906: Segmentation fault and database crash during procedure call

On Fri, Apr 21, 2023 at 10:09:00AM -0400, Tom Lane wrote:
> Can't help you with such an incomplete bug report. If you could
> reduce the problem to a self-contained test case, we'd be happy to look at it.
> See

FYI, an isolated test case would require to know what's behind the definitions of the tables apim_users, data_dictionary and domains which are used as part of the procedure you are seeing to fail.
Likely this would require a sample of the data that fails.

Being able to get a backtrace of the crash could provide hints, though without a data sample that may be difficult. If you send a sample of data, also make sure to mask anything sensitive.
--
Michael