Skip site navigation (1) Skip section navigation (2)

Re: Notify system doesn't recover from "No space" error

From: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>,pgsql-hackers(at)postgresql(dot)org, Joachim Wieland <joe(at)mcknight(dot)de>
Subject: Re: Notify system doesn't recover from "No space" error
Date: 2012-07-25 14:04:45
Message-ID: 20120725140445.GH23775@msgid.credativ.de (view raw or flat)
Thread:
Lists: pgsql-hackers
Re: Tom Lane 2012-07-02 <18088(dot)1341245035(at)sss(dot)pgh(dot)pa(dot)us>
> Christoph Berg <christoph(dot)berg(at)credativ(dot)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.  Please check into
> that more closely.  (It might be worth looking at $PGDATA/pg_notify/
> after a restart just to verify there are no files there except 0000.)

Hi,

we deployed an updated 9.1.4 package with your patch there. After
restarting the server, pg_notify was empty except for 0000. fsck.ext3
reported no errors.

Now the error has happened again, 58P01, could not read status of
transaction 0, could not open pg_notify/0016, ENOENT, location
SlruReportIOError, slru.c:840. (Roughly translated from the German
message.)

We'll try to dig into the code here, maybe we can spot something.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-07-25 17:01:13
Subject: Re: [BUGS] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
Previous:From: Alexander LawDate: 2012-07-25 11:54:23
Subject: Re: BUG #6742: pg_dump doesn't convert encoding of DB object names to OS encoding

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group