Alvaro Herrera writes:
> After spending way too much time editing this line, I ended up with
> exactly what Tom proposed, so +1 for his version. I think "This
> controls" adds nothing very useful, and we don't have it anywhere else,
> except tcp_keepalives_count from where I also propose to remov
On 2022-Sep-16, Amit Kapila wrote:
> We only want to commit the changes to 15 (a) if those fixes a problem
> introduced in 15, or (b) those are for a bug fix. I think the error
> message improvements fall into none of those categories, we can map it
> to (b) but I feel those are an improvement in
On 2022-Sep-14, Kyotaro Horiguchi wrote:
> At Tue, 13 Sep 2022 22:38:46 -0400, Tom Lane wrote in
> > Kyotaro Horiguchi writes:
> > > I saw the following message recently modified.
> > >> This controls the maximum distance we can read ahead in the WAL to
> > >> prefetch referenced data blocks.
On Fri, Sep 16, 2022 at 12:29 PM Amit Kapila wrote:
>
> > > >
> > > > +1, I saw that today and thought it was outside our usual style.
> > > > The whole thing is awfully verbose for a GUC description, too.
> > > > Maybe
> > > >
> > > > "Maximum distance to read ahead in WAL to prefetch data blocks
On Fri, Sep 16, 2022 at 2:07 PM Kyotaro Horiguchi
wrote:
>
> At Fri, 16 Sep 2022 12:29:52 +0530, Amit Kapila
> wrote in
> > So, the change related to wal_decode_buffer_size needs to be
> > backpatched to 15 whereas other message changes will be HEAD only, am
> > I correct?
>
> Has 15 closed the
At Fri, 16 Sep 2022 12:29:52 +0530, Amit Kapila wrote
in
> So, the change related to wal_decode_buffer_size needs to be
> backpatched to 15 whereas other message changes will be HEAD only, am
> I correct?
Has 15 closed the entry? IMHO I supposed that all changes are applied
back(?) to 15.
reg
On Fri, Sep 16, 2022 at 11:46 AM Kyotaro Horiguchi
wrote:
>
> At Fri, 16 Sep 2022 12:10:05 +1200, Thomas Munro
> wrote in
> > On Wed, Sep 14, 2022 at 2:38 PM Tom Lane wrote:
> > > Kyotaro Horiguchi writes:
> > > > I saw the following message recently modified.
> > > >> This controls the maximu
At Fri, 16 Sep 2022 12:10:05 +1200, Thomas Munro wrote
in
> On Wed, Sep 14, 2022 at 2:38 PM Tom Lane wrote:
> > Kyotaro Horiguchi writes:
> > > I saw the following message recently modified.
> > >> This controls the maximum distance we can read ahead in the WAL to
> > >> prefetch referenced d
On Wed, Sep 14, 2022 at 2:38 PM Tom Lane wrote:
> Kyotaro Horiguchi writes:
> > I saw the following message recently modified.
> >> This controls the maximum distance we can read ahead in the WAL to
> >> prefetch referenced data blocks.
> > Maybe the "we" means "PostgreSQL program and you" but I
On Wed, Sep 14, 2022 at 7:45 AM Kyotaro Horiguchi
wrote:
>
> I saw the following message recently modified.
>
> > This controls the maximum distance we can read ahead in the WAL to prefetch
> > referenced data blocks.
>
> Maybe the "we" means "PostgreSQL program and you" but I see it
> somewhat o
At Tue, 13 Sep 2022 22:38:46 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > I saw the following message recently modified.
> >> This controls the maximum distance we can read ahead in the WAL to
> >> prefetch referenced data blocks.
> > Maybe the "we" means "PostgreSQL program and you
Kyotaro Horiguchi writes:
> I saw the following message recently modified.
>> This controls the maximum distance we can read ahead in the WAL to prefetch
>> referenced data blocks.
> Maybe the "we" means "PostgreSQL program and you" but I see it
> somewhat out of place.
+1, I saw that today and
12 matches
Mail list logo
