Hi, On 2016-08-29 11:25:39 +0800, Craig Ringer wrote: > ERROR: could not access status of transaction 778793573 > DETAIL: could not open file "pg_clog/02E6": No such file or directory > > What I'd really like is to be able to ask transam.c to handle the > xid_in_recent_past logic, treating an attempt to read an xid from > beyond the clog truncation threshold as a soft error indicating > unknown xact state. But that involves delving into slru.c, and I > really, really don't want to touch that for what should be a simple > and pretty noninvasive utility function.
Can't you "just" check this against ShmemVariableCache->oldestXid while holding appropriate locks? > A PG_TRY to trap ERRCODE_UNDEFINED_FILE seems like it'd be sufficient, > except for two issues: It seems like a bad idea to PG_CATCH and not re-throw an error. That generally is quite error prone. At the very least locking and such gets a lot more complicated (as you noticed below). > * TransactionIdGetStatus() releases the CLogControlLock taken by > SimpleLruReadPage_ReadOnly() on normal exit but not after an exception > thrown from SlruReportIOError(). It seems appropriate for > SimpleLruReadPage() to release the LWLock before calling > SlruReportIOError(), so I've done that as a separate patch (now 0001). We normally prefer to handle this via the "bulk" releases in the error handlers. It's otherwise hard to write code that handles these situations reliably. It's different for spinlocks, but those normally protect far smaller regions of code. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
