Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

2016-07-03 Thread Kyotaro HORIGUCHI
Sorry for the absense. Thank you for registering it. regards. At Fri, 24 Jun 2016 14:46:25 +0900, Michael Paquier wrote in > On Thu, Jun 23, 2016 at 3:51 PM, Michael Paquier >

[HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

2016-07-03 Thread Andrew Borodin
Hi! >I think you should implement PageReplaceItem() version and add it to the >commitfest. Here is the patch. I've called function PageIndexTupleOverwrite() because it's suitable only for indices. It works on my tests and performance is the same as in proof-of-concept (despite some sanity checks

Re: [HACKERS] IPv6 link-local addresses and init data type

2016-07-03 Thread Haribabu Kommi
On Wed, Jun 29, 2016 at 6:31 AM, Markus Wanner wrote: >> I added another character array of 256 member into inet_struct as a last >> member >> to store the zone id. > > I haven't looked at the patch in detail, but zeroing or memcpy'ing those > 256 bytes seems like overkill to

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

2016-07-03 Thread Thomas Munro
On Wed, Jun 29, 2016 at 11:51 AM, Stefan Keller wrote: > Hi, > > FYI: I'd just like to point you to following two forthcoming standard > parts from "ISO/IEC JTS 1/SC 32" comittee: one on JSON, and one on > "Multi-Dimensional Arrays" (SQL/MDA). > > They define there some things

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

2016-07-03 Thread Michael Paquier
On Mon, Jul 4, 2016 at 6:34 AM, Peter Eisentraut wrote: > On 7/2/16 3:54 PM, Heikki Linnakangas wrote: >> >> In related news, RFC 7677 that describes a new SCRAM-SHA-256 >> authentication mechanism, was published in November 2015. It's identical >> to

Re: [HACKERS] to_date_valid()

2016-07-03 Thread Pavel Stehule
2016-07-04 5:19 GMT+02:00 Pavel Stehule : > > > 2016-07-04 4:25 GMT+02:00 Craig Ringer : > >> On 3 July 2016 at 09:32, Euler Taveira wrote: >> >>> On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: >>> > The attached patch

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

2016-07-03 Thread Michael Paquier
On Sat, Jul 2, 2016 at 2:56 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier >> wrote: > >> >> Okay, that argument I buy. >> >> >> >> I suppose this function/view should report no row at all

Re: [HACKERS] to_date_valid()

2016-07-03 Thread Gavin Flower
On 04/07/16 15:19, Pavel Stehule wrote: 2016-07-04 4:25 GMT+02:00 Craig Ringer >: On 3 July 2016 at 09:32, Euler Taveira > wrote: On 02-07-2016 22

Re: [HACKERS] to_date_valid()

2016-07-03 Thread Pavel Stehule
2016-07-04 4:25 GMT+02:00 Craig Ringer : > On 3 July 2016 at 09:32, Euler Taveira wrote: > >> On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: >> > The attached patch adds a new function "to_date_valid()" which will >> > validate the date and

Re: [HACKERS] Parallel appendrel scans?

2016-07-03 Thread Robert Haas
On Jul 3, 2016, at 6:58 PM, Tom Lane wrote: > It looks to me like set_append_rel_pathlist builds a partial path for > an appendrel only if there exist partial paths for all members of the > appendrel. I don't understand this restriction. Why could you not > build it from a

Re: [HACKERS] to_date_valid()

2016-07-03 Thread Craig Ringer
On 3 July 2016 at 09:32, Euler Taveira wrote: > On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: > > The attached patch adds a new function "to_date_valid()" which will > > validate the date and return an error if the input and output date do > > not match. Tests

Re: [HACKERS] Docs, backups, and MS VSS

2016-07-03 Thread Craig Ringer
On 2 July 2016 at 22:31, Craig Ringer wrote: > > - Microsoft VSS is NOT safe, as it fails point 2. It is atomic only on a > per-file level. You MUST use pg_start_backup() and pg_stop_backup() with > WAL archiving or automated copy of the extra WAL if you use MS VSS. Most >

[HACKERS] Parallel appendrel scans?

2016-07-03 Thread Tom Lane
It looks to me like set_append_rel_pathlist builds a partial path for an appendrel only if there exist partial paths for all members of the appendrel. I don't understand this restriction. Why could you not build it from a regular path for each appendrel child? You'd have to farm out entire

Re: [HACKERS] fixing subplan/subquery confusion

2016-07-03 Thread Tom Lane
I wrote: > Robert Haas writes: >> On Sun, Jul 3, 2016 at 1:14 PM, Tom Lane wrote: >>> You mentioned that you'll be on vacation for much of July. If you like, >>> I will take this open item off your hands, since I'll be around and can >>> deal with any

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

2016-07-03 Thread Peter Eisentraut
On 7/2/16 3:54 PM, Heikki Linnakangas wrote: In related news, RFC 7677 that describes a new SCRAM-SHA-256 authentication mechanism, was published in November 2015. It's identical to SCRAM-SHA-1, which is what this patch set implements, except that SHA-1 has been replaced with SHA-256. Perhaps we

Re: [HACKERS] fixing subplan/subquery confusion

2016-07-03 Thread Tom Lane
Robert Haas writes: > On Sun, Jul 3, 2016 at 1:14 PM, Tom Lane wrote: >> I think a cleaner way is to have set_append_rel_size() invoke >> set_rel_consider_parallel() on the child rels and then propagate their >> parallel-unsafety up to the parent. That

Re: [HACKERS] fixing subplan/subquery confusion

2016-07-03 Thread Robert Haas
On Sun, Jul 3, 2016 at 1:14 PM, Tom Lane wrote: > BTW, looking elsewhere in set_rel_consider_parallel, isn't there an extra > "return;" in the tablesample stanza, allpaths.c:541 as of HEAD? Looks to > me like we're failing to ever treat tablesampling as parallel-safe. > I'm

[HACKERS] INSERT .. SET syntax

2016-07-03 Thread Marko Tiikkaja
Hi, Here's a patch for $SUBJECT. I'll probably work on the docs a bit more before the next CF, but I thought I'd post it anyway. .m diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml index e710cf4..33e577b 100644 --- a/doc/src/sgml/ref/insert.sgml +++

Re: [HACKERS] fixing subplan/subquery confusion

2016-07-03 Thread Tom Lane
Robert Haas writes: > I dug into this a bit and found more problems. I wondered why Tom's > patch did this: > ! if (has_parallel_hazard((Node *) rte->subquery, > false)) > ! return; > ! break; >

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

2016-07-03 Thread Tom Lane
David Fetter writes: > On Sat, Jul 02, 2016 at 01:06:49PM -0400, David G. Johnston wrote: >> ​+1 for the idea - though restricting it to columns would not be ideal. > +1 for adding it to all the CREATEs whose objects support COMMENT. TBH, I think this is a pretty bad idea.

[HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-03 Thread Kevin Grittner
On Sat, Jul 2, 2016 at 5:10 PM, Robert Haas wrote: > On Sat, Jul 2, 2016 at 3:20 PM, Kevin Grittner wrote: >> Attached is a patch which fixes this issue, which I will push >> Monday unless there are objections. > > Considering that (1) this was posted

Re: [HACKERS] to_date_valid()

2016-07-03 Thread Andreas 'ads' Scherbaum
On 03.07.2016 07:05, Jaime Casanova wrote: El 2/7/2016 20:33, "Euler Taveira" > escribió: > > On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: > > The attached patch adds a new function "to_date_valid()" which will > > validate the date

[HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

2016-07-03 Thread Alexander Korotkov
Hi! On Sun, Jul 3, 2016 at 12:24 PM, Andrew Borodin wrote: > I think there is some room for improving GiST inserts. Following is > the description of what I think is performance problem. > > Function gistplacetopage in file /src/backend/access/gist/gist.c is > responsible

[HACKERS] GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

2016-07-03 Thread Andrew Borodin
Hi, hackers! I think there is some room for improving GiST inserts. Following is the description of what I think is performance problem. Function gistplacetopage in file /src/backend/access/gist/gist.c is responsible for updating or appending new tuple on GiST page. Currently, after checking