On Tue, Sep 15, 2020 at 11:30 AM Tom Lane wrote:
> Pushed, thanks for looking.
I think that the Postgres 13 release notes should mention the
enhancement to contrib/amcheck made by Alexander's commit d114cc53.
I suggest something along the lines of: "Make the cross-level
verification checks
On 9/15/20 2:30 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/15/20 2:11 PM, Tom Lane wrote:
>>> The other incompatibilities are only listed once, if they're minor.
>>> I was just about to commit the attached.
>
>> Even better. +1
>
> Pushed, thanks for looking.
Thanks for
"Jonathan S. Katz" writes:
> On 9/15/20 2:11 PM, Tom Lane wrote:
>> The other incompatibilities are only listed once, if they're minor.
>> I was just about to commit the attached.
> Even better. +1
Pushed, thanks for looking.
regards, tom lane
On 9/15/20 2:11 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/15/20 1:05 PM, Tom Lane wrote:
>>> After thinking a bit, I'm inclined to agree that we should move it
>>> to "Incompatibilities". It is a core server change (third-party
>>> extensions don't have a choice to opt out, as per
"Jonathan S. Katz" writes:
> On 9/15/20 1:05 PM, Tom Lane wrote:
>> After thinking a bit, I'm inclined to agree that we should move it
>> to "Incompatibilities". It is a core server change (third-party
>> extensions don't have a choice to opt out, as per postgis' issue),
>> and even if it's
On 9/15/20 1:05 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/15/20 12:05 PM, Tom Lane wrote:
>>> Ah. OK, we can certainly extend it to mention that. How about
>>> (not bothering with markup yet)
>>>
>>> Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
>>> +
"Jonathan S. Katz" writes:
> On 9/15/20 12:05 PM, Tom Lane wrote:
>> Ah. OK, we can certainly extend it to mention that. How about
>> (not bothering with markup yet)
>>
>> Remove support for upgrading unpackaged (pre-9.1) extensions (Tom Lane)
>> +
>> +The FROM option of CREATE EXTENSION is
On 9/15/20 12:05 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/15/20 11:45 AM, Tom Lane wrote:
>>> It is listed already in the "Additional Modules" section (about line 2940
>>> in release-13.sgml as of right now).
>
>> ...sort of. It talks about the feature, but does not talk about
"Jonathan S. Katz" writes:
> On 9/15/20 11:45 AM, Tom Lane wrote:
>> It is listed already in the "Additional Modules" section (about line 2940
>> in release-13.sgml as of right now).
> ...sort of. It talks about the feature, but does not talk about the
> syntax removal, which is what I was
On 9/15/20 11:45 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On a different note, I became aware of this[1] and noticed that dropping
>> "CREATE EXTENSION ... FROM" was not listed in the incompatibilities
>> section, so proposing the attached. I have no strong opinions on the
>> final
"Jonathan S. Katz" writes:
> On a different note, I became aware of this[1] and noticed that dropping
> "CREATE EXTENSION ... FROM" was not listed in the incompatibilities
> section, so proposing the attached. I have no strong opinions on the
> final wording, mainly wanted to get it listed.
It
On 9/15/20 9:49 AM, Jonathan S. Katz wrote:
> On 9/15/20 5:22 AM, Masahiko Sawada wrote:
>> On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
>> wrote:
>>>
>>> On 2020-09-09 22:57, Jonathan S. Katz wrote:
+
+
+ Parallelized vacuuming of B-tree indexes
+
+
"Jonathan S. Katz" writes:
> On 9/15/20 5:22 AM, Masahiko Sawada wrote:
>> On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
>> wrote:
>>> I don't think B-tree indexes are relevant here. AFAICT, this feature
>>> applies to all indexes.
> I'm not sure where I got B-tree from. I've attached a
On 9/15/20 5:22 AM, Masahiko Sawada wrote:
> On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
> wrote:
>>
>> On 2020-09-09 22:57, Jonathan S. Katz wrote:
>>> +
>>> +
>>> + Parallelized vacuuming of B-tree indexes
>>> +
>>> +
>>
>> I don't think B-tree indexes are relevant
On Tue, 15 Sep 2020 at 13:56, Peter Eisentraut
wrote:
>
> On 2020-09-09 22:57, Jonathan S. Katz wrote:
> > +
> > +
> > + Parallelized vacuuming of B-tree indexes
> > +
> > +
>
> I don't think B-tree indexes are relevant here. AFAICT, this feature
> applies to all indexes.
On 2020-09-09 22:57, Jonathan S. Katz wrote:
+
+
+ Parallelized vacuuming of B-tree indexes
+
+
I don't think B-tree indexes are relevant here. AFAICT, this feature
applies to all indexes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
Justin Pryzby writes:
> Rebasing onto 3965de54e718600a4703233936e56a3202caf73f, I'm left with:
Sorry, I hadn't seen that you submitted more updates. I pushed
these with minor additional wordsmithing.
regards, tom lane
On Mon, Sep 07, 2020 at 08:40:26AM -0500, Justin Pryzby wrote:
Rebasing onto 3965de54e718600a4703233936e56a3202caf73f, I'm left with:
diff --git a/doc/src/sgml/release-13.sgml b/doc/src/sgml/release-13.sgml
index 8fffc6fe0a..69d143e10c 100644
--- a/doc/src/sgml/release-13.sgml
+++
"Jonathan S. Katz" writes:
> One thing that did not make it through was this:
> - 2020-XX-XX, CURRENT AS OF 2020-08-09
> + 2020-09-24, CURRENT AS OF 2020-09-09
Yeah, that's a placeholder to recall how far back to look for additional
changes to the relnotes, so unless you already read the git
On 9/10/20 1:14 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> Attached is a proposal for the "major enhancements" section. I borrowed
>> from the press release[1] but tried to stay true to the release notes
>> format and listed out the enhancements that way.
>
> Pushed with some very minor
"Jonathan S. Katz" writes:
> Attached is a proposal for the "major enhancements" section. I borrowed
> from the press release[1] but tried to stay true to the release notes
> format and listed out the enhancements that way.
Pushed with some very minor wording tweaks.
Hi,
On 5/4/20 11:16 PM, Bruce Momjian wrote:
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
>
> https://momjian.us/pgsql_docs/release-13.html
>
> It still needs markup, word wrap, and indenting. The community doc
> build should happen in a few
On Tue, May 12, 2020 at 10:28 AM Amit Langote wrote:
>
> On Tue, May 12, 2020 at 8:51 AM Bruce Momjian wrote:
> > On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > > I have attached a patch with my suggestions above.
> >
> > OK, I slightly modified the wording of your first
There's some obvious improvements for which I include a patch.
>Add alternate version of jsonb_setI() with special NULL handling (Andrew
>Dunstan)
>The new function, jsonb_set_lax(), allows null new values to either set the
>specified key to JSON null, delete the key, raise exception, or ignore
On Mon, Aug 3, 2020 at 11:35:50AM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan wrote:
> > On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> > > I came up with a more verbose documentation suggestion, attached.
> >
> > I'm okay with this.
>
> Are you
On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> > I came up with a more verbose documentation suggestion, attached.
>
> I'm okay with this.
Are you going to push this soon, Bruce?
--
Peter Geoghegan
On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> I came up with a more verbose documentation suggestion, attached.
I'm okay with this.
Thanks
--
Peter Geoghegan
On Wed, Jul 29, 2020 at 08:43:24PM -0700, David G. Johnston wrote:
> On Wednesday, July 29, 2020, Peter Geoghegan wrote:
>
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons.
On Wednesday, July 29, 2020, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons. More importantly, the "Allow hash aggregation
> > > to use disk storage for large
On Wed, Jul 29, 2020 at 7:48 PM Bruce Momjian wrote:
> Well, that seems to be repeating what is already in the docs for
> hash_mem_multiplier, which I try to avoid. One other direction is to
> put something in the incompatibilities section. Does that make sense?
I would prefer to put it next
On Wed, Jul 29, 2020 at 07:00:43PM -0700, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons. More importantly, the "Allow hash aggregation
> > > to use disk storage
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > There should be a note about this in the Postgres 13 release notes,
> > for the usual reasons. More importantly, the "Allow hash aggregation
> > to use disk storage for large aggregation result sets" feature should
> > reference the new GUC
On Wed, Jul 29, 2020 at 03:34:22PM -0700, Peter Geoghegan wrote:
> Hi Bruce,
>
> On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian wrote:
> > Patch attached and applied to PG 13.
>
> I committed the hash_mem_multiplier GUC to Postgres 13 just now.
>
> There should be a note about this in the
Hi Bruce,
On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian wrote:
> Patch attached and applied to PG 13.
I committed the hash_mem_multiplier GUC to Postgres 13 just now.
There should be a note about this in the Postgres 13 release notes,
for the usual reasons. More importantly, the "Allow hash
On Fri, Jun 26, 2020 at 04:23:26PM -0400, Alvaro Herrera wrote:
> Reading Luis Carril's other entry in the relnotes,
>
> Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis
> Carril)
>
> It seems to suggest that --include-foreign-data existed previously,
> which is not
Reading Luis Carril's other entry in the relnotes,
Allow pg_dump --include-foreign-data to dump data from foreign servers (Luis
Carril)
It seems to suggest that --include-foreign-data existed previously,
which is not true. I would have worded it as "Add --include-foreign-data
option to pg_dump
On 2020-Jun-26, Bruce Momjian wrote:
> On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote:
> > Author: Alvaro Herrera
> > 2020-03-20 [4e6209134] pg_dump: Add FOREIGN to ALTER statements, if
> > appropriate
> > -->
> >
> >
> >Add FOREIGN to ALTER
> > statements,
>
On Fri, Jun 26, 2020 at 05:24:16PM +0900, Masahiko Sawada wrote:
> Hi,
>
> I realized that PG 13 release note still has the following entry:
>
>
>
>
>Add FOREIGN to ALTER statements,
>if appropriate (Luis Carril)
>
>
>
>WHAT IS THIS ABOUT?
>
Hi,
I realized that PG 13 release note still has the following entry:
Add FOREIGN to ALTER statements,
if appropriate (Luis Carril)
WHAT IS THIS ABOUT?
IIUC this entry is about that pg_dump adds FOREIGN word to ALTER TABLE
command.
On Mon, May 25, 2020 at 10:54:03AM +0200, Daniel Gustafsson wrote:
> Spotted this in the release notes:
>
>
>Add extension bool_plperl which transforms
>SQL booleans to/from PL/Perl booleans (Ivan
>Panchenko) WHERE IS THIS DOCUMENTED?
>
>
> bool_plperl is
Spotted this in the release notes:
Add extension bool_plperl which transforms
SQL booleans to/from PL/Perl booleans (Ivan
Panchenko) WHERE IS THIS DOCUMENTED?
bool_plperl is documented in "44.1. PL/Perl Functions and Arguments", but not
with a separate section
Thanks, applied.
---
On Mon, May 18, 2020 at 11:18:51AM +0200, Daniel Gustafsson wrote:
> > On 5 May 2020, at 05:16, Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> >
> On 5 May 2020, at 05:16, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 13 release notes. You can
> see them here:
Spotted a typo we probably should fix: s/PostgresSQL/PostgreSQL/ =)
cheers ./daniel
13relnotes_postgressql.diff
Description: Binary data
On Fri, May 15, 2020 at 09:54:55PM +0900, Fujii Masao wrote:
> > Actually, it should be:
> >
> >
> >
> > because we are using the text from the link.
>
> Yes, this works.
>
> > See
> > doc/src/sgml/README.links for details on xref links. Release notes
> > updated.
>
> Thanks!
>
> >
On 2020/05/15 21:29, Bruce Momjian wrote:
On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
https://momjian.us/pgsql_docs/release-13.html
It
On Fri, May 15, 2020 at 03:55:19PM +0900, Fujii Masao wrote:
>
>
> On 2020/05/05 12:16, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs markup,
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Many
On Thu, May 14, 2020 at 11:01:51PM +0200, Peter Eisentraut wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of
On Thu, May 14, 2020 at 2:02 PM Peter Eisentraut
wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of
On 2020-05-12 02:41, Justin Pryzby wrote:
I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include
On Thu, May 14, 2020 at 07:23:05AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > > > > * 34a0a81bfb
> > > >
> > > > We already have:
> > > >
> > > > Reformat tables containing function information for better
> > > > clarity (Tom Lane)
> > > >
> > > > so it seems it is
At Wed, 13 May 2020 22:40:52 -0400, Bruce Momjian wrote in
> On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian wrote
> > in
> > > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > It is just an more
Hello Bruce,
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)
so it seems it is covered as part of this.
AFAICR this one is not by the same author, and although the point was about
better clarity, it was not
On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian wrote in
> > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> It is just an more accurate (not an detailed) version of the
> previously proposed description.
At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian wrote in
> On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > >
> > > Allow skipping of WAL for new tables and indexes if wal_level is
> > > 'minimal' (Kyotaro Horiguchi)
> > >
> > > Relations larger than
On Wed, May 13, 2020 at 07:18:38AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > > * e1ff780485
> >
> > I was told in this email thread to not include that one.
>
> Ok.
>
> > > * 34a0a81bfb
> >
> > We already have:
> >
> > Reformat tables containing function information for
On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> >
> > Allow skipping of WAL for new tables and indexes if wal_level is
> > 'minimal' (Kyotaro Horiguchi)
> >
> > Relations larger than wal_skip_threshold will have their files
> > fsync'ed rather than writing
Hello Bruce,
* e1ff780485
I was told in this email thread to not include that one.
Ok.
* 34a0a81bfb
We already have:
Reformat tables containing function information for better
clarity (Tom Lane)
so it seems it is covered as part of this.
AFAICR this one is not by
At Tue, 12 May 2020 16:38:09 -0400, Bruce Momjian wrote in
> On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > > commit c6b9204
> > > > Author: Noah Misch
> > > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > > Commit: Noah Misch
> > > > CommitDate: Sat Apr 4
On Tue, May 12, 2020 at 01:47:38PM -0400, Alvaro Herrera wrote:
> On 2020-May-07, Bruce Momjian wrote:
>
> > OK, I have moved her name to be first. FYI, this commit was backpatched
> > back through PG 11, though the commit message doesn't mention that.
>
> At some point I became an avid user of
On Tue, May 12, 2020 at 09:43:10AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > OK, section and item added, patch attached,
>
> Thanks!
>
> Some items that might be considered for the added documentation section:
>
> * e1ff780485
I was told in this email thread to not include that
On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > commit c6b9204
> > > Author: Noah Misch
> > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > Commit: Noah Misch
> > > CommitDate: Sat Apr 4 12:25:34 2020 -0700
> > >
> > > Skip WAL for new relfilenodes, under
On Mon, May 11, 2020 at 11:38:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> >> 'specify' ?
>
> > I like that word if Tom prefers it.
>
> 'specify' works for me.
Sure, done.
--
Bruce Momjian
On 2020-May-07, Bruce Momjian wrote:
> OK, I have moved her name to be first. FYI, this commit was backpatched
> back through PG 11, though the commit message doesn't mention that.
At some point I became an avid user of our src/tools/git_changelog, and
then it stopped making sense for me to
Hello Bruce,
OK, section and item added, patch attached,
Thanks!
Some items that might be considered for the added documentation section:
* e1ff780485
* 34a0a81bfb
* e829337d42
* "Document color support (Peter Eisentraut)"
THIS WAS NOT DOCUMENTED BEFORE?
Not as such, AFAICR it
At Mon, 11 May 2020 20:12:04 -0400, Bruce Momjian wrote in
> On Thu, May 7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> > On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > > - Crash recovery was losing tuples written via COPY TO. This fixes
> > > > > > the bug.
> > >
Bruce Momjian writes:
> On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
>> 'specify' ?
> I like that word if Tom prefers it.
'specify' works for me.
regards, tom lane
On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> On 05/11/20 22:48, Bruce Momjian wrote:
> > On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
> >>> character available
On 05/11/20 22:48, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
>>> character available in the database encoding, even when the database
>>> encoding is
On Tue, May 12, 2020 at 6:11 AM Justin Pryzby wrote:
>
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > 1. We have allowed an (auto)vacuum to display additional information
> > > about heap or index in case of an error in commit b61d161c14 [1].
> > > Now, in general, it might
On 2020/05/12 9:34, Bruce Momjian wrote:
Could you add "Vinayak Pokale" as a co-author of the following feature since
I sometimes read his old patch to create a patch [1] ?
===
E.1.3.1.6. System Views
- Add system view pg_stat_progress_analyze to report analyze progress
On Mon, May 11, 2020 at 10:23:53PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, are you suggesting a new section because the glossary shouldn't be
> > listed under source code, or because you want the function reformatting
> > added? We just need to understand what the purpose is.
On Tue, May 12, 2020 at 6:36 AM Bruce Momjian wrote:
>
> On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
> > On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > One more observation:
> > >
> > > Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> >
On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I like your wording, but the "that encoding" wasn't clear enough for me,
> > so I reworded it to:
>
> > Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
> > character available in the
On Tue, May 12, 2020 at 10:54:52AM +0900, Michael Paquier wrote:
> On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
> > On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
> >> Should e2e02191 be added to the notes? This commit means that we
> >> actually dropped
Bruce Momjian writes:
> Well, are you suggesting a new section because the glossary shouldn't be
> listed under source code, or because you want the function reformatting
> added? We just need to understand what the purpose is. We already have
> the glossary listed, since that is new and
On 2020-May-11, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
> > Yes, we had to touch the source code in order to add documentation; but
> > so what? Everything touches the source code, but that doesn't mean it
> > should be listed there. I don't see
Bruce Momjian writes:
> I like your wording, but the "that encoding" wasn't clear enough for me,
> so I reworded it to:
> Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
> character available in the database encoding, even when the database
> encoding is not
On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
> On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
>> Should e2e02191 be added to the notes? This commit means that we
>> actually dropped support for Windows 2000 (finally) at run-time.
>
> Oh, yes. This is much
On Mon, May 11, 2020 at 6:23 PM Bruce Momjian wrote:
> OK, I was able to add some of it cleanly:
>
> This allows efficient btree indexing of low cardinality columns by
> storing duplicate keys only once. Users upgrading with pg_upgrade
> will need to use REINDEX to make
On Tue, May 12, 2020 at 8:51 AM Bruce Momjian wrote:
> On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > I have attached a patch with my suggestions above.
>
> OK, I slightly modified the wording of your first change, patch
> attached.
Thanks. I checked that what you committed
On Mon, May 11, 2020 at 09:15:43PM -0400, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> > On Mon, May 11, 2020 at 5:14 PM Bruce Momjian wrote:
> > > Agreed. How is this?
> > >
> > > This allows efficient btree indexing of low cardinality
On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2020 at 5:14 PM Bruce Momjian wrote:
> > Agreed. How is this?
> >
> > This allows efficient btree indexing of low cardinality columns.
> > Users upgrading with pg_upgrade will need to use REINDEX
On Mon, May 11, 2020 at 07:41:01PM -0500, Justin Pryzby wrote:
> |Allow function call backtraces of errors to be logged (Peter Eisentraut,
> Álvaro Herrera)
> |Server variable backtrace_functions specifies which C functions should
> generate backtraces on error.
>
> I think the details in the
On Mon, May 11, 2020 at 05:09:54PM -0400, Alvaro Herrera wrote:
> On 2020-May-11, Alvaro Herrera wrote:
>
> > Hello
> >
> > > +
> > > +
> > > +
> > > +Add psql commands to report operator classes and operator families
> > > (Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov)
> > > +
> >
>
On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > One more observation:
> >
> > Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> > Praliaskouski)
> > This new behavior allows pages to be set as
On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
> On 2020-May-11, Bruce Momjian wrote:
>
> > We have long discussed how much of the release notes is to reward
> > behavior, and we have settled on having the names on the items, and the
> > Acknowledgments section at the bottom.
>
On Mon, May 11, 2020 at 04:50:50PM -0400, Alvaro Herrera wrote:
> Hello
>
> > +
> > +
> > +
> > +Add psql commands to report operator classes and operator families (Sergey
> > Cherkashin, Nikita Glukhov, Alexander Korotkov)
> > +
>
> I think this item should list the commands in question:
>
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > 1. We have allowed an (auto)vacuum to display additional information
> > about heap or index in case of an error in commit b61d161c14 [1].
> > Now, in general, it might not be worth saying much about error
> > information but I
|Allow function call backtraces of errors to be logged (Peter Eisentraut,
Álvaro Herrera)
|Server variable backtrace_functions specifies which C functions should
generate backtraces on error.
I think the details in the description are eclipsing the most important thing:
backtraces on Assert().
On 2020-May-11, Bruce Momjian wrote:
> We have long discussed how much of the release notes is to reward
> behavior, and we have settled on having the names on the items, and the
> Acknowledgments section at the bottom.
Yes, we had to touch the source code in order to add documentation; but
so
On Mon, May 11, 2020 at 03:19:50PM +0900, Tatsuro Yamada wrote:
> Hi Bruce,
>
> On 2020/05/05 12:16, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs
On Mon, May 11, 2020 at 5:14 PM Bruce Momjian wrote:
> Agreed. How is this?
>
> This allows efficient btree indexing of low cardinality columns.
> Users upgrading with pg_upgrade will need to use REINDEX to make use
> of
> this feature.
I still think that the release
On Sun, May 10, 2020 at 03:09:47PM -0500, Justin Pryzby wrote:
> > In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}",
> > properly interpret that as "*{5}" (Nikita Glukhov)
>
> I think that should say ".*" not "*", as in:
>
> > In ltree, when using adjacent asterisks with
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> One more observation:
>
> Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> Praliaskouski)
> This new behavior allows pages to be set as all-visible, which then
> allows index-only scans, ...
>
> The above
On Sat, May 9, 2020 at 11:16:27AM +0530, Amit Kapila wrote:
> On Tue, May 5, 2020 at 8:46 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
>
> Thanks for the
On Fri, May 8, 2020 at 09:14:01AM +0200, Fabien COELHO wrote:
> > It seems (a) pointless
>
> I disagree, on the very principle of free software values as a social
> movement.
>
> Documentation improvements should be encouraged, and recognizing these in
> the release notes contributes to do that
On Mon, May 11, 2020 at 05:05:29PM -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2020 at 4:10 PM Bruce Momjian wrote:
> > > think that you should point out that deduplication works by storing
> > > the duplicates in the obvious way: Only storing the key once per
> > > distinct value (or once
On Thu, May 7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > - Crash recovery was losing tuples written via COPY TO. This fixes
> > > > > the bug.
> > > >
> > > > This was not backpatched?
> > >
> > > Right.
> >
> > Oh.
On Mon, May 11, 2020 at 4:10 PM Bruce Momjian wrote:
> > think that you should point out that deduplication works by storing
> > the duplicates in the obvious way: Only storing the key once per
> > distinct value (or once per distinct combination of values in the case
> > of multi-column
1 - 100 of 197 matches
Mail list logo
