Re: [HACKERS] taking stdbool.h into use

On Thu, Oct 26, 2017 at 5:41 PM, Tom Lane wrote: > While warnings for this would be lovely, I don't see how we can expect to > get any. This is perfectly correct C code no matter whether isprimary > is C99 bool or is typedef'd to char ... you just end up with different >

Re: [HACKERS] [bug fix] postgres.exe crashes with access violation on Windows while starting up

On Thu, Oct 26, 2017 at 7:10 PM, Tsunakawa, Takayuki wrote: > FIX > == > > Add the check "CurrentMemoryContext != NULL" in write_eventlog() as in > write_console(). * Also verify that we are not on our way into error recursion

Re: [HACKERS] CUBE seems a bit confused about ORDER BY

On Fri, Oct 20, 2017 at 1:01 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Fri, Oct 20, 2017 at 12:52 AM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> I've noticed this suspicious behavior of "cube" data type with ORDER BY, >> which I believe is a bug in the

Re: [HACKERS] Implementing pg_receivewal --no-sync

On Fri, Oct 27, 2017 at 12:03 AM, Michael Paquier wrote: > On Thu, Oct 26, 2017 at 10:46 PM, Robert Haas wrote: >> On Wed, Oct 25, 2017 at 10:03 PM, Michael Paquier >> wrote: >>> This sentence is actually wrong, a

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-10-28 23:35 GMT+02:00 Alexander Korotkov : > On Sat, Oct 28, 2017 at 3:46 PM, Pavel Stehule > wrote: > >> 2017-09-22 21:31 GMT+02:00 Pavel Stehule : >> >>> >>> >>> 2017-09-22 21:12 GMT+02:00 Peter Eisentraut < >>>

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On Sat, Oct 28, 2017 at 3:46 PM, Pavel Stehule wrote: > 2017-09-22 21:31 GMT+02:00 Pavel Stehule : > >> >> >> 2017-09-22 21:12 GMT+02:00 Peter Eisentraut < >> peter.eisentr...@2ndquadrant.com>: >> >>> On 9/22/17 09:16, Pavel Stehule wrote: >>> >

Re: [HACKERS] Index only scan for cube and seg

On Fri, Oct 27, 2017 at 9:54 PM, Tom Lane wrote: > Robert Haas writes: > > On Thu, Oct 26, 2017 at 12:22 PM, Andrey Borodin > wrote: > >> For cube there is new default opclass. > > > I seem to recall that changing the default

Re: [HACKERS] ALTER COLUMN TYPE vs. domain constraints

On Fri, Oct 27, 2017 at 11:15 AM, Tom Lane wrote: > We could consider back-patching the attached to cover this, but > I'm not entirely sure it's worth the trouble, because I haven't > thought of any non-silly use-cases in the absence of domains > over composite. Comments?

Re: [HACKERS] Current int & float overflow checking is slow.

On 2017-10-24 15:28:17 -0400, Tom Lane wrote: > Also, if I recall the old discussion properly, one concern was getting > uniform behavior across different platforms. I'm worried that if we do > what Andres suggests, we'll get behavior that is not only different but > platform-specific. Now, to

Re: [HACKERS] MERGE SQL Statement for PG11

On Sat, Oct 28, 2017 at 12:49 PM, Simon Riggs wrote: > Nothing I am proposing blocks later work. Actually, many things will block future work if you go down that road. You didn't respond to the specific points I raised, but that doesn't mean that they're not real. >

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Oct 27, 2017 at 3:00 PM, Serge Rielau wrote: >> What other systems *do* have this restriction? I've never seen one that did. > > Not clear what you are leading up to here. > When I did MERGE in DB2 there was also no limitation: > "Each row in the target can only be

Re: [HACKERS] MERGE SQL Statement for PG11

On 28 October 2017 at 20:39, Peter Geoghegan wrote: > On Sat, Oct 28, 2017 at 3:10 AM, Simon Riggs wrote: >> SQL:2011 specifically states "The extent to which an >> SQL-implementation may disallow independent changes that are not >> significant is

Re: [HACKERS] MERGE SQL Statement for PG11

On Sat, Oct 28, 2017 at 3:10 AM, Simon Riggs wrote: > SQL:2011 specifically states "The extent to which an > SQL-implementation may disallow independent changes that are not > significant is implementation-defined”, so in my reading the above > behaviour would make us fully

Re: [HACKERS] unsafe tuple releasing in get_default_partition_oid

On Sat, Oct 28, 2017 at 11:13 AM, Robert Haas wrote: > On Sat, Oct 28, 2017 at 10:03 AM, Julien Rouhaud wrote: >> I just noticed that get_default_partition_oid() tries to release the >> tuple even if it isn't valid. >> Trivial patch attached. > > Oops.

Re: [HACKERS] proposal: schema variables

Hi 2017-10-28 16:24 GMT+02:00 Chris Travers : > > > On Thu, Oct 26, 2017 at 9:21 AM, Pavel Stehule > wrote: > >> Hi, >> >> I propose a new database object - a variable. The variable is persistent >> object, that holds unshared session based

Re: [HACKERS] Parallel safety for extern params

On Sat, Oct 28, 2017 at 2:02 AM, Robert Haas wrote: > On Mon, Oct 16, 2017 at 12:59 PM, Amit Kapila wrote: > When I tried back-porting the patch to v10 I discovered that the > plpgsql changes conflict heavily and that ripping them out all the way >

Re: [HACKERS] proposal: schema variables

On Thu, Oct 26, 2017 at 9:21 AM, Pavel Stehule wrote: > Hi, > > I propose a new database object - a variable. The variable is persistent > object, that holds unshared session based not transactional in memory value > of any type. Like variables in any other languages.

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

Hi 2017-09-22 21:31 GMT+02:00 Pavel Stehule : > > > 2017-09-22 21:12 GMT+02:00 Peter Eisentraut com>: > >> On 9/22/17 09:16, Pavel Stehule wrote: >> > Example: somebody set SORT_COLUMNS to schema_name value. This is >> > nonsense for \l

[HACKERS] WIP: Restricting pg_rewind to data/wal dirs

Hi; There are still some cleanup bits needed here but I wanted to get feedback on my general direction. I hope to submit for commit fest soon if the general feedback is good. Tests are passing (with adjustments intended for change of behaviour in one test script). I want to note that Crimson

Re: [HACKERS] MERGE SQL Statement for PG11

On 28 October 2017 at 00:31, Michael Paquier wrote: > On Fri, Oct 27, 2017 at 9:00 AM, Robert Haas wrote: >> On Fri, Oct 27, 2017 at 4:41 PM, Simon Riggs wrote: >>> I didn't say it but my intention was to just throw an

Re: [HACKERS] Fix typo in blvacuum.c

On Tue, Oct 17, 2017 at 3:48 AM, Seki, Eiji wrote: > I found a typo in comment of blvacuum.c, so attach the patch for it. Thanks. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] Parallel Append implementation

On Thu, Oct 19, 2017 at 9:05 AM, Amit Khandekar wrote: >> + *ExecAppendEstimate >> + * >> + *estimates the space required to serialize Append node. >> >> Ugh, this is wrong, but I notice it follows various other >> equally-wrong comments for other

Re: [HACKERS] Partition-wise aggregation/grouping

On Fri, Oct 27, 2017 at 1:01 PM, Jeevan Chalke wrote: > 1. Added separate patch for costing Append node as discussed up-front in the > patch-set. > 2. Since we now cost Append node, we don't need > partition_wise_agg_cost_factor > GUC. So removed that. The

Re: [HACKERS] Reading timeline from pg_control on replication slave

Hi, Michael! Thank you very much for these comments! > 28 окт. 2017 г., в 3:09, Michael Paquier > написал(а): > > ThisTimeLineID is not something you can rely on for standby backends > as it is not set during recovery. That's the reason behind > pg_walfile_name

Re: [HACKERS] Adding table_constraint description in ALTER TABLE synopsis

On Thu, Oct 26, 2017 at 3:23 PM, Lætitia Avrot wrote: > In documentation, I've found that table_constraint is used in the ALTER > TABLE synopsis but that definition of table_constraint is missing, so I > submitted bug #14873. > > I found the table_constraint definition

Re: [HACKERS] Typos in src/backend/optimizer/README

On Fri, Oct 27, 2017 at 9:34 AM, Etsuro Fujita wrote: > This sentence in the section of Partition-wise joins in > src/backend/optimizer/README should be fixed: "This technique of breaking > down a join between partition tables into join between their partitions is >

Re: [HACKERS] unsafe tuple releasing in get_default_partition_oid

On Sat, Oct 28, 2017 at 10:03 AM, Julien Rouhaud wrote: > I just noticed that get_default_partition_oid() tries to release the > tuple even if it isn't valid. > Trivial patch attached. Oops. I wonder how that managed to survive testing. Committed. -- Robert Haas

[HACKERS] unsafe tuple releasing in get_default_partition_oid

Hi, I just noticed that get_default_partition_oid() tries to release the tuple even if it isn't valid. Trivial patch attached. diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c index 07fdf66c38..66ec214e02 100644 --- a/src/backend/catalog/partition.c +++