Re: HS/SR Assert server crash

Bruce Momjian wrote:
> I was able to easily crash the standby server today just by starting it
> and connecting to it via psql.  The master was idle.  The failure was:
> 
>     LOG:  streaming replication successfully connected to primary
>     TRAP: FailedAssertion("!(((xmax) >= ((TransactionId) 3)))", File: "procarray.c", Line: 1211)
>     LOG:  server process (PID 12761) was terminated by signal 6: Abort trap
>     LOG:  terminating any other active server processes
> 
> My master postgresql.conf was:
> 
>     wal_level = hot_standby                 # minimal, archive, or hot_standby
>     archive_mode = on               # allows archiving to be done
>     archive_command = 'cp -i %p /u/pg/archive/%f < /dev/null '  # command to use to archive a logfile segment
>     max_wal_senders = 1             # max number of walsender processes
> 
> My slave postgresql.conf was:
> 
>     port = 5433                             # (change requires restart)
>     wal_level = hot_standby                 # minimal, archive, or hot_standby
>     archive_mode = off              # allows archiving to be done
>     archive_command = 'cp -i %p /u/pg/archive/%f < /dev/null '      # command to use to archive a logfile segment
>     hot_standby = on                # allows queries during recovery
>     max_wal_senders = 1             # max number of walsender processes
> 
> and my slave recovery.conf was:
> 
>     restore_command = 'cp /u/pg/archive/%f %p'              # e.g. 'cp /mnt/server/archivedir/%f %p'
>     standby_mode = 'on'
>     primary_conninfo = 'host=localhost port=5432'           # e.g. 'host=localhost port=5432'
> 
> Let me know what additional information I can supply.

I saw Simon's commit fixing this bug.  Another good reason we didn't
bundle 9.0 beta2 yesterday.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com