From: "Kevin Grittner" on
Magnus Hagander wrote:

> I've just applied the attached file to the walwriter, to solve a
> case when it keeps handles around to old xlog segments, preventing
> them from actually being removed, and as such also causing alerts
> in some monitoring systems.

Thanks! I wasted some time on these a while back; I'm sure this will
save others that kind of bother.

> The way to provoke the problem is:

The way I ran into it was to have a web application which only ran
read-only transactions. Sooner or later it would need to write a
page from the buffer to make space to read a new page, and then it
would forever be holding a WAL file open, even after it was deleted.

Previous thread on the topic starts here:

http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php

continuing here:

http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php

Resulting in a TODO listed with this description:

Close deleted WAL files held open in *nix by long-lived read-only
backends

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Magnus Hagander on
On Wed, Jun 9, 2010 at 14:04, Kevin Grittner
<Kevin.Grittner(a)wicourts.gov> wrote:
> Magnus Hagander �wrote:
>
>> I've just applied the attached file to the walwriter, to solve a
>> case when it keeps handles around to old xlog segments, preventing
>> them from actually being removed, and as such also causing alerts
>> in some monitoring systems.
>
> Thanks! �I wasted some time on these a while back; I'm sure this will
> save others that kind of bother.
>
>> The way to provoke the problem is:
>
> The way I ran into it was to have a web application which only ran
> read-only transactions. �Sooner or later it would need to write a
> page from the buffer to make space to read a new page, and then it
> would forever be holding a WAL file open, even after it was deleted.
>
> Previous thread on the topic starts here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php
>
> continuing here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php
>
> Resulting in a TODO listed with this description:
>
> Close deleted WAL files held open in *nix by long-lived read-only
> backends

That seems to be about the same, but not actually fixed by this one.
This fix *only* fixes it when this happens in the walwriter. Not in
regular backends. OTOH, this happened in non-readonly mode :) My
understanding is that the issue you're talking about happens with the
regular backends, not walwriter, right?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on
On 09/06/10 15:04, Kevin Grittner wrote:
> Magnus Hagander wrote:
>> The way to provoke the problem is:
>
> The way I ran into it was to have a web application which only ran
> read-only transactions. Sooner or later it would need to write a
> page from the buffer to make space to read a new page, and then it
> would forever be holding a WAL file open, even after it was deleted.
>
> Previous thread on the topic starts here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php
>
> continuing here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php
>
> Resulting in a TODO listed with this description:
>
> Close deleted WAL files held open in *nix by long-lived read-only
> backends

This patch only helps with walwriter, though, not backends. Your
scenario is probably even more common, but will need a different fix.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers