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
46 matches
Mail list logo
