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: 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
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.
[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,
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
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
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
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
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
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).
10 matches
Mail list logo