Re: [HACKERS] Try to fix endless loop in ecpg with informix mode

2017-11-01 Thread Julien Rouhaud
On Wed, Nov 1, 2017 at 12:22 PM, 高增琦 wrote: > Any comments? > Hi, You should register these patches for the next commitfest at https://commitfest.postgresql.org/15/. As Michael pointed out earlier, this commitfest will start soon so you should add your patches quickly.

Re: [HACKERS] unsafe tuple releasing in get_default_partition_oid

2017-10-28 Thread Julien Rouhaud
On Sat, Oct 28, 2017 at 11:13 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Oct 28, 2017 at 10:03 AM, Julien Rouhaud <rjuju...@gmail.com> wrote: >> I just noticed that get_default_partition_oid() tries to release the >> tuple even if it isn't valid. >>

[HACKERS] unsafe tuple releasing in get_default_partition_oid

2017-10-28 Thread Julien Rouhaud
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 +++

Re: [HACKERS] 64-bit queryId?

2017-10-20 Thread Julien Rouhaud
On Fri, Oct 20, 2017 at 3:44 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Oct 19, 2017 at 2:11 AM, Julien Rouhaud <rjuju...@gmail.com> wrote: >> I agree, and I'm perfectly fine with adding a comment around pgssHashKey. >> >> PFA a patch to war

Re: [HACKERS] 64-bit queryId?

2017-10-19 Thread Julien Rouhaud
On Thu, Oct 19, 2017 at 1:08 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud <rjuju...@gmail.com> wrote: >>> WIth current pgs

Re: [HACKERS] 64-bit queryId?

2017-10-18 Thread Julien Rouhaud
On Thu, Oct 12, 2017 at 2:46 AM, Michael Paquier wrote: > On Thu, Oct 12, 2017 at 9:05 AM, Robert Haas wrote: >> On Wed, Oct 4, 2017 at 9:00 PM, Michael Paquier >> wrote: >>> v4 looks correct to me. Testing it through

Re: [HACKERS] oversight in EphemeralNamedRelation support

2017-10-13 Thread Julien Rouhaud
On Fri, Oct 13, 2017 at 5:22 AM, Tom Lane wrote: > Thomas Munro writes: >> On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote: >>> Yeah, I agree --- personally I'd never write a query like that. But >>> the fact that somebody

Re: [HACKERS] oversight in EphemeralNamedRelation support

2017-10-09 Thread Julien Rouhaud
On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro wrote: > > I suppose we could consider moving the schemaname check into > getRTEForSpecialRelationType(), since otherwise both callers need to > do that (and as you discovered, one forgot). Thanks for the feedback.

[HACKERS] oversight in EphemeralNamedRelation support

2017-10-09 Thread Julien Rouhaud
Hi, Hugo Mercier (in Cc) reported me an error in a query, failing since pg10. Simple test case to reproduce: CREATE TABLE public.test (id integer); WITH test AS (select 42) INSERT INTO public.test SELECT * FROM test; which will fail with "relation "test" cannot be the target of a modifying

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

2017-09-26 Thread Julien Rouhaud
On Tue, Sep 26, 2017 at 2:56 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Sep 23, 2017 at 6:29 AM, Julien Rouhaud <rjuju...@gmail.com> wrote: >> That's true, but numCols, sortColdIdx etc are also used to display the >> sort key in an explain. If an ap

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

2017-09-23 Thread Julien Rouhaud
On Fri, Sep 22, 2017 at 11:09 PM, Robert Haas wrote: > During planning, *every* node has a list of pathkeys associated with > it which represent the presumed output ordering. You can support > ordered append paths without changing any data structures at all; it's > just a

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

2017-09-22 Thread Julien Rouhaud
On Fri, Sep 22, 2017 at 9:58 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 22, 2017 at 3:34 PM, Julien Rouhaud <rjuju...@gmail.com> wrote: >> PFA v3 of the patch, once again rebased and that now use all the newly >> available infrastructure. >> >

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

2017-09-22 Thread Julien Rouhaud
On Thu, Sep 21, 2017 at 11:13 AM, Julien Rouhaud <rjuju...@gmail.com> wrote: > On Thu, Sep 21, 2017 at 10:52 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> With 9140cf8269b0c4ae002b2748d93979d535891311, we store the >> RelOptInfos of partitions in

Re: [HACKERS] pg_stat_wal_write statistics view

2017-09-22 Thread Julien Rouhaud
Hello, On Wed, Sep 13, 2017 at 3:01 AM, Haribabu Kommi wrote: > I ran the latest performance tests with and without IO times, there is an > overhead involved with IO time calculation and didn't observe any > performance > overhead with normal stats. May be we can enable

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

2017-09-21 Thread Julien Rouhaud
On Thu, Sep 21, 2017 at 10:52 AM, Ashutosh Bapat wrote: > With 9140cf8269b0c4ae002b2748d93979d535891311, we store the > RelOptInfos of partitions in the RelOptInfo of partitioned table. For > range partitioned table without default partition, they are arranged >

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

2017-09-20 Thread Julien Rouhaud
On Thu, Aug 31, 2017 at 5:30 AM, Peter Eisentraut wrote: > On 3/20/17 11:03, Ronan Dunklau wrote: >>> Great idea. This is too late for v10 at this point, but please add it >>> to the next CommitFest so we don't forget about it. >> I know it is too late, and

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-30 Thread Julien Rouhaud
On 31/07/2017 01:47, Andres Freund wrote: > Julien, could you quickly verify that everything's good for you now too? > I just checked on current HEAD (cc9f08b6b813e30789100b6b34110d8be1090ba0) and everything's good for me. Thanks! -- Julien Rouhaud http://dalibo.com - http://dali

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-07-26 Thread Julien Rouhaud
On Wed, Jul 26, 2017 at 7:11 AM, Pavel Stehule wrote: > Hi > > I wrote a special pager for psql. Surely, this pager is not good for paging > of man pages. So is not good to set it as global pager. We can introduce new > env variable PSQL_PAGER for this purpose. It can

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-21 Thread Julien Rouhaud
; callbacks now are static. Thanks for working on it. Just in case, I reviewed the patch and didn't find any issue with it. -- Julien Rouhaud -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

2017-07-20 Thread Julien Rouhaud
On Thu, Jul 20, 2017 at 5:44 AM, Peter Geoghegan wrote: > On Wed, Jul 19, 2017 at 8:33 PM, Craig Ringer wrote: >> That's silly, so here's a patch to teach pageinspect how to decode infomasks >> to a human readable array of flag names. >> >> Example: >> >>

Re: [HACKERS] psql's \r broken since e984ef5861d

2017-07-19 Thread Julien Rouhaud
elevant discussion: > https://www.postgresql.org/message-id/flat/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90%40manitou-mail.org > Oh I see. Thanks a lot, sorry for the noise. -- Julien Rouhaud -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscr

Re: [HACKERS] psql's \r broken since e984ef5861d

2017-07-19 Thread Julien Rouhaud
On 20/07/2017 03:34, Tom Lane wrote: > Julien Rouhaud <julien.rouh...@dalibo.com> writes: >> Unless I miss something, \r isn't working anymore, > > Works for me. Please describe exactly what misbehavior you're seeing. > What libreadline or libedit version are you using

[HACKERS] psql's \r broken since e984ef5861d

2017-07-19 Thread Julien Rouhaud
Hello, Unless I miss something, \r isn't working anymore, since exec_command_print() fallback to display previous_buf if query_buf has been freed. Trivial patch to fix issue (free both buffers in exec_command_reset()) attached. Regards. -- Julien Rouhaud diff --git a/src/bin/psql/command.c b

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-18 Thread Julien Rouhaud
On 18/07/2017 14:04, Andres Freund wrote: > On 2017-07-17 23:04:43 +0200, Julien Rouhaud wrote: >> Is it v11 material or is there any chance to make it in v10? > > I think it'd make sense to apply the first to v10 (and earlier), and the > second to v11. I think this isn't a te

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-17 Thread Julien Rouhaud
11 material or is there any chance to make it in v10? -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] segfault in HEAD when too many nested functions call

2017-07-15 Thread Julien Rouhaud
On 15/07/2017 17:22, Tom Lane wrote: > Julien Rouhaud <julien.rouh...@dalibo.com> writes: >> Since b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 (Andres in Cc), if you >> write queries which result in infinite recursion (or just too many >> nested function calls), execution

[HACKERS] segfault in HEAD when too many nested functions call

2017-07-14 Thread Julien Rouhaud
to reproduce the issue if needed. Should I add a regression test based on it? -- Julien Rouhaud http://dalibo.com - http://dalibo.org segfault.sql Description: application/sql diff --git a/src/backend/executor/execSRF.c b/src/backend/executor/execSRF.c index 138e86ac67..9d257d4d88 100644 --- a/src

Re: [HACKERS] Pluggable storage

2017-06-25 Thread Julien Rouhaud
ely on that - it's possible people will > try to improve other index types (e.g. by adding similar compression to > other index types). That reminds me https://www.postgresql.org/message-id/55e4051b.7020...@postgrespro.ru where Anastasia proposed something similar. -- Julien Rouhaud

Re: [HACKERS] Typo in insert.sgml

2017-06-20 Thread Julien Rouhaud
On 20/06/2017 20:34, Peter Eisentraut wrote: > On 6/18/17 03:16, Julien Rouhaud wrote: >> Patch attached. > > This was not a typo, this was intentional. > Oh, sorry. I'm not a native english speaker, that sounded really weird. -- Julien Rouhaud http://dalibo.com -

Re: [HACKERS] Typo in drop_publication.sgml

2017-06-18 Thread Julien Rouhaud
On Sun, Jun 18, 2017 at 07:42:54PM +0200, Magnus Hagander wrote: > On Sun, Jun 18, 2017 at 8:46 AM, Julien Rouhaud <julien.rouh...@dalibo.com> > wrote: > > > Patch attached. > > > > Applied, thanks. > Thanks. -- Julien Rouhaud http://dalibo.com - http://dal

[HACKERS] Typo in insert.sgml

2017-06-18 Thread Julien Rouhaud
Patch attached. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml index 94dad00870..0e327e5b2e 100644 --- a/doc/src/sgml/ref/insert.sgml +++ b/doc/src/sgml/ref/insert.sgml @@ -228,7 +228,7 @@ INSERT INTO table_name

[HACKERS] Typo in drop_publication.sgml

2017-06-18 Thread Julien Rouhaud
Patch attached. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/doc/src/sgml/ref/drop_publication.sgml b/doc/src/sgml/ref/drop_publication.sgml index 517d142251..8e45a43982 100644 --- a/doc/src/sgml/ref/drop_publication.sgml +++ b/doc/src/sgml/ref/drop_publication.sgml

Re: [HACKERS] Typo in planstats.sgml

2017-06-17 Thread Julien Rouhaud
On 18/06/2017 01:03, Peter Eisentraut wrote: > On 6/17/17 05:00, Julien Rouhaud wrote: >> A "condition" is missing, patch attached. > > fixed > Thanks. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Typo in CREATE SUBSCRIPTION documentation

2017-06-17 Thread Julien Rouhaud
On Sat, Jun 17, 2017 at 10:24:32AM -0400, Peter Eisentraut wrote: > On 6/15/17 15:19, Julien Rouhaud wrote: > > Hi, > > > > I just found $SUBJECT, patch attached. > > fixed Thanks! -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers

[HACKERS] Typo in planstats.sgml

2017-06-17 Thread Julien Rouhaud
A "condition" is missing, patch attached. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/doc/src/sgml/planstats.sgml b/doc/src/sgml/planstats.sgml index 8caf297f85..838fcda6d2 100644 --- a/doc/src/sgml/planstats.sgml +++ b/doc/src/sgml/planstats.sgml @@ -50

[HACKERS] Typo in CREATE SUBSCRIPTION documentation

2017-06-15 Thread Julien Rouhaud
Hi, I just found $SUBJECT, patch attached. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml index 77bf87681b..3ca06fb3c3 100644 --- a/doc/src/sgml/ref/create_subscription.sgml +++ b/doc/src

Re: [HACKERS] Typo in BRIN documentation

2017-06-13 Thread Julien Rouhaud
On Tue, Jun 13, 2017 at 11:29:30AM -0400, Peter Eisentraut wrote: > On 6/13/17 07:53, Julien Rouhaud wrote: > > I just found this typo while doing french translation, patch attached. > > fixed > Thanks ! -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgs

[HACKERS] Typo in BRIN documentation

2017-06-13 Thread Julien Rouhaud
Hi, I just found this typo while doing french translation, patch attached. Regards. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml index ad11109775..8dcc29925b 100644 --- a/doc/src/sgml/brin.sgml +++ b/doc/src/sgml/brin.sgml

Re: [HACKERS] Do we need the gcc feature "__builtin_expect" to promote the branches prediction?

2017-06-02 Thread Julien Rouhaud
=3awbh8cjwtp9zxeo...@mail.gmail.com BTW Andres added support for likely/unlikely in aa3ca5e3dd6, but its usage is still really limited. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CTE inlining

2017-05-04 Thread Julien Rouhaud
This change will be welcome for a large number of >> queries, but forced materialization is a real need and I use it often. >> This comes off as a very reasonable compromise in my opinion unless it >> requires major coding gymnastics to implement. >> > > +1 to this > +1 too -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Column rename in an extension update script

2017-05-02 Thread Julien Rouhaud
al one) fixes this issue for me, but I have no idea if this is the right fix. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_stat_wal_write statistics view

2017-03-15 Thread Julien Rouhaud
ite_time = 0; + } (and similar ones) The brackets seem unnecessary. I marked the commitfest entry as waiting on author. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscr

[HACKERS] Preserving param location

2017-03-11 Thread Julien Rouhaud
, which among other thing is used to regenerate query string from a pgss normalized query, thus needing the original param location). Is this something we want to get fixed? If yes, attached is a simple patch for that. Regards. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git

Re: [HACKERS] [PATCH] SortSupport for macaddr type

2017-03-02 Thread Julien Rouhaud
putting it into > master? I think picking the value with unused_oids as you dd is the right thing to do. As Robert said, if this oid is used in another patch in the meantime, updating it at commit time is not a big deal. Moreover, this patch will require a catversion bump, which is meant to be done

Re: [HACKERS] [PATCH] SortSupport for macaddr type

2017-02-25 Thread Julien Rouhaud
rough pgindent. > Thanks also, no more issue here. > Let me know if you have any further feedback and/or > suggestions. Thanks! One last thing, I noticed that you added: +static int macaddr_internal_cmp(macaddr *a1, macaddr *a2); but the existing function is declared as static

Re: [HACKERS] Rename max_parallel_degree?

2016-12-04 Thread Julien Rouhaud
eds review" state. Please feel free to update > > the status. > > I have committed this patch. And updated the status, too! Thanks! -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make cha

[HACKERS] Overlook in 2bd9e412?

2016-10-28 Thread Julien Rouhaud
It looks like pq_putmessage_hook and pq_flush_hook were meant for development purpose and not supposed to be committed. Attached patch remove them. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h index 18052cb..5fac817

Re: [HACKERS] issue with track_commit_timestamp and server restart

2016-10-24 Thread Julien Rouhaud
On 24/10/2016 06:58, Craig Ringer wrote: > On 22 October 2016 at 19:51, Julien Rouhaud <julien.rouh...@dalibo.com> wrote: >> I just noticed that if track_commit_timestamp is enabled, the >> oldestCommitTsXid and newestCommitTsXid don't persist after a server >>

[HACKERS] issue with track_commit_timestamp and server restart

2016-10-22 Thread Julien Rouhaud
nd disabling track_commit_timestamp, and everything seemed to work as intended. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c index a8d275f..7746578 100644 --- a/src/backend/access/transam/commit_ts.c +++ b

Re: [HACKERS] Multiple psql history files

2016-10-18 Thread Julien Rouhaud
tion because there are commands that cannot or should not be > used by different connections. > To solve this, psql could keep a separate command history file for each > connection. You can already do this, for instance in your .psqlrc: \set HISTFILE ~/.psql_history- :HOST - :PORT - :DBNAME

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Julien Rouhaud
On 16/10/2016 11:21, Craig Ringer wrote: > On 16 Oct. 2016 14:31, Julien Rouhaud wrote: >> >> On 16/10/2016 02:38, Jim Nasby wrote: >> > On 10/10/16 12:58 AM, Julien Rouhaud wrote: >> >> Unless you mean deparsing the Query instead of using raw source >

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Julien Rouhaud
any major difficulty here. I still hope we can find a way to store the fully qualified objects name in the normalized query instead. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-16 Thread Julien Rouhaud
On 16/10/2016 02:38, Jim Nasby wrote: > On 10/10/16 12:58 AM, Julien Rouhaud wrote: >> Unless you mean deparsing the Query instead of using raw source text? I >> think that would solve this issue (and also the other issue when >> multiple queries are submitted at once, y

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Julien Rouhaud
On 12/10/2016 14:32, Alvaro Herrera wrote: > Julien Rouhaud wrote: > >> and you can instead make macaddr64 support both format, and provide a >> macaddr::macaddr64 cast > > Having macaddr64 support both formats sounds nice, but how does it work? > Will we have to

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2016-10-12 Thread Julien Rouhaud
eal. I'm really not a fan of that idea. > > Just use macaddr64 if you want wide MACs. > > +1 and you can instead make macaddr64 support both format, and provide a macaddr::macaddr64 cast -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-09 Thread Julien Rouhaud
On 10/10/2016 05:00, Jim Nasby wrote: > On 10/7/16 4:39 AM, Julien Rouhaud wrote: >> I see two ways of fixing this. First one would be to store normalized >> queries while fully qualifiying the relation's names. After a quick look >> this can't be done without storing at l

[HACKERS] pg_stat_statements and non default search_path

2016-10-07 Thread Julien Rouhaud
should fix, and if yes is any of this acceptable, or does someone see another way to solve this problem? Regards. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Rename max_parallel_degree?

2016-10-04 Thread Julien Rouhaud
On 03/10/2016 21:27, Robert Haas wrote: > On Fri, Sep 30, 2016 at 12:23 PM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> I've already fixed every other issues mentioned upthread, but I'm facing >> a problem for this one. Assuming that the bgworker classes are su

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

2016-09-30 Thread Julien Rouhaud
On 30/09/2016 21:12, David Fetter wrote: > On Fri, Sep 30, 2016 at 06:37:17PM +0200, Julien Rouhaud wrote: >> On 30/09/2016 05:23, Thomas Munro wrote: >>> >>> It would be really nice to be able to set this to 'Ready for >>> Committer' in this CF. Do yo

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

2016-09-30 Thread Julien Rouhaud
ch, and noticed that only plain DELETE and UPDATE commands are handled. Is it intended that writable CTE without WHERE clauses are not detected by this extension? I personally think that wCTE should be handled (everyone can forget a WHERE clause), but if not it should at least be documented. -- Juli

Re: [HACKERS] Rename max_parallel_degree?

2016-09-30 Thread Julien Rouhaud
ry to implement it. I've already fixed every other issues mentioned upthread, but I'm facing a problem for this one. Assuming that the bgworker classes are supposed to be mutually exclusive, I don't see a simple and clean way to add such a check in SanityCheckBackgroundWorker(). Am I missing something

Re: [HACKERS] Issue with bgworker, SPI and pgstat_report_stat

2016-09-30 Thread Julien Rouhaud
On 28/09/2016 18:46, Robert Haas wrote: > > Everybody seems happy with this fix for a first step, so I've > committed it and back-patched it to 9.3. > Thanks! -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

Re: [HACKERS] Rename max_parallel_degree?

2016-09-16 Thread Julien Rouhaud
After some more thinking, it looks like a reorder here won't have any impact. I'll remove it, unless Amit has an objection about it. > + {"max_parallel_workers", PGC_USERSET, RESOURCES_ASYNCHRONOUS, > + gettext_noop("Sets the maximum number of > p

Re: [HACKERS] [PATCH] SortSupport for macaddr type

2016-09-14 Thread Julien Rouhaud
mention specific little-endian handling * "There will be two bytes of zero padding on the least significant end" "least significant bits" would be better * This patch will trigger quite a lot modifications after a pgindent run. Could you try to run pgindent on mac.c before sen

Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

2016-09-05 Thread Julien Rouhaud
On 05/09/2016 11:55, Julien Rouhaud wrote: > On 20/06/2016 06:28, Thomas Munro wrote: >> On Mon, Jun 20, 2016 at 3:43 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: >>> On 18 June 2016 at 11:28, Thomas Munro <thomas.mu...@enterprisedb.com> >>> wrote: >>

Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

2016-09-05 Thread Julien Rouhaud
tches are pretty straightforward, so I don't have much to say. My only remark is on following comment: + * LWLockHeldByMeInMode - test whether my process holds a lock in mode X Maybe something like "test whether my process holds a lock in given mode" would be better? Otherwise, I think they're rea

Re: [HACKERS] LSN as a recovery target

2016-08-20 Thread Julien Rouhaud
om many places, but it may be useful for some people. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small issues in syncrep.c

2016-08-10 Thread Julien Rouhaud
rep code, so I don't >> see any reason to keep the code as it currently is in 9.5/9.6. >> >> Any objections to backpatching this to 9.5 and 9.6? > > None from here. > same here. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers maili

[HACKERS] Small issues in syncrep.c

2016-08-09 Thread Julien Rouhaud
est to try to retrieve again syncRepState. Patch attached to fix both small issues, present since 9.5. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c index 67249d8..c3e11b8 100644 --- a/src/backend/replicat

Re: [HACKERS] Notice lock waits

2016-08-05 Thread Julien Rouhaud
ew value for log_lock_waits, like "interactive". If switching this GUC from bool to enum is not acceptable or allowing to see blocking PID for anyone is an issue, then maybe adding a new GUC to say to also send a NOTICE instead? -- Julien Rouhaud http://dalibo.com - http://dalibo.org -

Re: [HACKERS] [PROPOSAL] timestamp informations to pg_stat_statements

2016-07-17 Thread Julien Rouhaud
oes that, assuming you're using a 9.4+ server. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Issue with bgworker, SPI and pgstat_report_stat

2016-07-10 Thread Julien Rouhaud
On 08/07/2016 01:53, Michael Paquier wrote: > On Fri, Jul 8, 2016 at 3:06 AM, Andres Freund <and...@anarazel.de> wrote: >> On 2016-07-07 14:04:36 -0400, Robert Haas wrote: >>> On Thu, Jul 7, 2016 at 1:52 PM, Julien Rouhaud >>> <julien.rouh...@dalibo.com> wrot

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

2016-07-10 Thread Julien Rouhaud
ot;fully" logs out. > AFAIK it's only the case if the user is not a system user, and postgres user should be (at least with community packages). See https://github.com/systemd/systemd/issues/2039 -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers maili

[HACKERS] Issue with bgworker, SPI and pgstat_report_stat

2016-07-07 Thread Julien Rouhaud
for this bgworker and I suppose a lot of other one) is also affected. If yes, I think at least worker_spi should be fixed (patched attached). Regards. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/test/modules/worker_spi/worker_spi.c b/src/test/modules/worker_spi

Re: [HACKERS] Rename max_parallel_degree?

2016-06-29 Thread Julien Rouhaud
On 29/06/2016 08:51, Amit Kapila wrote: > On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> Or should we allow setting it to -1 for instance to disable the limit? >> > > By disabling the limit, do you mean to say that only >

Re: [HACKERS] Rename max_parallel_degree?

2016-06-29 Thread Julien Rouhaud
On 29/06/2016 06:29, Amit Kapila wrote: > On Wed, Jun 29, 2016 at 2:57 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> >> Thanks a lot for the help! >> >> PFA v6 which should fix all the issues mentioned. > > Couple of minor suggestions.

Re: [HACKERS] Rename max_parallel_degree?

2016-06-28 Thread Julien Rouhaud
On 28/06/2016 04:44, Amit Kapila wrote: > On Mon, Jun 27, 2016 at 10:35 PM, Julien Rouhaud >> >> There's already a pg_memory_barrier() call in >> BackgroundWorkerStateChange(), to avoid reordering the notify_pid load. >> Couldn't we use it to also make sure t

Re: [HACKERS] Rename max_parallel_degree?

2016-06-27 Thread Julien Rouhaud
ad barrier here, so that this check doesn't get >> reordered with the for loop below it. You mean between the end of this block and the for loop? (Sorry, I'm not at all familiar with the pg_barrier mechanism). >> Also, see if you find the code >> more readable by moving the after && part of check to next line. I think I'll just pgindent the file. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Rename max_parallel_degree?

2016-06-26 Thread Julien Rouhaud
On 26/06/2016 08:37, Amit Kapila wrote: > On Sat, Jun 25, 2016 at 2:27 PM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >>> >> >> It's better thanks. Should we document somewhere the link between this >> parameter and custom dynamic background work

Re: [HACKERS] Rename max_parallel_degree?

2016-06-25 Thread Julien Rouhaud
On 25/06/2016 09:33, Amit Kapila wrote: > On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> >> Attached v4 implements the design you suggested, I hope everything's ok. >> > > Few review comments: > Thanks

Re: [HACKERS] Rename max_parallel_degree?

2016-06-15 Thread Julien Rouhaud
On 15/06/2016 18:14, Julien Rouhaud wrote: > On 15/06/2016 17:49, Robert Haas wrote: >> On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud >> <julien.rouh...@dalibo.com> wrote: >>>> I don't entirely like the new logic in >>>> RegisterDynamicBackgrou

Re: [HACKERS] Rename max_parallel_degree?

2016-06-15 Thread Julien Rouhaud
On 15/06/2016 17:49, Robert Haas wrote: > On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >>> I don't entirely like the new logic in >>> RegisterDynamicBackgroundWorker. >> >>> I wonder if we can't drive this off &

Re: [HACKERS] Rename max_parallel_degree?

2016-06-14 Thread Julien Rouhaud
On 14/06/2016 04:09, Robert Haas wrote: > On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> Agreed, and fixed in attached v3. > > I don't entirely like the new logic in > RegisterDynamicBackgroundWorker. I'm not that happy with it

Re: [HACKERS] Rename max_parallel_degree?

2016-06-13 Thread Julien Rouhaud
On 13/06/2016 03:16, Robert Haas wrote: > On Sat, Jun 11, 2016 at 6:24 PM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> On 11/06/2016 23:37, Julien Rouhaud wrote: >>> On 09/06/2016 16:04, Robert Haas wrote: >>>> There remains only the task of addi

Re: [HACKERS] Rename max_parallel_degree?

2016-06-11 Thread Julien Rouhaud
On 11/06/2016 23:37, Julien Rouhaud wrote: > On 09/06/2016 16:04, Robert Haas wrote: >> >> OK, I pushed this after re-reviewing it and fixing a number of >> oversights. There remains only the task of adding max_parallel_degree >> as a system-wide limit (as opposed

Re: [HACKERS] Rename max_parallel_degree?

2016-06-11 Thread Julien Rouhaud
PFA a patch to fix this open item. I used the GUC name provided in the 9.6 open item page (max_parallel_workers), with a default value of 4. Value 0 is another way to disable parallel query. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/doc/src/sgml/config.sgml b/doc/src/

[HACKERS] max_worker_processes missing some documentation

2016-05-02 Thread Julien Rouhaud
I noticed that postgresql.conf.sample doesn't say that changing max_worker_processes requires a restart. Patch attached. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index

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

2016-04-29 Thread Julien Rouhaud
On 29/04/2016 18:05, Tom Lane wrote: > Julien Rouhaud <julien.rouh...@dalibo.com> writes: >> The segfault is caused by quals_match_foreign_key() calling get_leftop() >> and get_rightop() on a ScalarArrayOpExpr node. > >> Reordering the common fields o

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

2016-04-29 Thread Julien Rouhaud
the get_*op() work with either (as in attached patch) fixes the issue. I'm not sure that assuming this compatibility is the right way to fix this though. -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h index 1ffc0a1..dffe129

Re: [HACKERS] Memory leak in GIN index build

2016-04-18 Thread Julien Rouhaud
noted that some of the coding-rule > violations seem to be new in 9.5, so the problems may be less severe in > 9.4 --- the memory leak definitely exists there, though. > -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Memory leak in GIN index build

2016-04-16 Thread Julien Rouhaud
On 16/04/2016 20:45, Tom Lane wrote: > Julien Rouhaud <julien.rouh...@dalibo.com> writes: > >> Also, in dataPlaceToPageLeaf() and ginVacuumPostingTreeLeaf(), shouldn't >> the START_CRIT_SECTION() calls be placed before the xlog code? > > Yeah, they should. Evident

[HACKERS] Memory leak in GIN index build

2016-04-16 Thread Julien Rouhaud
, in dataPlaceToPageLeaf() and ginVacuumPostingTreeLeaf(), shouldn't the START_CRIT_SECTION() calls be placed before the xlog code? Regards. -- Julien Rouhaud http://dalibo.com - http://dalibo.org generate_data.pl Description: Perl program -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] Memory leak when querying GIN indexes

2016-04-14 Thread Julien Rouhaud
. I'm not at all familiar with GIN code, but naive attached patch seems to fix the issue and not break anything. I can reproduce this issue up to 9.4. Regards -- Julien Rouhaud http://dalibo.com - http://dalibo.org diff --git a/src/backend/access/gin/ginget.c b/src/backend/access/gin/ginget.c index b

Re: [HACKERS] Choosing parallel_degree

2016-04-13 Thread Julien Rouhaud
On 13/04/2016 19:17, Robert Haas wrote: > On Tue, Apr 12, 2016 at 6:31 PM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> On 11/04/2016 22:53, Julien Rouhaud wrote: >>> On 11/04/2016 17:44, Robert Haas wrote: >>>> We should probably add

Re: [HACKERS] Choosing parallel_degree

2016-04-12 Thread Julien Rouhaud
On 11/04/2016 22:53, Julien Rouhaud wrote: > On 11/04/2016 17:44, Robert Haas wrote: >> >> We should probably add the number of workers actually obtained to the >> EXPLAIN ANALYZE output. That's been requested before. >> > > If it's not too late for 9.6, it woul

Re: [HACKERS] Choosing parallel_degree

2016-04-11 Thread Julien Rouhaud
On 11/04/2016 17:44, Robert Haas wrote: > On Mon, Apr 11, 2016 at 11:27 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> On 11/04/2016 15:56, tushar wrote: >>> >>> I am assuming parallel_degree=0 is as same as not using it , i.e >>> cre

Re: [HACKERS] Choosing parallel_degree

2016-04-11 Thread Julien Rouhaud
arallel_degree =262143; > SET > postgres=# > > postgres=# explain analyze verbose select * from abd where n<=1; > ERROR: requested shared memory size overflows size_t > > if we remove the analyze keyword then query running successfully. > > Expected = Is it not better to throw the error at the time of setting > max_parallel_degree, if not supported ? +1 -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Choosing parallel_degree

2016-04-06 Thread Julien Rouhaud
On 06/04/2016 07:38, Amit Kapila wrote: > On Tue, Apr 5, 2016 at 11:55 PM, Julien Rouhaud >> >> In alter_table.sgml, I didn't comment the lock level needed to modify >> parallel_degree since it requires an access exclusive lock for now. >> While thinking about it, I thi

Re: [HACKERS] Choosing parallel_degree

2016-04-05 Thread Julien Rouhaud
et '(' which means with rel->pages. Refer multiline condition in > near by code. Or you can run pgindent. I ran pgindent, fixed. > B. The comment above this condition needs slight adjustment as per new > condition. > Also fixed. > 4. > +intparallel_degree; /* max num

Re: [HACKERS] Choosing parallel_degree

2016-04-04 Thread Julien Rouhaud
On 04/04/2016 17:03, Julien Rouhaud wrote: > On 04/04/2016 08:55, Amit Kapila wrote: > > Thanks for the review! > >> Few comments: >> 1. >> + limited according to the >> >> A. typo. >>/gux-max-parallel-degree/guc-max-parallel-degree &

  1   2   >