Hi Tom,
`I take it things were okay with the version you used previously?`
Yes, it was working pretty well in another instance with pg version `12.4-1.pgdg18.04+1`, and we had to make a migration of one database that was running in this server to another using Logical Replication.
the process was basically this:
After this migration we started to have this kind of problem in both replica and primary servers.
`This looks pretty messed up. Are you sure the debug symbols you're using`
What exactly do you mean? I'm not too familiar with this debug toolings, the packages I've used were:
postgresql-14/focal-pgdg,now 14.5-2.pgdg20.04+2 arm64 [installed]
postgresql-14-dbgsym/focal-pgdg,now 14.5-2.pgdg20.04+2 arm64 [installed]
`Even better, can you construct a self-contained test case?`:
Actually I couldn't reproduce the problem because it's happening just in a production database, and it doesn't look to have a pattern in the cases when it happens.
Is there anything I could provide you to help the analysis ?
On Mon, Nov 7, 2022 at 3:08 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Willian Colognesi <willian_colognesi@xxxxxxxxxxx> writes:
> I started to use version `14.5-2.pgdg20.04+2` for a dedicated database and
> I'm facing many segmentation faults during the day when the database has
> more heavy queries.
I take it things were okay with the version you used previously?
What was that exactly? Has anything else changed?
> I could also get a little information from gdb, I'm not sure if it will
> help:
This looks pretty messed up. Are you sure the debug symbols you're using
match the package?
Even better, can you construct a self-contained test case?
regards, tom lane