MIME-Version: 1.0
References: <CACG9ogyCjz6yBKBuTX=686CypkgQj+RjrtAw2Skj1Q=0AxxG3Q@mail.gmail.com>
 <CAApHDvqL3X+1QyapTchBvLbsLHHcYXRwtGEEb7PK2kpi4tc4Nw@mail.gmail.com>
In-Reply-To: <CAApHDvqL3X+1QyapTchBvLbsLHHcYXRwtGEEb7PK2kpi4tc4Nw@mail.gmail.com>
From: milist ujang <ujang.milist@gmail.com>
Date: Mon, 20 May 2024 18:18:30 +0700
Message-ID: <CACG9ogw1sGqX5vc=X9922tvN7dKJnazhnyjHXtF0ppY3=G=3ZA@mail.gmail.com>
Subject: Re: signal 11: Segmentation fault ; query constraint list; pg16.3
Cc: pgsql-general@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000001766030618e0dd49"
Archived-At: <https://www.postgresql.org/message-id/CACG9ogw1sGqX5vc%3DX9922tvN7dKJnazhnyjHXtF0ppY3%3DG%3D3ZA%40mail.gmail.com>
Precedence: bulk

--0000000000001766030618e0dd49
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

as of subject, it should be 16.3.

scenario was:
- a few months ago install + deployed user data pg 16.2.
- 2 days ago, updated to 16.3

now I can reproduce the issue, the segment fault comes from
postgres[495645]: segfault at 0 ip 00007f318b17e1f4 sp 00007ffc7f1b15d8
error 4 in citus.so[7f318b0a4000+ee000] likely on CPU 93 (core 1, socket 1)

after dropping the citus extension, now it's OK.

Thanks for the reply.


On Mon, May 20, 2024 at 6:01=E2=80=AFPM David Rowley <dgrowleyml@gmail.com>=
 wrote:

> 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_Postg=
reSQL_backend_on_Linux/BSD
>
> David
>


--=20
regards

ujang jaenudin | Self-Employed, DBA Consultant
http://id.linkedin.com/pub/ujang-jaenudin/12/64/bab

--0000000000001766030618e0dd49
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">as of subject, it should be 16.3.<div><br></div><div>scena=
rio was:</div><div>- a few months ago install + deployed user data pg 16.2.=
</div><div>- 2 days ago, updated to 16.3</div><div><br></div><div>now I can=
 reproduce the issue, the segment fault comes from=C2=A0</div><div>postgres=
[495645]: segfault at 0 ip 00007f318b17e1f4 sp 00007ffc7f1b15d8 error 4 in =
citus.so[7f318b0a4000+ee000] likely on CPU 93 (core 1, socket 1)<br></div><=
div><br></div><div>after dropping the citus=C2=A0extension, now it&#39;s OK=
.</div><div><br></div><div>Thanks for the reply.</div><div><br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon=
, May 20, 2024 at 6:01=E2=80=AFPM David Rowley &lt;<a href=3D"mailto:dgrowl=
eyml@gmail.com">dgrowleyml@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">On Mon, 20 May 2024 at 22:32, milist uj=
ang &lt;<a href=3D"mailto:ujang.milist@gmail.com" target=3D"_blank">ujang.m=
ilist@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; postgres 16.1; rocky 9.3<br>
&gt;<br>
&gt; when connect to database postgres this query is OK, but run on user da=
tabase, got segmentation fault.<br>
<br>
I tried your query on 16.1 and I&#39;m unable to reproduce the crash.<br>
<br>
Are you able to recreate this on a freshly installed instance after<br>
creating the table in question? If not, does it crash after you do a<br>
pg_dump --schema-only from the problem database and restoring that to<br>
the fresh instance and running ANALYZE? The crash may depend on the<br>
query plan chosen and that will depend on the schema in that database.<br>
<br>
We&#39;re probably going to need a recreator script for this. You might be<=
br>
able to come up with one from doing the --schema-only dump and<br>
restoring that somewhere and dropping unrelated objects to find the<br>
minimum set you need for the crash.<br>
<br>
Alternatively, a stack trace would be useful. See:<br>
<br>
<a href=3D"https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_runn=
ing_PostgreSQL_backend_on_Linux/BSD" rel=3D"noreferrer" target=3D"_blank">h=
ttps://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreS=
QL_backend_on_Linux/BSD</a><br>
<br>
David<br>
</blockquote></div><br clear=3D"all"><div><br></div><span class=3D"gmail_si=
gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><d=
iv dir=3D"ltr">regards<br><br>ujang jaenudin | Self-Employed, DBA Consultan=
t<br><a href=3D"http://id.linkedin.com/pub/ujang-jaenudin/12/64/bab" target=
=3D"_blank">http://id.linkedin.com/pub/ujang-jaenudin/12/64/bab</a><br></di=
v></div>

--0000000000001766030618e0dd49--