Re: [HACKERS] HS/SR Assert server crash

2010-05-15 Thread Simon Riggs
On Thu, 2010-05-13 at 18:01 -0400, 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

Thanks for the report. Fix applied. (Sorry for delay in replying)

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
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] HS/SR Assert server crash

2010-05-14 Thread Bruce Momjian
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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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


[HACKERS] HS/SR Assert server crash

2010-05-13 Thread Bruce Momjian
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.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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