"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> We got three errors in the log with exactly this DETAIL (file,
> offset and message):
> [2012-02-05 01:27:36.878 CST] 14892 <cc cc 127.0.0.1(35320)> ERROR:
> could not access status of transaction 0
> [2012-02-05 01:27:36.878 CST] 14892 <cc cc 127.0.0.1(35320)> DETAIL:
> Could not write to file "pg_notify/03A5" at offset 188416: No space
> left on device.
> After that the message changed to a new offset and a message of
> "Success." for the failure:
> [2012-02-05 01:30:36.952 CST] 16383 <cc cc 127.0.0.1(38931)> ERROR:
> could not access status of transaction 0
> [2012-02-05 01:30:36.952 CST] 16383 <cc cc 127.0.0.1(38931)> DETAIL:
> Could not read from file "pg_notify/03A5" at offset 253952:
> Success.
IIRC, the "could not access status of transaction" bits are artifacts
stemming from the use of the SLRU infrastructure for pg_notify access.
Sometime we ought to think a bit harder about how to specialize SLRU's
error messages for the cases where what it's manipulating aren't XIDs.
Also, the "Could not read ...: Success" bit presumably ought to be
spelled "Could not read ...: unexpected EOF". I thought we'd fixed
that most places, but we must've missed a spot in SLRU.
However, both of those points are just cosmetic. The substantive issue
is that you say it didn't resume normal behavior once space became
available again. Can you provide more info about that? In particular,
what behavior was being seen by the application?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
