Jeff Amiel <[EMAIL PROTECTED]> writes:
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-1] jboss 92257 ERROR:
> could not access status of transaction 2107200825
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-2] jboss 92257 DETAIL:
> could not open file "pg_clog/07D9": No such file or directory
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-3] jboss 92257 CONTEXT:
> SQL statement "DELETE FROM audit_metadata WHERE user_id <> -1"
> pg_clog dir looks like this:
> -rw------- 1 pgsql wheel 262144 Jan 13 05:41 07DA
> -rw------- 1 pgsql wheel 262144 Jan 13 08:06 07DB
> -rw------- 1 pgsql wheel 90112 Jan 13 08:51 07DC
> Now that table, audit_metadata, is a temporary table (when accessed by jboss
> as it is here). There is a 'rea'l table with the same name, but only used by
> batch processes that connect to postgres.
Really? Wow, *that's* an interesting thought. Is it likely that that
temp table could contain many-hour-old data?
This seems unrelated to your issue with autovacuum (which should never
touch a temp table, and certainly isn't going to find one in template0)
... but I suddenly fear that we've missed a fundamental point about
pg_clog truncation. And WAL wraparound for that matter. To wit, a
sufficiently long-lived temp table could contain old XIDs, and there's
no way for anyone except the owning backend to clean them out, or even
guarantee that they're marked committed.
Thoughts?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
