On Sat, Nov 9, 2019 at 6:52 AM Tom Lane wrote:
>
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1add2e09b9a4c2d2c72ce51991fa4efaf577a29f
>
> Please send any corrections by Sunday.
>
I have read it once and didn't find any obvious errors.
--
With Regards,
Amit Kapil
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1add2e09b9a4c2d2c72ce51991fa4efaf577a29f
Please send any corrections by Sunday.
regards, tom lane
On Sat, Jun 15, 2019 at 06:05:00PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Jun 15, 2019 at 02:11:41PM -0700, Peter Geoghegan wrote:
> >> I agree that this isn't terribly significant in general. Your proposed
> >> wording seems better than what we have now, but a reference to INCLUD
On Sat, Jun 15, 2019 at 3:05 PM Tom Lane wrote:
> Thanks for the input, guys. What do you think of
>
> Avoid writing an invalid empty btree index page in the unlikely case
> that a failure occurs while processing INCLUDEd columns during a page
> split (Peter Geoghegan)
>
> The
Noah Misch writes:
> On Sat, Jun 15, 2019 at 02:11:41PM -0700, Peter Geoghegan wrote:
>> I agree that this isn't terribly significant in general. Your proposed
>> wording seems better than what we have now, but a reference to INCLUDE
>> indexes also seems like a good idea. They are the only type o
On Sat, Jun 15, 2019 at 02:11:41PM -0700, Peter Geoghegan wrote:
> On Sat, Jun 15, 2019 at 1:39 PM Noah Misch wrote:
> > To me, this text implies a cautious DBA should amcheck every index. Reading
> > the thread[1], I no longer think that. It's enough to monitor that VACUUM
> > doesn't start fai
On Sat, Jun 15, 2019 at 2:11 PM Peter Geoghegan wrote:
> On Sat, Jun 15, 2019 at 1:39 PM Noah Misch wrote:
> > To me, this text implies a cautious DBA should amcheck every index. Reading
> > the thread[1], I no longer think that. It's enough to monitor that VACUUM
> > doesn't start failing pers
On Sat, Jun 15, 2019 at 1:39 PM Noah Misch wrote:
> To me, this text implies a cautious DBA should amcheck every index. Reading
> the thread[1], I no longer think that. It's enough to monitor that VACUUM
> doesn't start failing persistently on any index. I suggest replacing this
> release note
On Fri, Jun 14, 2019 at 04:58:47PM -0400, Tom Lane wrote:
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0995cefa74510ee0e38d1bf095b2eef2c1ea37c4
> +
> +
> + Avoid corruption of a btree index in the unlikely case that a failure
> + occurs during key truncation
I've committed first-draft release notes for next week's
releases at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0995cefa74510ee0e38d1bf095b2eef2c1ea37c4
Please send any review comments by Sunday.
regards, tom lane
10 matches
Mail list logo