Re: [HACKERS] Notify system doesn't recover from No space error

2012-07-25 Thread Christoph Berg
Re: Tom Lane 2012-07-02 18088.1341245...@sss.pgh.pa.us Christoph Berg christoph.b...@credativ.de writes: What is still puzzling me is that the customer is repeatedly reporting these issues, even after rebooting the system. Hm. A server restart really ought to clear any problem in this

Re: [HACKERS] Notify system doesn't recover from No space error

2012-07-02 Thread Christoph Berg
Re: Tom Lane 2012-06-29 8308.1340933...@sss.pgh.pa.us in async.c that would try to create the missing page. This error will persist until the server is restarted (thus resetting the state of pg_notify), even if the underlying disk-full condition is cleared. Thanks for digging into this and

Re: [HACKERS] Notify system doesn't recover from No space error

2012-07-02 Thread Tom Lane
Christoph Berg christoph.b...@credativ.de writes: What is still puzzling me is that the customer is repeatedly reporting these issues, even after rebooting the system. Hm. A server restart really ought to clear any problem in this area, since pg_notify gets reset to starting conditions.

Re: [HACKERS] Notify system doesn't recover from No space error

2012-06-29 Thread Christoph Berg
[Resending as the original post didn't get through to the list] Warming up an old thread here - we ran into the same problem. Database is 9.1.4/x86_64 from Debian/testing. The client application is bucardo hammering the database with NOTIFYs (including some master-master replication conflicts,

Re: [HACKERS] Notify system doesn't recover from No space error

2012-06-28 Thread Tom Lane
Christoph Berg christoph.b...@credativ.de writes: Warming up an old thread here - we ran into the same problem. Thanks for the example proving it is repeatable. I dug into this a bit and found the problem. When a page of pg_notify is filled, asyncQueueAddEntries() advances the global

Re: [HACKERS] Notify system doesn't recover from No space error

2012-02-09 Thread Tom Lane
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

Re: [HACKERS] Notify system doesn't recover from No space error

2012-02-09 Thread Kevin Grittner
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

Re: [HACKERS] Notify system doesn't recover from No space error

2012-02-09 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: The application LISTENs on channel tcn and a trigger function is attached to most permanent tables to NOTIFY for DML on that channel. ... The report to us was that testers were unable to start the application. I believe that the above error

Re: [HACKERS] Notify system doesn't recover from No space error

2012-02-09 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: The application LISTENs on channel tcn and a trigger function is attached to most permanent tables to NOTIFY for DML on that channel. ... The report to us was that testers were unable to start the

Re: [HACKERS] Notify system doesn't recover from No space error

2012-02-09 Thread Kevin Grittner
Kevin Grittner kevin.gritt...@wicourts.gov wrote: In continued digging through logs I found something to indicate the transaction on which COMMIT failed for 2528 of the failures. In all cases the transaction made a change which would have fired a NOTIFY at commit (in a deferred trigger).