On Thu, April 22, 2010 09:53, Heikki Linnakangas wrote: > Can you still reproduce this or has some of the changes since then fixed > it? We never quite figured out the cause..
I don't know for sure: >> Unfortunately, it does not happen always, or predictably. The only thing that I established after that email was sent, is that the error can also occur without the postbio package being been installed (this has happened once). It's a very easy test; I will probably run it a few more times. > 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
