Re: [HACKERS] increasing the default WAL segment size

Поиск
Список
Период
Сортировка
От Beena Emerson
Тема Re: [HACKERS] increasing the default WAL segment size
Дата
Msg-id CAOG9ApEu8bXVwBxkOO9J7ZpM76TASK_vFMEEiCEjwhMmSLiaqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] increasing the default WAL segment size  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] increasing the default WAL segment size  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Wed, Aug 30, 2017 at 4:43 AM, Andres Freund <andres@anarazel.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

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Richard Guo
Дата:
Сообщение: [HACKERS] CurrentUserId may be invalid during the rest of a session
Следующее
От: Magnus Hagander
Дата:
Сообщение: [HACKERS] log_destination=file