Re: patch to allow disable of WAL recycling
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Jerry Jelinek <jerry.jelinek@joyent.com>, Michael Paquier <michael@paquier.xyz>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Thomas Munro <thomas.munro@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-06T16:47:02Z
Lists: pgsql-hackers
On Wed, Mar 6, 2019 at 11:37 AM Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote: > Well, let's put the question another way. Is there any reason to allow > skipping zero filling if we are recycling? That seems possibly > dangerous. I can imagine turning off recycling but leaving on > zero-filling, although I don't have a concrete use case for it ATM. I think the short answer is that we don't know. Any filesystem where just writing the last byte of the file is good enough to guarantee that all the intervening space is allocated can skip zero-filling. Any system where creating new WAL files is faster than recycling old ones can choose to do it that way. I don't know how you can make a categorical argument that there can't be a system where one of those things -- either one -- is true and the other is false. At least to me, they seem like basically unrelated issues. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Add wal_recycle and wal_init_zero GUCs.
- 475861b2615d 12.0 landed
-
Add GUC and storage parameter to set the maximum size of GIN pending list.
- a1b395b6a26a 9.5.0 cited