Re: [HACKERS] spgist recovery assertion failure
On 07/27/2015 04:24 PM, Michael Paquier wrote:
On Mon, Jul 27, 2015 at 2:33 PM, Piotr Stefaniak
postg...@piotr-stefaniak.me wrote:
On 07/27/2015 07:19 AM, Michael Paquier wrote:
On Mon, Jul 27, 2015 at 2:00 PM, Noah Misch n...@leadboat.com wrote:
When I caused a crash during the create_index regression test, recovery
hit an
assertion failure. Minimal test case:
psql -X EOSQL
CREATE TABLE t (c text);
INSERT INTO t SELECT 'P0123456789abcdef' FROM generate_series(1,1000);
INSERT INTO t VALUES ('P0123456789abcdefF');
CREATE INDEX ON t USING spgist (c);
EOSQL
pg_ctl -m immediate -w restart
On which platform are you seeing the failure? I am afraid I could not
reproduce the failure on Linux and OSX after testing it on HEAD.
I'm having the same symptoms with
159cff58cf3b565be3c17901698a74238e9e23f8 on Ubuntu Linux 3.4.39 armv7l.
Yes, on armv7l this can be indeed reproduced.
Fixed, thanks everyone! The problem was that in the WAL format change
patch, I had used char in a struct to hold -1, but char is unsigned
on PowerPC and ARM.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] spgist recovery assertion failure
On Mon, Jul 27, 2015 at 2:00 PM, Noah Misch n...@leadboat.com wrote:
When I caused a crash during the create_index regression test, recovery hit an
assertion failure. Minimal test case:
psql -X EOSQL
CREATE TABLE t (c text);
INSERT INTO t SELECT 'P0123456789abcdef' FROM generate_series(1,1000);
INSERT INTO t VALUES ('P0123456789abcdefF');
CREATE INDEX ON t USING spgist (c);
EOSQL
pg_ctl -m immediate -w restart
On which platform are you seeing the failure? I am afraid I could not
reproduce the failure on Linux and OSX after testing it on HEAD.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] spgist recovery assertion failure
When I caused a crash during the create_index regression test, recovery hit an
assertion failure. Minimal test case:
psql -X EOSQL
CREATE TABLE t (c text);
INSERT INTO t SELECT 'P0123456789abcdef' FROM generate_series(1,1000);
INSERT INTO t VALUES ('P0123456789abcdefF');
CREATE INDEX ON t USING spgist (c);
EOSQL
pg_ctl -m immediate -w restart
The log ends with:
29294 2015-07-27 04:41:43.330 GMT LOG: database system was not properly shut
down; automatic recovery in progress
29294 2015-07-27 04:41:43.330 GMT LOG: redo starts at 0/17A4070
TRAP: FailedAssertion(!(xldata-parentBlk == -1), File: spgxlog.c, Line:
338)
29292 2015-07-27 04:41:43.338 GMT LOG: startup process (PID 29294) was
terminated by signal 6: Aborted
29292 2015-07-27 04:41:43.338 GMT LOG: aborting startup due to startup process
failure
REL9_4_STABLE is unaffected. I suspect, but have not checked, that a standby
replaying WAL from a cluster running make installcheck would observe the
same problem.
Thanks,
nm
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] spgist recovery assertion failure
On Mon, Jul 27, 2015 at 02:19:09PM +0900, Michael Paquier wrote:
On Mon, Jul 27, 2015 at 2:00 PM, Noah Misch n...@leadboat.com wrote:
When I caused a crash during the create_index regression test, recovery hit
an
assertion failure. Minimal test case:
psql -X EOSQL
CREATE TABLE t (c text);
INSERT INTO t SELECT 'P0123456789abcdef' FROM generate_series(1,1000);
INSERT INTO t VALUES ('P0123456789abcdefF');
CREATE INDEX ON t USING spgist (c);
EOSQL
pg_ctl -m immediate -w restart
On which platform are you seeing the failure? I am afraid I could not
reproduce the failure on Linux and OSX after testing it on HEAD.
I saw it on ppc64 Fedora and on {ppc32 PostgreSQL, ppc64 kernel} AIX. Like
you, I don't see it on x86_64 Ubuntu. Perhaps it is specific to big-endian.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
