MIME-Version: 1.0
References: <CACG9ogyCjz6yBKBuTX=686CypkgQj+RjrtAw2Skj1Q=0AxxG3Q@mail.gmail.com>
In-Reply-To: <CACG9ogyCjz6yBKBuTX=686CypkgQj+RjrtAw2Skj1Q=0AxxG3Q@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Mon, 20 May 2024 23:01:05 +1200
Message-ID: <CAApHDvqL3X+1QyapTchBvLbsLHHcYXRwtGEEb7PK2kpi4tc4Nw@mail.gmail.com>
Subject: Re: signal 11: Segmentation fault ; query constraint list; pg16.3
To: milist ujang <ujang.milist@gmail.com>
Cc: pgsql-general@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAApHDvqL3X%2B1QyapTchBvLbsLHHcYXRwtGEEb7PK2kpi4tc4Nw%40mail.gmail.com>
Precedence: bulk

On Mon, 20 May 2024 at 22:32, milist ujang <ujang.milist@gmail.com> wrote:
>
> postgres 16.1; rocky 9.3
>
> when connect to database postgres this query is OK, but run on user database, got segmentation fault.

I tried your query on 16.1 and I'm unable to reproduce the crash.

Are you able to recreate this on a freshly installed instance after
creating the table in question? If not, does it crash after you do a
pg_dump --schema-only from the problem database and restoring that to
the fresh instance and running ANALYZE? The crash may depend on the
query plan chosen and that will depend on the schema in that database.

We're probably going to need a recreator script for this. You might be
able to come up with one from doing the --schema-only dump and
restoring that somewhere and dropping unrelated objects to find the
minimum set you need for the crash.

Alternatively, a stack trace would be useful. See:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

David