Re: BUG #3362: xlog corruption just after initdb on irix

On Tue, 2007-06-05 at 14:42 +0000, Herve Boulouis wrote:

> PostgreSQL version: 8.2.4
> Operating system: IRIX 6.5.26

Thats not yet a supported system, but we should fix this.

> Jun 5 15:23:11 6T:origin300 postgres[2009]: [5-1] LOG: database system is
> shut down
> * 2d start
> Jun 5 15:23:17 6T:origin300 postgres[2027]: [1-1] LOG: could not create
> IPv6 socket: Address family not supported by protocol family
> Jun 5 15:23:17 6T:origin300 postgres[2027]: [2-1] LOG: could not create
> socket for statistics collector: Address family not supported by protocol
> family
> Jun 5 15:23:17 6T:origin300 postgres[2027]: [3-1] LOG: trying another
> address for the statistics collector
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [4-1] LOG: database system was
> shut down at 2007-06-05 15:23:11 GMT
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [5-1] LOG: record with zero
> length at 0/486718
> * vvv I believe this line is not normal, as there was a clean shutdown
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [6-1] LOG: invalid primary
> checkpoint record
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [7-1] LOG: using previous
> checkpoint record at 0/4866C8
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [8-1] LOG: redo record is at
> 0/4866C8; undo record is at 0/0; shutdown TRUE
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [9-1] LOG: next transaction
> ID: 0/593; next OID: 10820
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [10-1] LOG: next MultiXactId:
> 1; next MultiXactOffset: 0
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [11-1] LOG: database system
> was not properly shut down; automatic recovery in progress
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [12-1] LOG: record with zero
> length at 0/486718
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [13-1] LOG: redo is not
> required
> Jun 5 15:23:17 6T:origin300 postgres[2028]: [14-1] LOG: database system is
> ready

Well, I'd question what's going on with the hardware/filesystem or the
settings you've chosen for fsync and wal_fsync.

If you shut it down cleanly, yet its flaky when it comes back up that
doesn't sound too much like a database problem to me...

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com