I suggest to rename enable_incrementalsort to enable_incremental_sort.
This is obviously more readable and also how we have named recently
added multiword planner parameters.
See attached patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
Ranier Vilela writes:
> The res->curBlock pointer possibly, can be NULL here (line 563).
No, it can't.
To get to that line, nBytes has to be > 0, which means res->spaceLeft
has to be > 0, which cannot happen while res->curBlock is NULL.
regards, tom lane
On Sun, Jun 21, 2020 at 2:28 AM Justin Pryzby wrote:
> And a couple more in spgist.sgml (some of which were not added by this patch).
Pushed, thanks!
--
Regards,
Alexander Korotkov
Tomas Vondra writes:
> I'm not particularly familiar with AlternativeSubPlans, but I see we're
> picking the one in nodeSubplan.c based on plan_rows. Can't we do the
> same thing in cost_qual_eval_walker?
Nope. The entire reason why we have that kluge is that we don't know
until much later how m
On Sat, Jun 20, 2020 at 6:46 PM Michael Paquier wrote:
> On Sat, Jun 20, 2020 at 03:01:36PM +1200, Thomas Munro wrote:
> > Thanks for the clue. Appveyor runs your build script as a privileged
> > user (unlike, I assume, the build farm animals), and that has caused a
> > problem with this test in
On Wed, Jun 17, 2020 at 06:21:58PM -0700, Melanie Plageman wrote:
On Fri, Jun 5, 2020 at 9:08 AM Alexey Bashtanov wrote:
In [1] we found a situation where it leads to a suboptimal plan,
as it bloats the overall cost into large figures,
a decision related to an outer part of the plan look negl
And a couple more in spgist.sgml (some of which were not added by this patch).
>From ed7bd93c6a6953d8626331de9bcba126ddb79b54 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 20 Jun 2020 16:37:51 -0500
Subject: [PATCH v2] Language fixen for
15cb2bd27009f73a84a35c2ba60fdd105b4bf263
---
do
On Sat, Jun 20, 2020 at 01:55:33PM +0300, Alexander Korotkov wrote:
> On Thu, Jun 18, 2020 at 8:06 PM Alexander Korotkov
> wrote:
> > On Wed, Jun 17, 2020 at 2:00 PM Alexander Korotkov
> > wrote:
> > > On Wed, Jun 17, 2020 at 2:50 AM Peter Geoghegan wrote:
> > > > On Tue, Jun 16, 2020 at 4:24
Minor language tweak:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 7050ce6e2e..08142d64cb 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3800,8 +3800,8 @@ restore_command = 'copy "C:\\server\\archivedir\\%f"
"%p"' # Windows
slots are al
On Thu, Jun 11, 2020 at 01:22:57PM -0700, Jeff Davis wrote:
> > think the names you suggested quite fit, but the idea to use a more
> > interesting GUC value might help express the behavior. Perhaps making
> > enable_hashagg a ternary "enable_hashagg=on|off|avoid_disk"? The word
> > "reject" is too
On Thu, Jun 18, 2020 at 12:21:17PM +0530, Amit Kapila wrote:
On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada
wrote:
On Wed, 17 Jun 2020 at 20:14, Amit Kapila wrote:
>
>
> I had written above in the context of persisting these stats. I mean
> to say if the process has bounced or server has re
Hi,
Sorry for neglecting this thread for the last couple days ...
In general, I agree it's somewhat unfortunate the stats are reset when
the walsender exits. This was mostly fine for tuning of the spilling
(change value -> restart -> see stats) but for proper monitoring this
is somewhat problema
On Sat, Jun 20, 2020 at 10:15 PM Peter Geoghegan wrote:
> On Sat, Jun 20, 2020 at 3:55 AM Alexander Korotkov
> wrote:
> > So, pushed!
>
> Noticed one small thing. You forgot to update this part from the B-Tree docs:
>
> "As shown in Table 37.9, btree defines one required and three optional
> sup
On Sat, Jun 20, 2020 at 3:55 AM Alexander Korotkov wrote:
> So, pushed!
Noticed one small thing. You forgot to update this part from the B-Tree docs:
"As shown in Table 37.9, btree defines one required and three optional
support functions. The four user-defined methods are:"
Thanks
--
Peter Ge
On Sat, Jun 20, 2020 at 04:30:10PM +0200, Dmitry Dolgov wrote:
On Sat, May 16, 2020 at 04:56:09PM +0200, Tomas Vondra wrote:
So I don't think there will be a single "interesting" grouping pathkeys
(i.e. root->group_pathkeys), but a collection of pathkeys. And we'll
need to build grouping paths f
On Sat, Jun 20, 2020 at 6:08 PM Stefan Kaltenbrunner
wrote:
> On 6/20/20 4:46 PM, Alexander Korotkov wrote:
> > On Sat, Jun 20, 2020 at 3:32 PM Erik Rijkers wrote:
> >> The mails that I get today from pgsql-committers contain links (as
> >> usual) to git.postgresql.org
> >> but these links don't
On 2020-06-20 17:08, Stefan Kaltenbrunner wrote:
the root issue should be fixed as of a few minutes ago but it might
take
a bit until everything is synced up again.
Thanks!
On 6/20/20 4:46 PM, Alexander Korotkov wrote:
> On Sat, Jun 20, 2020 at 3:32 PM Erik Rijkers wrote:
>> The mails that I get today from pgsql-committers contain links (as
>> usual) to git.postgresql.org
>> but these links don't seem to give valid pages: I get what looks like a
>> gitweb page but w
On Thu, Jun 18, 2020 at 8:06 PM Alexander Korotkov
wrote:
> On Wed, Jun 17, 2020 at 2:00 PM Alexander Korotkov
> wrote:
> > On Wed, Jun 17, 2020 at 2:50 AM Peter Geoghegan wrote:
> > > On Tue, Jun 16, 2020 at 4:24 AM Alexander Korotkov
> > > wrote:
> > > > Thank you for patience. The documenta
On Sat, Jun 20, 2020 at 6:02 PM Erik Rijkers wrote:
>
>
> I don't know exactly where things are going wrong - could even be local
> here but I don't think so.. do others see the same thing?
>
Yes, I am also facing the same problem.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterpri
> On Sat, May 16, 2020 at 04:56:09PM +0200, Tomas Vondra wrote:
>
> So I don't think there will be a single "interesting" grouping pathkeys
> (i.e. root->group_pathkeys), but a collection of pathkeys. And we'll
> need to build grouping paths for all of those, and leave the planner to
> eventually p
Hi Mark,
please, can you take a look?
This possible bug was appeared before, see at:
1. https://bugzilla.redhat.com/show_bug.cgi?id=879803
The trap still persist, in HEAD see:
src/interfaces/libpq/fe-exec.c (line 563)
/* If there's enough space in the current block, no problem. */
if (nBytes <=
On Sat, Jun 20, 2020 at 3:32 PM Erik Rijkers wrote:
> The mails that I get today from pgsql-committers contain links (as
> usual) to git.postgresql.org
> but these links don't seem to give valid pages: I get what looks like a
> gitweb page but with '404 - Unknown commit object '
>
> example:
> ht
On Sat, Jun 20, 2020 at 1:16 PM Alexander Korotkov
wrote:
> On Fri, Jun 19, 2020 at 10:34 PM Alvaro Herrera
> wrote:
> >
> > On 2020-Jun-15, Michael Paquier wrote:
> >
> > > I have begun my annual study of WAL consistency across replays, and
> > > wal_consistency_checking = 'all' is pointing out
On Tue, Jun 16, 2020 at 6:13 PM Georgios wrote:
> > Few comments:
> >
> > - if (pset.sversion >= 12)
> >
> > - appendPQExpBufferStr(&buf,
> >
> > - "\n LEFT JOIN pg_catalog.pg_am am ON am.oid = c.relam");
> >
> > Should we include pset.hide_tableam check along with the version check?
Hello,
The mails that I get today from pgsql-committers contain links (as
usual) to git.postgresql.org
but these links don't seem to give valid pages: I get what looks like a
gitweb page but with '404 - Unknown commit object '
example:
https://git.postgresql.org/pg/commitdiff/15cb2bd27009f7
On Sat, Jun 20, 2020 at 5:51 PM Amit Kapila wrote:
>
>
> So, is anyone working on improving these parts of the patch. AFAICS
> from what Bruce has shared [1],
>
oops, forgot to share the link [1] -
https://wiki.postgresql.org/wiki/WIP_PostgreSQL_Sharding
--
With Regards,
Amit Kapila.
Enterpris
On Fri, Jun 19, 2020 at 1:42 PM Andrey V. Lepikhov
wrote:
>
> On 6/19/20 11:48 AM, Amit Kapila wrote:
> > On Wed, Jun 10, 2020 at 8:36 AM Andrey V. Lepikhov
> > wrote:
> >> On 09.06.2020 11:41, Fujii Masao wrote:
> >>> The patches seem not to be registered in CommitFest yet.
> >>> Are you plannin
On Fri, Jun 19, 2020 at 6:33 PM Bruce Momjian wrote:
>
> On Fri, Jun 19, 2020 at 05:03:20PM +0800, movead...@highgo.ca wrote:
> >
> > >> would like to know if the patch related to CSN based snapshot [2] is a
> > >> precursor for this, if not, then is it any way related to this patch
> > >> because
On Fri, Jun 19, 2020 at 10:34 PM Alvaro Herrera
wrote:
>
> On 2020-Jun-15, Michael Paquier wrote:
>
> > I have begun my annual study of WAL consistency across replays, and
> > wal_consistency_checking = 'all' is pointing out at some issues with
> > at least VACUUM and SPGist:
> > FATAL: inconsist
Hello Peter,
whereas the current standard says
SUBSTRING(text SIMILAR pattern ESCAPE escapechar)
The former was in SQL99, but the latter has been there since SQL:2003.
It's pretty easy to implement the second form also, so here is a patch that
does that.
Patches apply cleanly, compile
31 matches
Mail list logo
