Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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