Обсуждение: PANIC: pg_xlog/000blah Invalid argument pg_resetxlog gives no relief

I'll keep it simple:  Postgres hates me, see below.  Thanks.


# rpm -q postgresql; uname -a
postgresql-8.4.5-1.fc13.x86_64
Linux hostname 2.6.36-1.fc13.x86_64 #1 SMP Tue Nov 2 23:39:09 EDT 2010 x86_64
x86_64 x86_64 GNU/Linux

# service postgresql start
Starting postgresql service:                               [  OK  ]

# ps aux |grep post
root     14926  0.0  0.0 103204   800 pts/7    S+   14:56   0:00 grep post

# tail -n3 /var/lib/pgsql/data/pg_log/postgresql-Wed.log
PANIC:  could not open file "pg_xlog/000000010000000100000023" (log file 1,
segment 35): Invalid argument
LOG:  startup process (PID 14922) was terminated by signal 6: Aborted
LOG:  aborting startup due to startup process failure

# su -l postgres -c "pg_resetxlog -f /var/lib/pgsql/data"
Transaction log reset

# service postgresql start
Starting postgresql service:                               [  OK  ]

# ps aux |grep post
root     14926  0.0  0.0 103204   800 pts/7    S+   14:56   0:00 grep post

# tail -n3 /var/lib/pgsql/data/pg_log/postgresql-Wed.log
PANIC:  could not open file "pg_xlog/000000010000000100000024" (log file 1,
segment 36): Invalid argument
LOG:  startup process (PID 16536) was terminated by signal 6: Aborted
LOG:  aborting startup due to startup process failure

# tail -n4 /var/log/messages
Nov  3 15:43:08 hq2 abrt[16537]: saved core dump of pid 16536
(/usr/bin/postgres) to /var/spool/abrt/ccpp-1288813387-16536.new/coredump
(30986240 bytes)
Nov  3 15:43:08 hq2 abrtd: Directory 'ccpp-1288813387-16536' creation detected
Nov  3 15:43:08 hq2 abrtd: Crash is in database already (dup of
/var/spool/abrt/ccpp-1288794001-5932)
Nov  3 15:43:08 hq2 abrtd: Deleting crash ccpp-1288813387-16536 (dup of
ccpp-1288794001-5932), sending dbus signal

Brian Neu <proclivity76@yahoo.com> writes:
> PANIC:  could not open file "pg_xlog/000000010000000100000023" (log file 1,
> segment 35): Invalid argument

We've seen this before --- the cause seems to be having wal_sync_method
set to open_sync or open_datasync when the filesystem doesn't actually
accept those open() options.  I gather you're running Fedora 13, but
what kind of filesystem is pg_xlog on?

            regards, tom lane

what kind of filesystem is pg_xlog on?

            regards, tom lane



Tom, you get gold star for today.  I had it on btrfs, but it was causing a
kernel crash, so booted in single user and moved it to zfs-fuse.

Wanna to go for 2 gold stars and suggest a solution that doesn't involve me
reformatting ?

[ please keep the list cc'd for the archives' sake ]

Brian Neu <proclivity76@yahoo.com> writes:
> Tom, you get gold star for today.  I had it on btrfs, but it was causing a
> kernel crash, so booted in single user mode and moved it to zfs-fuse.

> Wanna to go for 2 gold stars and suggest a solution that doesn't involve me
> reformatting ?

Just change wal_sync_method to whatever will work.  fsync is probably
the lowest common denominator.

            regards, tom lane