Re: Notify system doesn't recover from "No space" error
| От | Kevin Grittner |
|---|---|
| Тема | Re: Notify system doesn't recover from "No space" error |
| Дата | |
| Msg-id | 4F33B86A0200002500045111@gw.wicourts.gov обсуждение исходный текст |
| Ответ на | Re: Notify system doesn't recover from "No space" error (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Notify system doesn't recover from "No space" error
|
| Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@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
В списке pgsql-hackers по дате отправления: