Re: Assertion failure twophase.c (3) (testing HS/SR) - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Re: Assertion failure twophase.c (3) (testing HS/SR) |
Date | |
Msg-id | 4BD0008E.1030509@enterprisedb.com Whole thread Raw |
In response to | Re: Assertion failure twophase.c (3) (testing HS/SR) ("Erik Rijkers" <er@xs4all.nl>) |
Responses |
Re: Assertion failure twophase.c (3) (testing HS/SR)
|
List | pgsql-hackers |
Can you still reproduce this or has some of the changes since then fixed it? We never quite figured out the cause.. Erik Rijkers wrote: > On Thu, March 4, 2010 17:00, Erik Rijkers wrote: >> in a 9.0devel, primary+standby, cvs from 2010.03.04 01:30 >> >> With three patches: >> >> new_smart_shutdown_20100201.patch >> extend_format_of_recovery_info_funcs_v4.20100303.patch >> fix-KnownAssignedXidsRemoveMany-1.patch >> >> pg_dump -d $db8.4.2 | psql -d $db9.0devel-primary >> >> FailedAssertion, File: "twophase.c", Line: 1201. >> > > For the record, this still happens (FailedAssertion, File: "twophase.c", Line: 1201.) > (created 2010.03.13 23:49 cvs). > > Unfortunately, it does not happen always, or predictably. > > patches: > new_smart_shutdown_20100201.patch > extend_format_of_recovery_info_funcs_v4.20100303.patch > (both here: http://archives.postgresql.org/pgsql-hackers/2010-03/msg00446.php ) > > (fix-KnownAssignedXidsRemoveMany-1.patch has been committed, I think?) > > > I use commandlines like this to copy schemas across from 8.4.2 to 9.0devel: > pg_dump -c -h /tmp -p 5432 -n myschema --no-owner --no-privileges mydb \ > | psql -1qtA -h /tmp -p 7575 -d replicas > > (the copied schemas were together 175 GB) > > As I seem to be the only one who finds this, I started looking what could be unique in this > install: and it would be postbio, which we use for its gist-indexing on ranges > (http://pgfoundry.org/projects/postbio/). We use postbio's int_interval type as a column type. > But keep in mind that sometimes the whole dump+restore+replication completes OK. > > > Other installed modules are: > contrib/btree_gist > contrib/seg > contrib/adminpack > > log_line_prefix = '%t %p %d %u start=%s ' # slave > > pgsql.sr_hotslave/logfile: > > 2010-03-13 23:54:59 CET 15765 start=2010-03-13 23:54:59 CET LOG: database system was > interrupted; last known up at 2010-03-13 23:54:31 CET > cp: cannot stat `/var/data1/pg_stuff/dump/hotslave/replication_archive/000000010000000000000001': > No such file or directory > 2010-03-13 23:55:00 CET 15765 start=2010-03-13 23:54:59 CET LOG: entering standby mode > 2010-03-13 23:55:00 CET 15765 start=2010-03-13 23:54:59 CET LOG: redo starts at 0/1000020 > 2010-03-13 23:55:00 CET 15765 start=2010-03-13 23:54:59 CET LOG: consistent recovery state > reached at 0/2000000 > 2010-03-13 23:55:00 CET 15763 start=2010-03-13 23:54:59 CET LOG: database system is ready to > accept read only connections > TRAP: FailedAssertion("!(((xid) != ((TransactionId) 0)))", File: "twophase.c", Line: 1201) > 2010-03-14 05:28:59 CET 15763 start=2010-03-13 23:54:59 CET LOG: startup process (PID 15765) > was terminated by signal 6: Aborted > 2010-03-14 05:28:59 CET 15763 start=2010-03-13 23:54:59 CET LOG: terminating any other active > server processes > > > Maybe I'll try now to setup a similar instance without postbio, to see if the crash still occurs. > > hth, > > Erik Rijkers > > > -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
pgsql-hackers by date: