Prev: [HACKERS] walwriter not closing old files
Next: pgstatindex still throws ERROR: value "3220078592" is out of range for type integer
From: "Kevin Grittner" on 9 Jun 2010 08:04 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 9 Jun 2010 08:12 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 9 Jun 2010 08:12
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 |