RE: BUG #17906: Segmentation fault and database crash during procedure call - Mailing list pgsql-bugs

From Vaclav Pink
Subject RE: BUG #17906: Segmentation fault and database crash during procedure call
Date
Msg-id DU2PR04MB9193888CBEF0AB01B65C6144F36F9@DU2PR04MB9193.eurprd04.prod.outlook.com
Whole thread Raw
In response to Re: BUG #17906: Segmentation fault and database crash during procedure call  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #17906: Segmentation fault and database crash during procedure call  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Good afternoon guys,

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

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) -
datatypesvarchar 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@paquier.xyz>
Sent: Monday, May 1, 2023 9:41 AM
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vaclav Pink <vaclav.pink@tietoevry.com>; pgsql-bugs@lists.postgresql.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_dictionaryand 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
yousend a sample of data, also make sure to mask anything sensitive. 
--
Michael



pgsql-bugs by date:

Previous
From: Kieran McCusker
Date:
Subject: Re: plpython does not honour max-rows
Next
From: Alexander Lakhin
Date:
Subject: Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger