Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> [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. > 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? The application LISTENs on channel tcn and a trigger function is attached to most permanent tables to NOTIFY for DML on that channel. (See the recently committed triggered_change_notification patch if you want to see the trigger function.) At this point it might be hard to determine (at least without re-creating the problem) whether it was only transactions which issued a NOTIFY, but the application never really got very far because of COMMIT statements failing with the above message. The report to us was that testers were unable to start the application. I believe that the above error on COMMIT kept the application from getting past initial tests that the connection was good. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
