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

2016-06-03 Thread Markus Wanner
On 06/03/2016 12:14 AM, Tom Lane wrote: > Markus Wanner writes: >> I'm even wondering if 'fe80::1%1'::inet = 'fe80::1%2'::inet shouldn't >> simply yield true. After all, it's the same (non-global) address. > > Surely not? If the zone_ids didn't mean anything, why would the

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Masahiko Sawada
On Sat, Jun 4, 2016 at 12:08 AM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 10:49 AM, Masahiko Sawada > wrote: >> That patch also incorporates the following review comment. >> We can push at least this fix. > > Can you submit that part as a

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Fabien COELHO
Hello Noah, The usual PostgreSQL handling of a deeply workload-dependent performance feature is to disable it by default. That's what I'm inclined to do here, for every GUC the feature added. Sophisticated users will nonetheless fully exploit this valuable mechanism in 9.6. I don't think

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 09:24:28 -0700, Andres Freund wrote: > This unstable performance issue, with the minute-long stalls, is the > worst and most frequent production problem people hit with postgres in > my experience, besides issues with autovacuum. Ignoring that is just > hurting our users. Oh, and a

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada wrote: >> Can you submit that part as a separate patch? > > Attached. Thanks, committed. >>> I'm address the review comment of 7087166 commit, and will post the patch. >> >> When? > > On Saturday. Great. Will that address

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 2:09 AM, Andres Freund wrote: > On 2016-06-03 01:57:33 -0400, Noah Misch wrote: >> > Which means that transactional workloads that are bigger than the OS >> > memory, or which have a non-uniform distribution leading to some >> > locality, are likely to

Re: [HACKERS] [DOC][PATCH]bloom index options limits

2016-06-03 Thread Tom Lane
Nikolay Shaplov writes: > Hi! I've changed limits of the length option in the "Introduction" section. > They should be 1 ≤ colN ≤ 2048 instead of 1 < colN < 2048 (I've talk with > the > author about it) I rewrote that text this morning, so this patch won't apply

Re: [HACKERS] Problem with dumping bloom extension

2016-06-03 Thread Stephen Frost
Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > > If a database with the bloom extension installed is dumped and restored, > > there's an error with the access method creation: > > > > createdb bloomtest > > psql

[HACKERS] [DOC][PATCH]bloom index options limits

2016-06-03 Thread Nikolay Shaplov
Hi! I've changed limits of the length option in the "Introduction" section. They should be 1 ≤ colN ≤ 2048 instead of 1 < colN < 2048 (I've talk with the author about it) I've also added minimal maximum and default values for description of options in the "Parameters" section, because I think

Re: [HACKERS] array of domain types

2016-06-03 Thread Konstantin Knizhnik
On 03.06.2016 02:02, Rod Taylor wrote: On Thu, Jun 2, 2016 at 10:42 AM, Konstantin Knizhnik > wrote: On 02.06.2016 17:22, Tom Lane wrote: konstantin knizhnik

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 10:48:18 -0400, Noah Misch wrote: > On Thu, Jun 02, 2016 at 11:09:22PM -0700, Andres Freund wrote: > > > Today's defaults for *_flush_after greatly smooth and accelerate > > > performance > > > for one class of plausible workloads while greatly slowing a different > > > class > > >

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

2016-06-03 Thread Tom Lane
Markus Wanner writes: > Considering that Postgres is not unlikely to write INET types to > permanent storage, its values should better survive a reboot. And while > I have some doubts about persistence of interface names, those clearly > have a higher chance of surviving a

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 10:49 AM, Masahiko Sawada wrote: > That patch also incorporates the following review comment. > We can push at least this fix. Can you submit that part as a separate patch? > I'm address the review comment of 7087166 commit, and will post the patch.

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

2016-06-03 Thread Robert Haas
On Sat, May 7, 2016 at 9:07 AM, Amit Kapila wrote: > From the above output it is clear that parallel restricted function is > pushed down below gather node. I found that though we have have care fully > avoided to push pathtarget below GatherPath in

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund wrote: >> I've always heard that guideline as "roughly 1/4, but not more than >> about 8GB" - and the number of people with more than 32GB of RAM is >> going to just keep going up. > > I think that upper limit is wrong. But even

Re: [HACKERS] Negators for operators

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 3:02 PM, David Fetter wrote: > While constructing a somewhat hairy query with HAVING in it, I noticed > that a lot of operators don't have negators, which would have been > convenient for the class of queries I was constructing. Further > investigation

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 13:33:31 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: > > On 2016-06-03 12:31:58 -0400, Robert Haas wrote: > >> Now, what varies IME is how much total RAM there is in the system and > >> how frequently they write that data, as

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

2016-06-03 Thread Markus Wanner
On 06/03/2016 06:55 PM, Tom Lane wrote: > More importantly, > on what basis do you conclude that the inet type will only be asked to > store link-local addresses that are currently valid on the local machine? > It is not very hard to think of applications where that wouldn't be the > case. That's

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 1:43 PM, Andres Freund wrote: >> I really don't get it. There's nothing in any set of guidelines for >> setting shared_buffers that I've ever seen which would cause people to >> avoid this scenario. > > The "roughly 1/4" of memory guideline already

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 13:42:09 -0400, Tom Lane wrote: > Robert Haas writes: > > On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: > >> Note that other operating systems like windows and freebsd *alreaddy* > >> write back much more aggressively (independent

Re: [HACKERS] Change in order of criteria - reg

2016-06-03 Thread Robert Haas
On Wed, Jun 1, 2016 at 5:22 AM, Amit Langote wrote: > On 2016/06/01 13:07, sri harsha wrote: >> Hi, >> >> In PostgreSQL , does the order in which the criteria is given matter ?? >> For example >> >> Query 1 : Select * from TABLE where a > 5 and b < 10; >> >>

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

2016-06-03 Thread David G. Johnston
On Fri, Jun 3, 2016 at 1:55 PM, Robert Haas wrote: > On Wed, Jun 1, 2016 at 5:59 PM, David G. Johnston > wrote: > > Maybe I don't understand PGDLLEXPORT... > > We're talking about PGDLLIMPORT. > ​Typo, was thinking "we export this for others

[HACKERS] Negators for operators

2016-06-03 Thread David Fetter
Folks, While constructing a somewhat hairy query with HAVING in it, I noticed that a lot of operators don't have negators, which would have been convenient for the class of queries I was constructing. Further investigation showed that while 380 of the built-in operators had negators, 395 do not.

Re: [HACKERS] array of domain types

2016-06-03 Thread Jim Nasby
On 6/3/16 11:50 AM, Konstantin Knizhnik wrote: Originally I was mostly interested in domains as kind of typedefs: convenient way to assign type to some particular kind of columns, for example object reference used in ORM. There are two main goals of using domain here: 1. Be able to easily change

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

2016-06-03 Thread Robert Haas
On Wed, Jun 1, 2016 at 7:39 PM, Michael Paquier wrote: >> In short, I'd vote for putting this change in HEAD, but I see no need to >> back-patch. > > OK, fine for me. Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

2016-06-03 Thread Robert Haas
On Wed, Jun 1, 2016 at 5:59 PM, David G. Johnston wrote: > Maybe I don't understand PGDLLEXPORT... We're talking about PGDLLIMPORT. > The PostgreSQL function/feature in question is already in place and can be > accessed by someone using Linux or other unix-like

Re: [HACKERS] Change in order of criteria - reg

2016-06-03 Thread David G. Johnston
On Wed, Jun 1, 2016 at 12:07 AM, sri harsha wrote: > > Hi, > > In PostgreSQL , does the order in which the criteria is given matter > ?? For example > > Query 1 : Select * from TABLE where a > 5 and b < 10; > > Query 2 : Select * from TABLE where b <10 and a > 5; > >

Re: [HACKERS] Tracking wait event for latches

2016-06-03 Thread Robert Haas
On Thu, Jun 2, 2016 at 1:34 AM, Michael Paquier wrote: > This patch is shaped this way intentionally based on the feedback I > received at PGCon (Robert and others). We could provide a routine that > extensions call in _PG_init to register a new latch event name in >

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Tom Lane
Robert Haas writes: > On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: >> Note that other operating systems like windows and freebsd *alreaddy* >> write back much more aggressively (independent of this change). I seem >> to recall you yourself

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

2016-06-03 Thread Andres Freund
On 2016-06-03 14:00:00 -0400, Robert Haas wrote: > On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: > > I'm not convinced of that. Hiding unexpected issues for longer, just to > > continue kind-of-operating, can make the impact of problems a lot worse, > > and it makes

Re: [HACKERS] Negators for operators

2016-06-03 Thread Tom Lane
Robert Haas writes: > On Fri, Jun 3, 2016 at 3:02 PM, David Fetter wrote: >> While constructing a somewhat hairy query with HAVING in it, I noticed >> that a lot of operators don't have negators, which would have been >> convenient for the class of

Re: [HACKERS] Changed SRF in targetlist handling

2016-06-03 Thread Tom Lane
Merlin Moncure writes: > On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: >> Andres Freund writes: >>> If we go with rewriting this into LATERAL, I'd vote for 2.5 (trailed by >>> option 1), that'd keep most of the functionality, and

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

2016-06-03 Thread Robert Haas
On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote: >> Err, wow. That makes my head hurt. Can you explain why this case >> only arises for appendrel children, and not for plain rels? > > Well, plain rels only output Vars ;-) Hmm. Dilip's example in

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

2016-06-03 Thread Tom Lane
Markus Wanner writes: > That leaves me wondering if it's really worth extending INET, though. > TEXT would be just fine to store a textual scope id. And it makes it > utterly clear that there's no magic involved. True, but it would force users to disassemble and reassemble the

Re: [HACKERS] PostmasterPid not marked with PGDLLIMPORT

2016-06-03 Thread Michael Paquier
On Sat, Jun 4, 2016 at 2:56 AM, Robert Haas wrote: > On Wed, Jun 1, 2016 at 7:39 PM, Michael Paquier > wrote: >>> In short, I'd vote for putting this change in HEAD, but I see no need to >>> back-patch. >> >> OK, fine for me. > > Done. Thanks

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

2016-06-03 Thread Kevin Grittner
On Fri, May 27, 2016 at 10:18 AM, Kevin Grittner wrote: > On Fri, May 27, 2016 at 9:58 AM, Kevin Grittner wrote: >> On Tue, May 24, 2016 at 4:56 PM, Andres Freund wrote: > >>> If an old session with >= repeatable read accesses a

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

2016-06-03 Thread David Steele
On 6/3/16 4:13 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:12 PM, Andres Freund wrote: >> On 2016-06-03 14:00:00 -0400, Robert Haas wrote: >>> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: I'm not convinced of that. Hiding unexpected

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 2:12 PM, Andres Freund wrote: > On 2016-06-03 14:00:00 -0400, Robert Haas wrote: >> On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: >> > I'm not convinced of that. Hiding unexpected issues for longer, just to >> > continue

[HACKERS] Changed SRF in targetlist handling

2016-06-03 Thread David G. Johnston
On Friday, June 3, 2016, Tom Lane > wrote: > Merlin Moncure writes: > > On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: > >> Andres Freund writes: > >>> If we go

Re: [HACKERS] Changed SRF in targetlist handling

2016-06-03 Thread Tom Lane
"David G. Johnston" writes: > On Friday, June 3, 2016, Tom Lane > wrote: >> Merlin Moncure writes: >>> another interesting case today is: >>> create sequence s; >>> select

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

2016-06-03 Thread Kevin Grittner
On Fri, May 27, 2016 at 10:35 AM, Kevin Grittner wrote: > On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote: >> [ANALYZE of index with expression may fail to update statistics >> if ANALYZE runs longer than old_snapshot_threshold] >> If we can get

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 15:17:06 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund wrote: > >> I've always heard that guideline as "roughly 1/4, but not more than > >> about 8GB" - and the number of people with more than 32GB of RAM is > >> going to just keep

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

2016-06-03 Thread Robert Haas
On Wed, Jun 1, 2016 at 9:35 PM, Noah Misch wrote: > [Action required within 72 hours. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 9.6 open item. Robert, > since you committed the patch believed to have created it, you own this open

Re: [HACKERS] Number of parentheses in check constraints affected by operator_precedence_warning

2016-06-03 Thread Tom Lane
Jean-Pierre Pelletier writes: > We noticed on PostgreSQL 9.5.3 that the number of parentheses in check > constraints expressions > vary depending on the setting of operator_precedence_warning. Hmm, yeah, another place that needs to look through AEXPR_PAREN nodes :-(.

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Noah Misch
On Fri, Jun 03, 2016 at 03:17:06PM -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 2:20 PM, Andres Freund wrote: > >> > I'm inclined to give up and disable backend_flush_after (not the rest), > >> > because it's new and by far the "riskiest". But I do think it's a > >> >

[HACKERS] Number of parentheses in check constraints affected by operator_precedence_warning

2016-06-03 Thread Jean-Pierre Pelletier
Hi, We noticed on PostgreSQL 9.5.3 that the number of parentheses in check constraints expressions vary depending on the setting of operator_precedence_warning. -- The following reproduces this issue which we first saw by restoring into 9.5.3 a 9.4.8 dump on two servers which had different

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 12:31:58 -0400, Robert Haas wrote: > Now, what varies IME is how much total RAM there is in the system and > how frequently they write that data, as opposed to reading it. If > they are on a tightly RAM-constrained system, then this situation > won't arise because they won't be

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 20:41:33 -0400, Noah Misch wrote: > Disabling just backend_flush_after by default works for me, so let's do that. > Though I would not elect, on behalf of PostgreSQL, the risk of enabling > {bgwriter,checkpoint,wal_writer}_flush_after by default, a reasonable person > may choose to

Re: [HACKERS] Prepared statements and generic plans

2016-06-03 Thread Albe Laurenz
David G. Johnston wrote: > On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote: >> In Postgres 9.2 we improved the logic of when generic plans are used by >> EXECUTE. We weren't sure how well it would work, and the docs included >> a vague description on when generic plans are

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

2016-06-03 Thread Michael Paquier
On Fri, Jun 3, 2016 at 1:03 PM, Tom Lane wrote: > I wrote: >> Jeff Janes writes: >>> My biggest gripe with it at the moment is that the signature size should be >>> expressed in bits, and then internally rounded up to a multiple of 16, >>> rather than

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread Albe Laurenz
Robert Haas wrote: > On Wed, Jun 1, 2016 at 5:29 PM, Tom Lane wrote: > > Robert Haas writes: > >> I've largely given up hope of coming up with an alternative that can > >> attract more than one vote and that is also at least mildly accurate, > >> but

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

2016-06-03 Thread Corey Huinker
On Fri, Jun 3, 2016 at 1:06 AM, Craig Ringer wrote: > On 3 June 2016 at 04:48, Corey Huinker wrote: > >> A while back, there was a push to make COPY gzip-aware. That didn't >> happen, but COPY FROM PROGRAM did, and it scratches the same itch. >> >

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 01:57:33 -0400, Noah Misch wrote: > > Which means that transactional workloads that are bigger than the OS > > memory, or which have a non-uniform distribution leading to some > > locality, are likely to be faster. In practice those are *hugely* more > > likely than the uniform

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

2016-06-03 Thread Kyotaro HORIGUCHI
At Thu, 2 Jun 2016 12:17:11 -0400, Alvaro Herrera wrote in <20160602161711.GA239156@alvherre.pgsql> > Tom Lane wrote: > > Kyotaro HORIGUCHI writes: > > > Apart from the invalid snapshot problem, I looked the patch > > > previously

[HACKERS] chkpass_in should not be volatile

2016-06-03 Thread Thom Brown
...or at least according to the warning message: postgres=# CREATE EXTENSION chkpass ; WARNING: type input function chkpass_in should not be volatile Thom

[HACKERS] Problem with dumping bloom extension

2016-06-03 Thread Thom Brown
Hi, If a database with the bloom extension installed is dumped and restored, there's an error with the access method creation: createdb bloomtest psql -c 'CREATE EXTENSION bloom;' bloomtest pg_dump -d bloomtest > ~/tmp/bloom.sql createdb bloomtest2 psql -d bloomtest2 -f ~/tmp/bloom.sql The

[HACKERS] hstore: add hstore_length function

2016-06-03 Thread Korbin Hoffman
Hi there- I've attached a small patch exposing HS_COUNT to the user as "hstore_length(hstore)". Documentation, upgrade sql files, and a few tests are also included. Almost every hstore function calls HS_COUNT, but I couldn't determine if there was a reason this exposure didn't already exist.

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

2016-06-03 Thread Dmitry Igrishin
2016-05-24 5:01 GMT+03:00 Craig Ringer : > > On 24 May 2016 at 00:00, Michael Paquier wrote: >> >> On Mon, May 23, 2016 at 8:50 AM, Andres Freund wrote: > > >> >> > yay^2. >> >> I'll follow this mood. Yeha. > > > > BTW, I've

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Masahiko Sawada
On Sat, May 7, 2016 at 5:42 AM, Robert Haas wrote: > On Thu, May 5, 2016 at 2:20 PM, Andres Freund wrote: >> On 2016-05-02 14:48:18 -0700, Andres Freund wrote: >>> 7087166 pg_upgrade: Convert old visibility map format to new format. >> >> +const char *

Re: [HACKERS] HashAggregate row estimate = 200

2016-06-03 Thread David Rowley
On 4 June 2016 at 14:10, Christophe Pettus wrote: > Something I've noticed frequently is that HashAggregate will, especially if > the children are Append with one of the nodes a non-seqscan, estimate 200 > rows rather than a calculated vlaue. Where is that value coming from?

[HACKERS] HashAggregate row estimate = 200

2016-06-03 Thread Christophe Pettus
Something I've noticed frequently is that HashAggregate will, especially if the children are Append with one of the nodes a non-seqscan, estimate 200 rows rather than a calculated vlaue. Where is that value coming from? The statistics target, a hardwired constant, or something else? -- --

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

2016-06-03 Thread Robert Haas
On Thu, May 26, 2016 at 5:57 AM, Amit Kapila wrote: > On Tue, May 24, 2016 at 6:36 PM, Andreas Seltenreich > wrote: >> >> >> Each of the sent plans was collected when a worker dumped core due to >> the failed assertion. More core dumps than plans

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

2016-06-03 Thread Jeff Janes
On Thu, Jun 2, 2016 at 9:03 PM, Tom Lane wrote: > I wrote: >> Jeff Janes writes: >>> My biggest gripe with it at the moment is that the signature size should be >>> expressed in bits, and then internally rounded up to a multiple of 16, >>> rather than

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 10:25 PM, Masahiko Sawada wrote: >>> + charnew_vmbuf[BLCKSZ]; >>> + char *new_cur = new_vmbuf; >>> + boolempty = true; >>> + bool

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

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 5:02 PM, Tom Lane wrote: > Markus Wanner writes: >> That leaves me wondering if it's really worth extending INET, though. >> TEXT would be just fine to store a textual scope id. And it makes it >> utterly clear that there's no magic

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Masahiko Sawada
On Sat, Jun 4, 2016 at 12:41 PM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 10:25 PM, Masahiko Sawada > wrote: + charnew_vmbuf[BLCKSZ]; + char *new_cur = new_vmbuf; +

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Masahiko Sawada
On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada > wrote: >>> Can you submit that part as a separate patch? >> >> Attached. > > Thanks, committed. > I'm address the review comment of 7087166

Re: [HACKERS] Prepared statements and generic plans

2016-06-03 Thread Bruce Momjian
On Fri, Jun 3, 2016 at 08:27:38AM -0400, David G. Johnston wrote: > ​This goes back to Bruce's motivation but as long as it goes into the > internals > section I have no problem adding material that someone felt was worth their OK, updated version attached. I added "potential" to the first

Re: [HACKERS] XTM & parallel search

2016-06-03 Thread Amit Kapila
On Fri, Jun 3, 2016 at 6:49 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > On 03.06.2016 16:05, Amit Kapila wrote: > > On Fri, Jun 3, 2016 at 1:34 AM, Konstantin Knizhnik < > k.knizh...@postgrespro.ru> wrote: > >> We have to add three more functions

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

2016-06-03 Thread Tom Lane
Robert Haas writes: > Yeah, but what if somebody doesn't want to store scopes? [ shrug... ] We can invent a "strip_scope()" sort of function, analogous to the weight-stripping function for tsvectors, or several other examples. That's a really lame excuse for not being

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

2016-06-03 Thread Tom Lane
Jeff Janes writes: > One thing from the commit-message: > "On-disk, we can still store it in words, so as to not break on-disk > compatibility with beta1." > Hasn't that ship already sailed? No. > Or is the concern about intra-version pg_upgrade rather than direct >

Re: [HACKERS] Parallel safety tagging of extension functions

2016-06-03 Thread Andreas Karlsson
Hi, Here is the patch split into many small patches as you suggested. The current patches are based on top of the patch which fixes the signatures for gin and gist functions. These patches only touch functions which never should be called directly, so they are fine to skip. I decided to

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 12:39 PM, Andres Freund wrote: > On 2016-06-03 12:31:58 -0400, Robert Haas wrote: >> Now, what varies IME is how much total RAM there is in the system and >> how frequently they write that data, as opposed to reading it. If >> they are on a tightly

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

2016-06-03 Thread Robert Haas
On Fri, May 27, 2016 at 8:44 PM, Andres Freund wrote: > I'm not convinced of that. Hiding unexpected issues for longer, just to > continue kind-of-operating, can make the impact of problems a lot worse, > and it makes it very hard to actually learn about the issues. So if we

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Andres Freund
On 2016-06-03 13:47:58 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 1:43 PM, Andres Freund wrote: > >> I really don't get it. There's nothing in any set of guidelines for > >> setting shared_buffers that I've ever seen which would cause people to > >> avoid this

Re: [HACKERS] Changed SRF in targetlist handling

2016-06-03 Thread Merlin Moncure
On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-05-25 15:20:03 -0400, Tom Lane wrote: >>> We could certainly make a variant behavior in nodeFunctionscan.c that >>> emulates that, if we feel that being exactly

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread Robert Haas
On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > I was assuming that we would have *both* per-operation and per-statement > limits. I can see reasons for having both, I can see why power users > would want both, but it's going to be overwhelming to casual users. I don't

Re: [HACKERS] XTM & parallel search

2016-06-03 Thread Amit Kapila
On Fri, Jun 3, 2016 at 1:34 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > We have to add three more functions to eXtensible Transaction Manager API > (XTM): > > /* > * Calculate transaction state size. This method is invoked by > EstimateTransactionStateSpace to copy

Re: [HACKERS] XTM & parallel search

2016-06-03 Thread Konstantin Knizhnik
On 03.06.2016 16:05, Amit Kapila wrote: On Fri, Jun 3, 2016 at 1:34 AM, Konstantin Knizhnik > wrote: We have to add three more functions to eXtensible Transaction Manager API (XTM): /* * Calculate

Re: [HACKERS] Prepared statements and generic plans

2016-06-03 Thread David G. Johnston
On Fri, Jun 3, 2016 at 3:17 AM, Albe Laurenz wrote: > > > I'd maybe go with something like this: > > > > All executions of a prepared statement having zero parameters will use > the same plan so the planning > > time taken during the first execution will be spread across

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread Robert Haas
On Fri, Jun 3, 2016 at 8:30 AM, David G. Johnston wrote: > How big is the hazard of future-naming this and documenting the present > limitation? Is the casual user reading explains even going to be aware of > that particular implementation detail? Well, see, the nice

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread David G. Johnston
On Fri, Jun 3, 2016 at 8:20 AM, Robert Haas wrote: > On Thu, Jun 2, 2016 at 4:35 PM, Josh berkus wrote: > > I was assuming that we would have *both* per-operation and per-statement > > limits. I can see reasons for having both, I can see why power

Re: [HACKERS] Statement timeout

2016-06-03 Thread Tatsuo Ishii
>> I didn't noticed it. Could you give me the message id or URL? >> >> > https://commitfest.postgresql.org/10/634/ > > https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=b4dm...@mail.gmail.com#CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=b4dm...@mail.gmail.com

Re: [HACKERS] Rename synchronous_standby_names?

2016-06-03 Thread Vik Fearing
On 01/06/16 02:49, Michael Paquier wrote: > On Wed, Jun 1, 2016 at 3:56 AM, David G. Johnston > wrote: >> On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut >> wrote: >>> >>> On 5/31/16 1:47 PM, Jaime Casanova wrote: Are we

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread Josh berkus
On 06/02/2016 09:33 PM, Peter Eisentraut wrote: > On 6/3/16 12:21 AM, Petr Jelinek wrote: >> On 01/06/16 17:55, David G. Johnston wrote: >>> On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek >> >wrote: >>> >>> That GUC also controls worker

Re: [HACKERS] chkpass_in should not be volatile

2016-06-03 Thread David G. Johnston
On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote: > Thom Brown writes: > > ...or at least according to the warning message: > > postgres=# CREATE EXTENSION chkpass ; > > WARNING: type input function chkpass_in should not be volatile > > See thread here: > > >

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

2016-06-03 Thread Michael Paquier
On Fri, Jun 3, 2016 at 3:11 PM, Michael Paquier wrote: > On Fri, Jun 3, 2016 at 1:03 PM, Tom Lane wrote: >> I wrote: >>> Jeff Janes writes: My biggest gripe with it at the moment is that the signature size should be

Re: [HACKERS] regexp_match() returning text

2016-06-03 Thread Jim Nasby
On 5/30/16 1:01 PM, Andrew Gierth wrote: Returning an array containing the values of all capture groups might be more useful (substring returns the value of the first capture group if any, otherwise the matched string). +1. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread Tom Lane
Robert Haas writes: > I think we should just go with max_parallel_workers for a limit on > total parallel workers within max_work_processes, and > max_parallel_workers_per_gather for a per-Gather limit. It's slightly > annoying that we may end up renaming the latter GUC,

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Robert Haas
On Thu, Jun 2, 2016 at 11:24 AM, Masahiko Sawada wrote: > Attached patch optimises skipping pages logic so that blkno can jump to > next_unskippable_block directly while counting the number of all_visible > and all_frozen pages. So we can avoid double checking visibility

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

2016-06-03 Thread Tom Lane
Kyotaro HORIGUCHI writes: > For sure, any of the "dangers" of TerminateThread don't matter > for this case. I think that this one: >> If the target thread is allocating memory from the heap, the heap >> lock will not be released. is potentially a hazard, which

Re: [HACKERS] Problem with dumping bloom extension

2016-06-03 Thread Michael Paquier
On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > If a database with the bloom extension installed is dumped and restored, > there's an error with the access method creation: > > createdb bloomtest > psql -c 'CREATE EXTENSION bloom;' bloomtest > pg_dump -d bloomtest >

Re: [HACKERS] chkpass_in should not be volatile

2016-06-03 Thread Tom Lane
Thom Brown writes: > ...or at least according to the warning message: > postgres=# CREATE EXTENSION chkpass ; > WARNING: type input function chkpass_in should not be volatile See thread here:

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Robert Haas
On Wed, Jun 1, 2016 at 3:50 AM, Masahiko Sawada wrote: > Attached patch fixes only above comments, other are being addressed now. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

[HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

2016-06-03 Thread Noah Misch
On Wed, Jun 01, 2016 at 09:29:54PM -0400, Noah Misch wrote: > On Sun, May 29, 2016 at 01:36:01AM -0400, Noah Misch wrote: > > On Fri, May 06, 2016 at 03:06:01PM -0400, Robert Haas wrote: > > > On Thu, May 5, 2016 at 10:48 AM, David Rowley > > > wrote: > > > > On 5

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

2016-06-03 Thread Tom Lane
Michael Paquier writes: > Actually, the docs could be more polished. I think the docs could stand to be rewritten from scratch ;-). But upthread there was an offer to work on them if we made the code behavior saner. I've done the latter part, I don't want to do the

Re: [HACKERS] chkpass_in should not be volatile

2016-06-03 Thread Thom Brown
On 3 June 2016 at 15:26, David G. Johnston wrote: > On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote: > >> Thom Brown writes: >> > ...or at least according to the warning message: >> > postgres=# CREATE EXTENSION chkpass ; >> >

Re: [HACKERS] chkpass_in should not be volatile

2016-06-03 Thread David G. Johnston
On Fri, Jun 3, 2016 at 10:41 AM, Thom Brown wrote: > On 3 June 2016 at 15:26, David G. Johnston > wrote: > >> On Fri, Jun 3, 2016 at 9:56 AM, Tom Lane wrote: >> >>> Thom Brown writes: >>> > ...or at least

Re: [HACKERS] Perf Benchmarking and regression.

2016-06-03 Thread Noah Misch
On Thu, Jun 02, 2016 at 11:09:22PM -0700, Andres Freund wrote: > On 2016-06-03 01:57:33 -0400, Noah Misch wrote: > > > Which means that transactional workloads that are bigger than the OS > > > memory, or which have a non-uniform distribution leading to some > > > locality, are likely to be

Re: [HACKERS] Reviewing freeze map code

2016-06-03 Thread Masahiko Sawada
On Fri, Jun 3, 2016 at 11:03 PM, Robert Haas wrote: > On Thu, Jun 2, 2016 at 11:24 AM, Masahiko Sawada > wrote: >> Attached patch optimises skipping pages logic so that blkno can jump to >> next_unskippable_block directly while counting the number

  1   2   >