Glauco Torres writes:
> Today I left to generate more core-dump, follow the return,
> (gdb) bt
> #0 tbm_comparator (left=left@entry=0x1d5ca08, right=right@entry=0x3acdb70)
> at tidbitmap.c:1031
> #1 0x00801268 in med3 (a=0x1d5ca08 "\350>\337\001", b=0x3acdb70
> , c=0x583ecd8 bounds>, c
>
> Might be worth comparing sha1sum's of the postgres executable between
> this server and one that's not having the problem, just to eliminate
> the corrupted-binary theory.
>
>
>
The return is the same for the two servers,
$ sha1sum /usr/pgsql-9.6/bin/postmaster
56bcb4d644a8b00f07e9bd42f9a3f02
Glauco Torres writes:
>> The system is a CentOS 7, and PG was installed using PGDG's YUM repository.
Might be worth comparing sha1sum's of the postgres executable between
this server and one that's not having the problem, just to eliminate
the corrupted-binary theory.
reg
>
> That would result in nonsensical gdb output, most likely; but Glauco's
> trace is internally consistent enough that I doubt gdb is lying to us.
> In any case, the crash is an observable fact :-(
>
>
> The system is a CentOS 7, and PG was installed using PGDG's YUM repository.
We are pretty sur
Merlin Moncure wrote:
> simple
> SELECT version();
> ...can give a lot of hints on who/what compiled the database if you don't
> know.
Probably, this is why Glauco included the output in his opening letter.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 2
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm. I'm not normally one to jump to the conclusion that something is a
>> compiler bug, but it's hard to explain this stack trace any other way.
>> The value of "n" passed to the inner invocation of pg_qsort should not
>> have been more than 29914, but
Tom Lane wrote:
> Glauco Torres writes:
> > (gdb) bt
> > #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c,
> > pb=pb@entry=0x1be06d2d06644)
> > at bufmgr.c:4137
> > #1 0x00801268 in med3 (a=0x7f6fa9ef4b2c "\177\006",
> > b=0x1be06d2d06644 ,
> > c=0x2fc9dfbb1815c , cmp=0x6a4d20
> >
On Wed, Jan 10, 2018 at 11:08 AM, Tom Lane wrote:
> Glauco Torres writes:
>> (gdb) bt
>> #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c,
>> pb=pb@entry=0x1be06d2d06644)
>> at bufmgr.c:4137
>> #1 0x00801268 in med3 (a=0x7f6fa9ef4b2c "\177\006",
>> b=0x1be06d2d06644 ,
>> c=0x2fc9
Glauco Torres writes:
> (gdb) bt
> #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c,
> pb=pb@entry=0x1be06d2d06644)
> at bufmgr.c:4137
> #1 0x00801268 in med3 (a=0x7f6fa9ef4b2c "\177\006",
> b=0x1be06d2d06644 ,
> c=0x2fc9dfbb1815c , cmp=0x6a4d20
> )
> at qsort.c:107
> #2 0x00
Hi group,
I'm using PG 9.6.6 and I have a problem with seg fault from every few days
to up to two week,
this server is a replica, the other servers (master, and other slaves) do
not have this problem.
I could not identify the problem, so I do not know what triggers the
problem, however I have the
10 matches
Mail list logo
