Dear Abrahim,
> Hi Hayato and Shlok, I confirmed that it is related of Citus, everytrhing
> worked
> after remove the Citus instalation from the docker image.
Thanks for the confirmation. I also feel that the issue is related with Citus.
I recommend
to report the Citus's community [1] to solve
Hi Hayato and Shlok, I confirmed that it is related of Citus, everytrhing
worked after remove the Citus instalation from the docker image.
I did not added stack trace yet on the new instalation. It seems that the
present Citus installation was done in an unusual way. I will work to figure
out a
Dear Abrahim
> The Citus extension package is installed, but it is not preload on
> shared_preload_libraries
> and citus extesion is not created.
It is possible that a shared library is loaded even if shared_preload is not set
and CREATE EXTENSION is not executed. Per my understanding the specif
Thanks Hayato and Shlok, The Citus extension package is installed, but it is
not preload on shared_preload_libraries and citus extesion is not created.I
will create a new container without Citus extension package and adding stack
trace ( I think this is the one you're talking about) as soon as
Dear Shlok, Abrahim,
> Also, I was going to the logs on found:
> > > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414)
> SELECT 0 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08
> 14:57:08.653 UTC > LOG: Initializing CDC decoder
>
> This log is not present in Postg
On Wed, 9 Jul 2025 at 12:19, Shlok Kyal wrote:
>
> On Wed, 9 Jul 2025 at 11:43, abrahim abrahao wrote:
> >
> > I got error “server process was terminated by signal 11: Segmentation
> > fault” using pg_create_logical_replication_slot with pgoutput plugin
> > par
On Wed, 9 Jul 2025 at 11:43, abrahim abrahao wrote:
>
> I got error “server process was terminated by signal 11: Segmentation fault”
> using pg_create_logical_replication_slot with pgoutput plugin parameter and
> using test_decoding worked fine, any idea that is wrong?
>
>
I got error “server process was terminated by signal 11: Segmentation fault”
using pg_create_logical_replication_slot with pgoutput plugin parameter and
using test_decoding worked fine, any idea that is wrong?
Note: I am using docker container and I also updated shm-size from 1024mb to 2g
and
On 11/7/22 09:43, Tom Lane wrote:
Ron writes:
On 11/7/22 08:02, Tom Lane wrote:
call. It'd still be recommendable to pg_dumpall and restore into
a freshly-initdb'd cluster, because otherwise you can't be real
sure that you identified and cleared all the data corruption.
Why *just* pg_dumpall
Ron writes:
> On 11/7/22 08:02, Tom Lane wrote:
>> call. It'd still be recommendable to pg_dumpall and restore into
>> a freshly-initdb'd cluster, because otherwise you can't be real
>> sure that you identified and cleared all the data corruption.
> Why *just* pg_dumpall instead of "pg_dumpall --
On 11/7/22 08:02, Tom Lane wrote:
[snip]
call. It'd still be recommendable to pg_dumpall and restore into
a freshly-initdb'd cluster, because otherwise you can't be real
sure that you identified and cleared all the data corruption.
Why *just* pg_dumpall instead of "pg_dumpall --globals-only" an
On Mon, Nov 07, 2022 at 09:02:26AM -0500, Tom Lane wrote:
> Stefan Froehlich writes:
> > On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote:
> >> On 11/7/22 06:19, Laurenz Albe wrote:
> >>> Don't continue to work with that cluster even if everything seems OK now.
> >>> "pg_dumpall" and
Stefan Froehlich writes:
> On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote:
>> On 11/7/22 06:19, Laurenz Albe wrote:
>>> Don't continue to work with that cluster even if everything seems OK now.
>>> "pg_dumpall" and restore to a new cluster on good hardware.
>> Why would that be ne
On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote:
> On 11/7/22 06:19, Laurenz Albe wrote:
> >Don't continue to work with that cluster even if everything seems OK now.
> >"pg_dumpall" and restore to a new cluster on good hardware.
> Why would that be necessary if the original machine
On 11/7/22 06:19, Laurenz Albe wrote:
Don't continue to work with that cluster even if everything seems OK now.
"pg_dumpall" and restore to a new cluster on good hardware.
Why would that be necessary if the original machine works well now?
--
Mladen Gogala
Database Consultant
Tel: (347) 321-12
On Mon, 2022-11-07 at 11:17 +0100, Stefan Froehlich wrote:
> On Sun, Nov 06, 2022 at 09:48:32AM -0500, Tom Lane wrote:
> > Stefan Froehlich writes:
> > > > # create extension amcheck;
> > > > # select oid, relname from pg_class where relname
> > > > ='faultytablename_pkey';
> > > > [returns oid 5
On Sun, Nov 06, 2022 at 09:48:32AM -0500, Tom Lane wrote:
> Stefan Froehlich writes:
> > | # create extension amcheck;
> > | # select oid, relname from pg_class where relname ='faultytablename_pkey';
> > | [returns oid 537203]
> > | # select bt_index_check(537203, true);
> > | server closed the co
Stefan Froehlich writes:
> I am using v13, but well:
> | # create extension amcheck;
> | # select oid, relname from pg_class where relname ='faultytablename_pkey';
> | [returns oid 537203]
> | # select bt_index_check(537203, true);
> | server closed the connection unexpectedly
Oh ... up through
On Sun, Nov 06, 2022 at 09:13:08AM -0500, Tom Lane wrote:
> > | 2022-11-06 11:52:36.367 CET [2098-35] LOG: server process (PID 2964738)
> > was terminated by signal 11: Segmentation fault
> contrib/amcheck might help to identify the faulty data (at this
> point there's
Stefan Froehlich writes:
> I followed the suggestion to trace down the faulty record, found and
> fixed it. Now I can access that record again, but if I try to dump
> the table I get:
> | 2022-11-06 11:52:36.367 CET [2098-35] LOG: server process (PID 2964738)
> was terminat
I get:
| 2022-11-06 11:52:36.367 CET [2098-35] LOG: server process (PID 2964738) was
terminated by signal 11: Segmentation fault
| [...]
| 2022-11-06 11:53:46.229 CET [2964744-2] LOG: database system was not
properly shut down; automatic recovery in progress
| 2022-11-06 11:53:46.263 CET [296
On Mon, 27 Apr 2020 at 17:52, Tom Lane wrote:
>
> Radu Radutiu writes:
> > Can you guide me how to debug postgresql crash?
>
> A stack trace would be pretty useful.
>
> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
>
> regards, tom lane
Radu Radutiu writes:
> Can you guide me how to debug postgresql crash?
A stack trace would be pretty useful.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
partition tables crashed the
postgresql instance. I have in the log:
2020-04-26 17:35:50.065 EEST [8385] LOG: background worker "parallel
worker" (PID 32152) was terminated by signal 11: Segmentation fault
2020-04-26 17:35:50.065 EEST [8385] DETAIL: Failed process was running:
CREATE INDEX I
Hi Tom,
Thank you, we have that same scenario.
Regards
Gerrit
On Wed, 13 Nov 2019, 20:57 Tom Lane, wrote:
> Gerrit Fouche writes:
> > This is the second time I get this error since Postgresql 12 was
> officially
> > released. My version:
> > PostgreSQL 12.0 (Ubuntu 12.0-2.pgdg18.04+1) on x86_64
Gerrit Fouche writes:
> This is the second time I get this error since Postgresql 12 was officially
> released. My version:
> PostgreSQL 12.0 (Ubuntu 12.0-2.pgdg18.04+1) on x86_64-pc-linux-gnu,
> compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit
Given that this failed in an UPDATE, I
in the right direction to
solve it?
2019-11-13 11:18:31.296 SAST,,,5033,,5dc7a74d.13a9,75,,2019-11-10 07:59:41
SAST,,0,LOG,0,"server process (PID 17257) was terminated by signal 11:
Segmentation fault","Failed process was running: UPDATE stock_items SET
""
Thomas Munro writes:
> On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> If someone out there is not enabling any of that stuff
>>> because their system doesn't like threads, they can use
>>> --disable-thread-safety to avoid the effects of this change.
>> No, that's no
On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote:
> Thomas Munro writes:
> > If someone out there is not enabling any of that stuff
> > because their system doesn't like threads, they can use
> > --disable-thread-safety to avoid the effects of this change.
>
> No, that's nonsense; --disable-thread-
Thomas Munro writes:
> On Wed, Mar 20, 2019 at 10:51 AM Tom Lane wrote:
>> It's reasonable to assume that the proposed patch won't cause real issues
>> on any modern platform, but I'm not sure we can assume that for old ones,
>> so the whole thing is making me a bit nervous.
> Sure, it's possibl
On Wed, Mar 20, 2019 at 10:51 AM Tom Lane wrote:
> Thomas Munro writes:
> > Even though I can't reproduce the problem myself, I'm quite keen to go
> > ahead and push the patch I proposed for v12 anyway, and close this
> > case. Otherwise this problem could just keep coming back until
> > libldap
Thomas Munro writes:
> Even though I can't reproduce the problem myself, I'm quite keen to go
> ahead and push the patch I proposed for v12 anyway, and close this
> case. Otherwise this problem could just keep coming back until
> libldap.so is eventually entirely phased out by all distros. In 20
On Fri, Mar 15, 2019 at 4:46 PM Noah Misch wrote:
> Thanks. That rules out my guess. I don't have another guess at this time.
Even though I can't reproduce the problem myself, I'm quite keen to go
ahead and push the patch I proposed for v12 anyway, and close this
case. Otherwise this problem c
On Fri, Mar 15, 2019 at 12:10:59AM +0800, Mike Yeap wrote:
> Hi Noah, below is the output from one of the servers having this issue:
>
> $ echo "select pg_backend_pid(); load 'dblink'; select pg_sleep(100)" | psql
> -X &
> [1] 9731
>
> $ select pg_backend_pid(); load 'dblink'; select pg_sleep(10
Hi Noah, below is the output from one of the servers having this issue:
$ echo "select pg_backend_pid(); load 'dblink'; select pg_sleep(100)" |
psql -X &
[1] 9731
$ select pg_backend_pid(); load 'dblink'; select pg_sleep(100)
pg_backend_pid
9732
(1 row)
LOAD
$ gdb -
On Thu, Mar 14, 2019 at 05:18:49PM +1300, Thomas Munro wrote:
> On Thu, Mar 7, 2019 at 4:19 PM Noah Misch wrote:
> > Has anyone else reproduced this?
>
> I tried, but could not reproduce this problem on "CentOS Linux release
> 7.6.1810 (Core)" using OpenLDAP "2.4.44-21.el7_6" (same as Mike
> repo
On Thu, Mar 7, 2019 at 4:19 PM Noah Misch wrote:
> Has anyone else reproduced this?
I tried, but could not reproduce this problem on "CentOS Linux release
7.6.1810 (Core)" using OpenLDAP "2.4.44-21.el7_6" (same as Mike
reported, what yum install is currently serving up). I tried "make
check" in
On Thu, Mar 07, 2019 at 10:45:56AM +1300, Thomas Munro wrote:
> On Wed, Feb 27, 2019 at 11:28 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > I don't see pthread_is_threaded_np() on any non-Apple systems in my
> > > lab.
> >
> > Yeah, I thought that might be a Mac thing. I wonder if POSIX has
Adding Noah to thread.
On Wed, Feb 27, 2019 at 11:28 AM Tom Lane wrote:
> Thomas Munro writes:
> > I don't see pthread_is_threaded_np() on any non-Apple systems in my
> > lab.
>
> Yeah, I thought that might be a Mac thing. I wonder if POSIX has any
> usable equivalent.
I don't see anything lik
Thomas Munro writes:
> On Wed, Feb 27, 2019 at 3:57 AM Tom Lane wrote:
>> If pthread_is_threaded_np(), or something equivalent, is widely available
>> then it might be all right to try solving this going forward by switching
>> to libldap_r and seeing if anyone hits those cross-checks. I'd be af
On Wed, Feb 27, 2019 at 3:57 AM Tom Lane wrote:
> Thomas Munro writes:
> > Question
> > for the list: other stuff in the server needs libpthread (SSL, LLVM,
> > ...), so why are we insisting on using non-MT LDAP?
>
> The traditional reason for avoiding that is the risk of a server
> process becom
Thomas Munro writes:
> Question
> for the list: other stuff in the server needs libpthread (SSL, LLVM,
> ...), so why are we insisting on using non-MT LDAP?
The traditional reason for avoiding that is the risk of a server
process becoming multi-threaded. There are live bugs of that ilk
on Darwin
Greetings Mike,
* Mike Yeap (wkk1...@gmail.com) wrote:
> Hi Thomas, I see. guess I can't use LDAP authentication for now, :-(
If you're in an active directory environment, you should really be using
Kerberos for authentication and NOT LDAP anyway. LDAP-based
authentication involves sending t
On Tue, Feb 26, 2019 at 9:11 PM Thomas Munro wrote:
> On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote:
> > Hi Thomas, does that mean the bug is still there?
> I haven't tried to repro this myself, but it certainly sounds like it.
> It also sounds like it would probably go away if you switched to
Hi Thomas, I see. guess I can't use LDAP authentication for now, :-(
Hopefully this problem is solved in future version, thank you!
Regards,
Mike Yeap
On Tue, Feb 26, 2019 at 4:12 PM Thomas Munro wrote:
> On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote:
> > Hi Thomas, does that mean the b
On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote:
> Hi Thomas, does that mean the bug is still there?
Hi Mike,
I haven't tried to repro this myself, but it certainly sounds like it.
It also sounds like it would probably go away if you switched to a
Debian-derived distro, instead of a Red Hat-deri
Hi Thomas, does that mean the bug is still there?
Regards,
Mike Yeap
On Mon, Feb 25, 2019 at 4:06 PM Thomas Munro wrote:
> On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap wrote:
> > openldap-clients.x86_64 2.4.44-21.el7_6
> @updates
> > openldap-devel.i686
On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap wrote:
> openldap-clients.x86_64 2.4.44-21.el7_6
> @updates
> openldap-devel.i686 2.4.44-21.el7_6updates
> openldap-devel.x86_64 2.4.44-21.el7_6updates
>
Hi Tom, when I run "ldd /usr/pgsql-10/bin/postmaster" I got this output:
# ldd /usr/pgsql-10/bin/postmaster
linux-vdso.so.1 => (0x7ffd4ec65000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7eff8b5d3000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x7eff8b268000)
libpam.so.0 => /lib64/libpam.
Mike Yeap writes:
>> Are the "postgres" executable and libpq linked with the same version of
>> OpenLDAP?
> How should I check whether they are linked?
"ldd" should show the dependencies of whatever executable or library
you point it at.
regards, tom lane
> Are the "postgres" executable and libpq linked with the same version of
OpenLDAP?
How should I check whether they are linked?
My Postgres version is 10.6 and I have this output for "yum list | grep
ldap | sort":
$ yum list | grep ldap | sort
apr-util-ldap.x86_641.5.2-6.e
Laurenz Albe writes:
> Mike Yeap wrote:
>> I have encountered a problem related to LDAP authenticated session with
>> Postgres foreign data wrapper (postgres_fdw).
> Are the "postgres" executable and libpq linked with the same version of
> OpenLDAP?
And which version is that? (And which versi
D=1353 application="" user_name= database=
> host(port)=] LOG: server process (PID 26306) was terminated by signal 11:
> Segmentation fault
>
> 2019-02-20 14:53:30.496 SGT [PID=1353 application="" user_name= database=
> host(port)=] LOG: terminating any other
= database=
host(port)=] LOG: server process (PID 26306) was terminated by signal 11:
Segmentation fault
2019-02-20 14:53:30.496 SGT [PID=1353 application="" user_name= database=
host(port)=] LOG: terminating any other active server processes
I can reproduce it in a test server with
54 matches
Mail list logo
