G'day Andres. On Tue, Nov 12, 2013 at 11:13 AM, Andres Freund <and...@2ndquadrant.com> wrote: > Hi, > > On 2013-11-12 10:56:55 -0500, J Smith wrote: >> G'day list. Didn't get any interest in pgsql-general, thought I'd try >> my luck here, which perhaps would be more fitting in case I've >> stumbled upon an edge case issue or something... > > Normally the bug report for/the -bugs mailing list is the right one for > things like this.
Ah, okay. I can redirect there if that's the better location. (Assuming it's a bug and not a misconfiguration on my part, although the configuration on these servers has been consistent since 9.0, and we've upgraded through each of the 9.x series while merging together new settings accordingly.) >> ERROR could not access status of transaction 4179979 >> Could not open file "pg_subtrans/003F": No such file or directory. > > A couple of question: > * Did you have any OS, hardware crashes? Haven't had any issues on this machine. > * Do you run with fsync=off or full_page_writes=off? Both fsync and full_page_writes are in their default "on" configurations. I'll post our full postgresql.conf below, as it is quite short. > * Could you post the pg_controldata output? Sure, posted below. > * Is it always the same xid? Seems to be different every time. > * Does SELECT count(*) FROM pg_prepared_xacts; return 0? Yes it does. Here's the postgresql.conf and pg_controldata dump. # postgresql.conf listen_addresses = '*' wal_level = hot_standby checkpoint_completion_target = 0.7 max_wal_senders = 3 wal_keep_segments = 64 logging_collector = off datestyle = 'iso, mdy' timezone = 'Canada/Eastern' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' default_statistics_target = 100 maintenance_work_mem = 1GB effective_cache_size = 44GB work_mem = 320MB wal_buffers = 4MB checkpoint_segments = 64 shared_buffers = 15GB max_connections = 200 # pg_controldata pg_control version number: 937 Catalog version number: 201306121 Database system identifier: 5942827484423487452 Database cluster state: in production pg_control last modified: Tue 12 Nov 2013 11:39:07 AM EST Latest checkpoint location: 30/50F7A180 Prior checkpoint location: 30/4914C428 Latest checkpoint's REDO location: 30/4CB2C450 Latest checkpoint's REDO WAL file: 00000001000000300000004C Latest checkpoint's TimeLineID: 1 Latest checkpoint's PrevTimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0/5138174 Latest checkpoint's NextOID: 3574036 Latest checkpoint's NextMultiXactId: 5762623 Latest checkpoint's NextMultiOffset: 11956824 Latest checkpoint's oldestXID: 1673 Latest checkpoint's oldestXID's DB: 1 Latest checkpoint's oldestActiveXID: 5138174 Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 1 Time of latest checkpoint: Tue 12 Nov 2013 11:35:37 AM EST Fake LSN counter for unlogged rels: 0/1 Minimum recovery ending location: 0/0 Min recovery ending loc's timeline: 0 Backup start location: 0/0 Backup end location: 0/0 End-of-backup record required: no Current wal_level setting: hot_standby Current max_connections setting: 200 Current max_prepared_xacts setting: 0 Current max_locks_per_xact setting: 64 Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Maximum size of a TOAST chunk: 1996 Date/time type storage: 64-bit integers Float4 argument passing: by value Float8 argument passing: by value Data page checksum version: 0 Cheers and thanks for the help all. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
