Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Beena Emerson
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id CAOG9ApEy9rc3_tMcTuoCuJbEgr6CKnsdTPgfX35h4tHd4ZOrMg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] increasing the default WAL segment size  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hello,

Thank you for your comments, I will post an updated patch soon.

On Fri, Mar 17, 2017 at 6:40 AM, Robert Haas <robertmhaas@gmail.com> wrote:

+assign_wal_segment_size(int newval, void *extra)

Why does a PGC_INTERNAL GUC need an assign hook?  I think the GUC
should only be there to expose the value; it shouldn't have
calculation logic associated with it.

The Checkpoint Segments and the UsableBytesInSegment had to be changed depending on the value of  wal_segment_size set during initdb. I will figure out another way to assign these values without using this assign_hook.


+               wal_segment_size = atoi(str_wal_segment_size);

So, you're comfortable interpreting --wal-segsize=1TB or
--wal-segsize=1GB as 1?  Implicitly, 1MB?

The option was intended to only accept values in MB as the original  config --with-wal-segsize option, unfortunately, the patch does not throw error as in the config option when the units are specified. 

Error with config option --with-wal-segsize=1MB
configure: error: Invalid WAL segment size. Allowed values are 1,2,4,8,16,32,64.

Should we imitate this behaviour and just add a check to see if it only contains numbers? or would it be better to allow the use of the units and make appropriate code changes?

--
Thank you, 

Beena Emerson

EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: [HACKERS] <> join selectivity estimate question
Next
From: Fabien COELHO
Date:
Subject: [HACKERS] Re: [BUGS] Problem in using pgbench's --connect(-C) and--rate=rate(-R rate) options together.