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?
> >> @@ -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?
Regards,
Andres