Re: increasing the default WAL segment size

From: Beena Emerson <memissemerson(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: increasing the default WAL segment size
Date: 2017-08-31 11:20:15
Message-ID: CAOG9ApEu8bXVwBxkOO9J7ZpM76TASK_vFMEEiCEjwhMmSLiaqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Wed, Aug 30, 2017 at 4:43 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2017-08-23 12:13:15 +0530, Beena Emerson wrote:
>> >> + /*
>> >> + * The calculation of XLOGbuffers requires the run-time parameter
>> >> + * XLogSegSize which is set from the control file. This value is
>> >> + * required to create the shared memory segment. Hence, temporarily
>> >> + * allocate space for reading the control file.
>> >> + */
>> >
>> > This makes me uncomfortable. Having to choose the control file multiple
>> > times seems wrong. We're effectively treating the control file as part
>> > of the configuration now, and that means we should move it's parsing to
>> > an earlier part of startup.
>>
>> Yes, this may seem ugly. ControlFile was originally read into the
>> shared memory segment but then we now need the XLogSegSize from the
>> ControlFile to initialise the shared memory segment. I could not
>> figure out any other way to achieve this.
>
> I think reading it one into local memory inside the startup process and
> then copying it into shared memory from there should work?
>.

Done.

>
>> >> @@ -8146,6 +8181,9 @@ InitXLOGAccess(void)
>> >> ThisTimeLineID = XLogCtl->ThisTimeLineID;
>> >> Assert(ThisTimeLineID != 0 || IsBootstrapProcessingMode());
>> >>
>> >> + /* set XLogSegSize */
>> >> + XLogSegSize = ControlFile->xlog_seg_size;
>> >> +
>> >
>> > Hm, why do we have two variables keeping track of the segment size?
>> > wal_segment_size and XLogSegSize? That's bound to lead to confusion.
>> >
>>
>> wal_segment_size is the guc which stores the number of segments
>> (XLogSegSize / XLOG_BLCKSZ).
>
> wal_segment_size and XLogSegSize are the same name, spelt different, so
> if that's where we want to go, we should name them differently. But
> perhaps more fundamentally, I don't see why we need both: What stops us
> from just defining the GUC in bytes?

I made a few changes for this:
- Make XLogSegSize int instead of uint32
- Add a GUC_UNIT_BYT for the unit conversion so that show
wal_segment_size displays user-friendly values.
- track_activity_query_size unit is set to GUC_UNIT_BYT. This was
initially null because we did not have a unit for bytes. This may not
be necessary as it changes the output of SHOW command.

--

Beena Emerson

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

Attachment Content-Type Size
03-modify-xlog-macros_rebase.patch application/octet-stream 68.2 KB
02-initdb-configurable-walsegsize_v2.patch application/octet-stream 52.4 KB
01-add-XLogSegmentOffset-macro_rebase3.patch application/octet-stream 16.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2017-08-31 11:49:37 log_destination=file
Previous Message Richard Guo 2017-08-31 10:02:56 CurrentUserId may be invalid during the rest of a session