"Thomas F. O'Connell" <tfo@xxxxxxxxxxxx> writes:
> Could this be related to temp tables?
Possibly, given that the table doesn't seem to be there anymore.
> Does bgwriter operate on temp tables, and could there exist an edge
> condition in which bgwriter might have scheduled a write to disk for
> a file corresponding to a temp table that was removed by sudden
> termination of the session in which the temp table existed such that
> the file was removed?
Do you have some evidence that the bgwriter was what was reporting the
error? You didn't say that before.
The bgwriter only works on dirty shared buffers, so the only way this
could be happening is if a page of a temp table had gotten loaded into
a shared buffer, which isn't supposed to happen really. Is it possible
that you had some backend deliberately trying to read a temp table
created by another backend? (You don't have to assume that the
interloper tried to modify the table; a mere SELECT could have created
the dirty-buffer condition due to hint-bit update. You do have to
assume that the interloper was superuser, though, else permissions
would have stopped him from accessing someone else's temp table.)
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
