Hi,
On Thu, Jun 6, 2019 at 1:44 PM David Rowley
wrote:
>
> On Fri, 24 May 2019 at 22:00, David Rowley
> wrote:
> > I've attached the pg10 and pg11 patches with that updated... and also
> > the master one (unchanged) with the hopes that the CF bot picks that
> > one.
>
> I got talking to Andres
I suggest just minor variations on language.
On Thu, Jun 06, 2019 at 04:43:48PM +1200, David Rowley wrote:
>diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
>index cce1618fc1..ab26630199 100644
>--- a/doc/src/sgml/ddl.sgml
>+++ b/doc/src/sgml/ddl.sgml
>@@ -4674,6 +4675,76 @@ EXPLAIN
On Fri, 24 May 2019 at 22:00, David Rowley wrote:
> I've attached the pg10 and pg11 patches with that updated... and also
> the master one (unchanged) with the hopes that the CF bot picks that
> one.
I got talking to Andres about this at PGCon after a use case of 250k
partitions was brought to
On Thu, Jun 6, 2019 at 7:37 AM Wu, Fei wrote:
>
> Sorry, Last mail forget to CC the mailing list.
>
> Now the comment is confusing, Maybe someone should correct it.
>
Sure, for the sake of clarity, when this code was initially introduced
in commit d1b7c1ff, the structure used was
Sorry, Last mail forget to CC the mailing list.
Now the comment is confusing, Maybe someone should correct it.
Here is a simple patch, What do you think ?
With Regards,
Wu Fei
-Original Message-
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
Sent: Wednesday, June 05, 2019 7:18 PM
On Thu, Jun 6, 2019 at 1:46 AM vignesh C wrote:
>
> Hi,
>
> *I noticed pg_basebackup failure when default_table_access_method option
> is set.*
>
> *Test steps:*
>
> Step 1: Init database
> ./initdb -D data
>
> Step 2: Start Server
> ./postgres -D data &
>
> Step 3: Set Guc option
> export
On Thu, May 23, 2019 at 7:48 PM David Rowley
wrote:
> > cost_sort() costs sorts as top-N heapsorts. While we cannot make an
> > iron-clad guarantee that it will work out that way from within
> > tuplesort.c, that doesn't seem like it closes off the possibility of
> > more informative EXPLAIN
On Wed, 5 Jun 2019 at 08:10, Alvaro Herrera wrote:
>
> On 2019-May-24, David Rowley wrote:
>
> > It appears there is no mention of lack of support for CREATE INDEX
> > CONCURRENTLY on partitioned index in the documents.
>
> I'll leave this one for you to handle, thanks.
Thanks. I've just pushed
Hi,
On Wed, 5 Jun 2019 at 18:50, Andres Freund wrote:
> Hi,
>
> On 2019-06-05 18:47:57 -0400, Dave Cramer wrote:
> > So one of the things they would like added is to get not null information
> > in the schema record. This is so they can mark the field Optional in
> Java.
> > I presume this
Hi,
On 2019-06-05 18:47:57 -0400, Dave Cramer wrote:
> So one of the things they would like added is to get not null information
> in the schema record. This is so they can mark the field Optional in Java.
> I presume this would also have some uses in other languages. As I
> understand it this
On Thu, May 16, 2019 at 8:46 PM Melanie Plageman
wrote:
>
> Good idea.
> I squashed the changes I suggested in previous emails, Ashwin's patch, my
> suggested updates to that patch, and the index order check all into one
> updated
> patch attached.
>
>
I've updated this patch to make it apply on
Hi,
On Wed, 5 Jun 2019 at 12:01, Andres Freund wrote:
> Hi
>
> On June 5, 2019 8:51:10 AM PDT, Dave Cramer wrote:
> >On Wed, 5 Jun 2019 at 07:21, Dave Cramer wrote:
> >
> >> Hi,
> >>
> >>
> >> On Wed, 5 Jun 2019 at 07:18, Petr Jelinek
> >
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> On 05/06/2019
On 2019-May-28, Andrew Gierth wrote:
> The main cases I know of are:
>
> 1. RANGE UNBOUNDED PRECEDING - this one is actually a defect in the
> standard SQL grammar, since UNBOUNDED is a non-reserved keyword and so
> it can also appear as a legal , and the construct
> RANGE PRECEDING allows to
On Wed, Jun 5, 2019 at 2:11 PM Alvaro Herrera wrote:
> REINDEX CONCURRENTLY would be one good area to focus on, I think, as
> well as ALTER TABLE ATTACH PARTITION. Maybe also INCLUDE columns in
> GiST, and the stuff in commits 9155580fd, fe280694d and 7df159a62.
Those all seem like good things
On 2019-May-23, Jeff Janes wrote:
> Now that beta is out, I wanted to do some crash-recovery testing where I
> inject PANIC-inducing faults and see if it recovers correctly. A long-lived
> Perl process keeps track of what it should find after the crash, and
> verifies that it finds it. You will
On 2019-May-26, David Rowley wrote:
> On Sun, 26 May 2019 at 04:50, Tom Lane wrote:
> > Here the cost is code space rather than programmer-visible complexity,
> > but I still doubt that it's worth it.
>
> I see on today's master the postgres binary did grow from 8633960
> bytes to 8642504 on
On 2019-05-28 04:56, Michael Paquier wrote:
> You could also use a long option for that without a one-letter option,
> like --file-path or such, so reserving a one-letter option for a
> future, hypothetical use is not really a stopper in my opinion. In
> consequence, I think that that it is fine
On Wed, Jun 5, 2019 at 5:17 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> I propose this patch to add a LOCALE option to CREATE DATABASE. This
> sets both LC_COLLATE and LC_CTYPE with one option. Similar behavior is
> already supported in initdb, CREATE COLLATION, and
I propose this patch to add a LOCALE option to CREATE DATABASE. This
sets both LC_COLLATE and LC_CTYPE with one option. Similar behavior is
already supported in initdb, CREATE COLLATION, and createdb.
With collation providers other than libc, having separate lc_collate and
lc_ctype settings is
> To address this, probably we can do something like in the attached patch.
> Altogether with distinct_pathkeys uniq_distinct_pathkeys are stored, which is
> the same, but without the constants elimination. It's being used then for
> getting the real number of distinct keys, and to check the order
On Mon, Jun 3, 2019 at 3:22 PM Peter Eisentraut
wrote:
> After many years of trying, it seems the -fsanitize=undefined checking
> in gcc is now working somewhat reliably. Attached is a patch that fixes
> all errors of the kind
Is this as of some particular gcc version?
--
Robert Haas
Thanks for taking a look at this Tom.
On Mon, Jun 3, 2019 at 4:07 PM Tom Lane wrote:
> Mat Arye writes:
> > On Fri, May 24, 2019 at 5:05 PM Mat Arye wrote:
> >> 11.3 included some change to partition table planning. Namely
> >> commit 925f46f ("Fix handling of targetlist SRFs when scan/join
>
Hi,
On June 5, 2019 12:14:42 PM PDT, Alvaro Herrera
wrote:
>On 2019-Jun-05, Andres Freund wrote:
>
>> I'd much rather see this tackled in a general way than fiddling with
>> individual datatypes. I think we should:
>>
>> 1) make fetch_att(), store_att_byval() etc support datums of any
>length
On 2019-Jun-05, Andres Freund wrote:
> I'd much rather see this tackled in a general way than fiddling with
> individual datatypes. I think we should:
>
> 1) make fetch_att(), store_att_byval() etc support datums of any length
>between 1 and <= sizeof(Datum). Probably also convert them to
Hi,
On 2019-06-05 09:18:34 -0700, Melanie Plageman wrote:
> On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan wrote:
>
> > On Tue, Jun 4, 2019 at 3:23 PM Andres Freund wrote:
> > > > This is half the reason why I ended up implementing itemptr_encode()
> > > > to accelerate the TID sort used by
On 2019-Jun-05, Melanie Plageman wrote:
> I can take on making macaddr8 pass-by-value
> I tinkered a bit last night and got in/out mostly working (I think).
> I'm not sure about macaddr, TID, and user-defined types.
Yeah, let's see what macaddr8 looks like, and we can move from there --
I
On Tue, Jun 4, 2019 at 3:50 PM Peter Geoghegan wrote:
> On Tue, Jun 4, 2019 at 3:23 PM Andres Freund wrote:
> > > This is half the reason why I ended up implementing itemptr_encode()
> > > to accelerate the TID sort used by CREATE INDEX CONCURRENTLY some
> > > years back -- TID is 6 bytes wide,
On Mon, 3 Jun 2019 at 15:39, James Coleman wrote:
>
> On Sun, Jun 2, 2019 at 5:18 PM Tomas Vondra
> wrote:
> > Currently, the costing logic (cost_incremental_sort) assumes all groups
> > have the same size, which is fine for uniform distributions. But for
> > skewed distributions, that may be an
Hoi hackers,
Please find attached updated versions of the patches, I've now tested
them. Also attached is a reproduction script to verify that they
actually work.
To test you need to create 150 databases as described in the script,
then simply execute it. Before patching you get the following
Hi
On June 5, 2019 8:51:10 AM PDT, Dave Cramer wrote:
>On Wed, 5 Jun 2019 at 07:21, Dave Cramer wrote:
>
>> Hi,
>>
>>
>> On Wed, 5 Jun 2019 at 07:18, Petr Jelinek
>
>> wrote:
>>
>>> Hi,
>>>
>>> On 05/06/2019 00:08, Andres Freund wrote:
>>> > Hi,
>>> >
>>> > On 2019-06-05 00:05:02 +0200, David
On 2019-Jun-03, Andres Freund wrote:
> On 2019-06-03 11:45:51 -0400, Elvis Pranskevichus wrote:
> > It is understandably late in the 12 cycle, so maybe prohibit NOT
> > MATERIALIZED with DML altogheter and revisit this in 13?
>
> I could see us adding an error, or just continuing to silently
On Wed, 5 Jun 2019 at 07:21, Dave Cramer wrote:
> Hi,
>
>
> On Wed, 5 Jun 2019 at 07:18, Petr Jelinek
> wrote:
>
>> Hi,
>>
>> On 05/06/2019 00:08, Andres Freund wrote:
>> > Hi,
>> >
>> > On 2019-06-05 00:05:02 +0200, David Fetter wrote:
>> >> Would it make sense to work toward a binary format
Hi,
*I noticed pg_basebackup failure when default_table_access_method option is
set.*
*Test steps:*
Step 1: Init database
./initdb -D data
Step 2: Start Server
./postgres -D data &
Step 3: Set Guc option
export PGOPTIONS='-c default_table_access_method=zheap'
Step 4: Peform backup
Robert Haas wrote:
> On Fri, May 31, 2019 at 2:59 AM Antonin Houska wrote:
> > > Sounds good. I'm not quite sure how this is going to work. Ideally
> > > you'd like the encryption key command to fetch the key from something
> > > like ssh-agent, or maybe pop up a window on the user's terminal
Hi,
On Wed, 5 Jun 2019 at 07:18, Petr Jelinek
wrote:
> Hi,
>
> On 05/06/2019 00:08, Andres Freund wrote:
> > Hi,
> >
> > On 2019-06-05 00:05:02 +0200, David Fetter wrote:
> >> Would it make sense to work toward a binary format that's not
> >> architecture-specific? I recall from COPY that our
Hi,
On 05/06/2019 00:08, Andres Freund wrote:
> Hi,
>
> On 2019-06-05 00:05:02 +0200, David Fetter wrote:
>> Would it make sense to work toward a binary format that's not
>> architecture-specific? I recall from COPY that our binary format is
>> not standardized across, for example, big- and
On Wed, Jun 5, 2019 at 11:27 AM Wu, Fei wrote:
>
> Thanks for your reply.
> From the code below:
> (https://github.com/postgres/postgres/blob/REL_10_7/src/backend/executor/execParallel.c)
> ###
> 443 /*
> 444
On Tue, Jun 4, 2019 at 9:25 PM Robert Haas wrote:
> On Fri, May 17, 2019 at 4:36 PM Tom Lane wrote:
> > Yeah, I did some additional testing that showed that it's pretty darn
> > hard to get the leak to amount to anything. The test case that I
> > originally posted did many DDLs in a single
On Wed, 5 Jun 2019 at 18:11, Michael Paquier wrote:
>
> On Tue, Jun 04, 2019 at 11:26:44AM -0700, Ashwin Agrawal wrote:
> > The variable is used in else scope hence I moved it there. But yes its
> > removed completely for this scope.
>
> Thanks for updating the patch. It does its job by having
Re: Tom Lane 2019-06-04 <65800.1559662...@sss.pgh.pa.us>
> > There is something wrong here. On Debian Buster/unstable, using
> > system tzdata (2019a-1), if /etc/timezone is "Etc/UTC":
>
> Is your build using --with-system-tzdata? If so, which tzdb
> release is the system on, and is it a
Tom, thanks for operational response reaction.
Based on this topic and some nearby ones
the problem turned out to be deeper than
expceted... as always.
p.s. Sorry for cyrillic in the mailing list.
At the beginning I wrote from corporate email
and could not change the sender name.
If you can,
On Wed, May 29, 2019 at 10:30 AM Haribabu Kommi
wrote:
>
> Updated patches are attached.
>
>
All patches apply, build and pass tests. The patch
'0001-support-building-with-visual-studio-2019_v10_to_v9.6_v3.patch'
applies on version 9.5.
Not sure if more review is needed before moving to 'ready
Hi,
Is anyone able to reproduce this one ?
Any pointer to solve this would be helpful.
regards,
On 05/27/2019 07:27 PM, tushar wrote:
Hi,
I am getting this below error - after performing pg_rewind when i try
to start new slave ( which earlier was my master) against PGv12 Beta1.
"
cp:
On Tue, Jun 04, 2019 at 11:26:44AM -0700, Ashwin Agrawal wrote:
> The variable is used in else scope hence I moved it there. But yes its
> removed completely for this scope.
Thanks for updating the patch. It does its job by having one separate
message for the concurrent and the non-concurrent
On Tue, Jun 04, 2019 at 04:18:30PM -0400, Alvaro Herrera wrote:
> Yeah, I was not quite understanding why it was being blamed on a commit
> that actually *removed* one other callsite that did the same thing. (I
> didn't actually realize at the time that this bug was there, mind.)
I completely
45 matches
Mail list logo
