... at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=572ec03cbec4690eeb5c1047b378626fe475d218
Please send comments/corrections by Sunday.
regards, tom lane
Nathan Bossart writes:
> I've just committed 0a883a0 to v17. I'm not sure if that's worth
> mentioning, though.
Yeah, I concluded it probably isn't. (I do normally add in any
last-minute commits on the release Sunday.)
regards, tom lane
On Fri, Nov 08, 2024 at 04:42:14PM -0500, Tom Lane wrote:
> I've finished the first draft of 17.1 release notes; see
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4145ea0910d7bdbf131aa6514ffce8eb92230a5f
>
> Please send comments/corrections by Sunday.
I've just committed
I've finished the first draft of 17.1 release notes; see
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4145ea0910d7bdbf131aa6514ffce8eb92230a5f
Please send comments/corrections by Sunday.
regards, tom lane
I've finished the first draft of 16.1 release notes; see
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1e774846b870a858f8eb88b3f512562009177f45
Please send comments/corrections by Sunday.
regards, tom lane
On 11/7/22 10:30 AM, Jonathan S. Katz wrote:
On 11/6/22 11:14 AM, Tom Lane wrote:
Justin Pryzby writes:
+ Fix planner failure with extended statistics on partitioned
tables
+ (Richard Guo, Justin Pryzby)
This can also happen with inheritance tables.
+ Add missing guards f
On 11/6/22 11:14 AM, Tom Lane wrote:
Justin Pryzby writes:
+ Fix planner failure with extended statistics on partitioned tables
+ (Richard Guo, Justin Pryzby)
This can also happen with inheritance tables.
+ Add missing guards for NULL connection pointer
Maybe should be N
Justin Pryzby writes:
> + Fix planner failure with extended statistics on partitioned tables
> + (Richard Guo, Justin Pryzby)
> This can also happen with inheritance tables.
> + Add missing guards for NULL connection pointer
> Maybe should be NULL or NULL ?
Done, thanks.
On Fri, Nov 04, 2022 at 12:47:40PM -0400, Tom Lane wrote:
> I committed draft release notes at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bc62182f0afe6b01fec45b8d26df03fc9de4599a
+ Fix planner failure with extended statistics on partitioned tables
+ (Richard
I committed draft release notes at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bc62182f0afe6b01fec45b8d26df03fc9de4599a
Please send comments/corrections by Sunday.
regards, tom lane
... at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=aab05919a685449826db986a921c1d8632d673e0
Please send corrections and comments by Sunday.
regards, tom lane
Alvaro Herrera writes:
> I suppose you're aware of this, so I just want to get it on record that
> this entry
> +
> +
> + Fix use-after-free bug in saving tuples for AFTER
> + triggers (Amit Langote)
> +
> only goes back to 12; the commit to 11 was just to add the test case.
On 2021-May-07, Tom Lane wrote:
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
I suppose you're aware of this, so I just want to get it on record that
this entry
+
+
+ Fix use-after-free bug in saving tuples for AFTER
"Jonathan S. Katz" writes:
> Are there going to be any tzdata changes?
Nope, they're still on 2021a:
https://www.iana.org/time-zones
regards, tom lane
On 5/7/21 12:22 PM, Tom Lane wrote:
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
Thanks!
> As usual, please send comments/corrections by Sunday.
==snip=
A previous bug fix caused environment variables (such as PGPORT) to
over
Matthias van de Meent writes:
> I see similar (if not duplicate) entries for a "COMMIT AND CHAIN"
> issue, committed at nearly the same time, and both by Fujii Masao. Are
> these the same / should they be contained in one entry?
>> +Author: Fujii Masao
>> +Branch: master [8a55cb5ba] 2021-02-19 2
On Fri, 7 May 2021 at 18:23, Tom Lane wrote:
>
> See
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
>
> As usual, please send comments/corrections by Sunday.
I noticed only one potential issue.
I see similar (if not duplicate) entrie
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f4bab7f4a0e42ee9fa14707f726017b7869386b
As usual, please send comments/corrections by Sunday.
regards, tom lane
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
28 matches
Mail list logo
