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.
Regards.
--
Sent via
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. I wo
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
+++ b/src/backend/
On Fri, Oct 20, 2017 at 3:44 PM, Robert Haas wrote:
> On Thu, Oct 19, 2017 at 2:11 AM, Julien Rouhaud wrote:
>> I agree, and I'm perfectly fine with adding a comment around pgssHashKey.
>>
>> PFA a patch to warn about the danger.
>
> Committed a somewhat differen
On Thu, Oct 19, 2017 at 1:08 AM, Michael Paquier
wrote:
> On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas wrote:
>> On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud wrote:
>>> WIth current pgssHashKey definition, there shouldn't be padding bits,
>>> so it should be
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 (pgbench and some custom
>>> queries) I have not spotted issues. If the final
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 ran into it when v10 has been out for barely
>>> a week suggests that p
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. That was my first idea, but I assum
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 stat
On Tue, Sep 26, 2017 at 2:56 PM, Robert Haas wrote:
> On Sat, Sep 23, 2017 at 6:29 AM, Julien Rouhaud wrote:
>> That's true, but numCols, sortColdIdx etc are also used to display the
>> sort key in an explain. If an append can return sorted data, it
>> should also di
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 matter of putting pathke
On Fri, Sep 22, 2017 at 9:58 PM, Robert Haas wrote:
> On Fri, Sep 22, 2017 at 3:34 PM, Julien Rouhaud wrote:
>> PFA v3 of the patch, once again rebased and that now use all the newly
>> available infrastructure.
>>
>> I also added a check that a sorted append can'
On Thu, Sep 21, 2017 at 11:13 AM, Julien Rouhaud wrote:
> 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 partition
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 the IO stats only in the
>
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
> in the ascending order of partition
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 thought that it was too early to add it
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 - h
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 work similar like
> PSQL_EDIT
llbacks 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
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:
>>
>> SELECT t_infomask, t_infomask2, flags
>>
the relevant 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 s
On 20/07/2017 03:34, Tom Lane wrote:
> Julien Rouhaud 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?
>
I have libreadlin
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/comman
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&#
-3.70]
Is it v11 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
On 15/07/2017 17:22, Tom Lane wrote:
> Julien Rouhaud writes:
>> Since b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 (Andres in Cc), if you
>> write queries which result in infinite recursion (or just too many
>> nested function calls), execution ends with segfault instead of
le 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
---
sure we can simply rely 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 simi
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.
On Sun, Jun 18, 2017 at 07:42:54PM +0200, Magnus Hagander wrote:
> On Sun, Jun 18, 2017 at 8:46 AM, Julien Rouhaud
> wrote:
>
> > Patch attached.
> >
>
> Applied, thanks.
>
Thanks.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgs
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
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
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
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
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
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
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
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
p9zxeo...@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
y
>>> don't care and they remain happy because of the other improvements) or
>>> notably so, in which case they can easily figure where to add the
>>> MATERIALIZED option and regain the original performance.
>>
>> +1 for option 1. This change will be welc
ne) 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
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
, 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 a
e (if necessary) as they're 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
catver
l! I've run the new version through 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 existi
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 changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
On 24/10/2016 06:58, Craig Ringer wrote:
> On 22 October 2016 at 19:51, Julien Rouhaud wrote:
>> I just noticed that if track_commit_timestamp is enabled, the
>> oldestCommitTsXid and newestCommitTsXid don't persist after a server
>> restart, so you can't ask for
and a replica, enabling and
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/
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
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
> tex
re's 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
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
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
t 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 list (pgsql-hackers@
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 stori
Is it something that we 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 t
On 03/10/2016 21:27, Robert Haas wrote:
> On Fri, Sep 30, 2016 at 12:23 PM, Julien Rouhaud
> 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 supposed
>> to be
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
e patch, 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.
I'll
try 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 SanityCheckBackgroundWork
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@p
matter here?
>
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(
addr_abbrev_convert() doesn't 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
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 wrote:
>>> On 18 June 2016 at 11:28, Thomas Munro
>>> wrote:
>>>> Several times now when reading, debugging and writing co
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 ready for committer.
--
Julien Rouhaud
http
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
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 mailing list
w unneeded
test 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/b
en if
it's on.
Maybe a new 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.
t this is the job of a tool that aggregates things from
> pg_stat_statements. It's unfortunate that there isn't a good
> third-party tool that does that, but there is nothing that prevents
> it.
>
FWIW there's https://github.com/dalibo/powa-archivist which does that,
as
On 08/07/2016 01:53, Michael Paquier wrote:
> On Fri, Jul 8, 2016 at 3:06 AM, Andres Freund wrote:
>> On 2016-07-07 14:04:36 -0400, Robert Haas wrote:
>>> On Thu, Jul 7, 2016 at 1:52 PM, Julien Rouhaud
>>> wrote:
>>>> Should a bgworker modifing da
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 mail
e 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/worke
On 29/06/2016 08:51, Amit Kapila wrote:
> On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud
> 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
> max_parallel_workers_per_gather
On 29/06/2016 06:29, Amit Kapila wrote:
> On Wed, Jun 29, 2016 at 2:57 AM, Julien Rouhaud
> wrote:
>>
>> Thanks a lot for the help!
>>
>> PFA v6 which should fix all the issues mentioned.
>
> Couple of minor suggestions.
>
> - . Note t
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 m
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
On 26/06/2016 08:37, Amit Kapila wrote:
> On Sat, Jun 25, 2016 at 2:27 PM, Julien Rouhaud
> wrote:
>>>
>>
>> It's better thanks. Should we document somewhere the link between this
>> parameter and custom dynamic background workers or is it pretty
>> s
On 25/06/2016 09:33, Amit Kapila wrote:
> On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud
> wrote:
>>
>> Attached v4 implements the design you suggested, I hope everything's ok.
>>
>
> Few review comments:
>
Thanks for the review.
> 1.
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
>> wrote:
>>>> I don't entirely like the new logic in
>>>> RegisterDynamicBackgroundWorker.
>>>
>>
On 15/06/2016 17:49, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud
> wrote:
>>> I don't entirely like the new logic in
>>> RegisterDynamicBackgroundWorker.
>>
>>> I wonder if we can't drive this off
>>> of a couple
On 14/06/2016 04:09, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud
> wrote:
>> Agreed, and fixed in attached v3.
>
> I don't entirely like the new logic in
> RegisterDynamicBackgroundWorker.
I'm not that happy with it too. We can avoid it
On 13/06/2016 03:16, Robert Haas wrote:
> On Sat, Jun 11, 2016 at 6:24 PM, Julien Rouhaud
> 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 adding max_parallel_degree
>>>
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
>
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
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
On 29/04/2016 18:05, Tom Lane wrote:
> Julien Rouhaud writes:
>> The segfault is caused by quals_match_foreign_key() calling get_leftop()
>> and get_rightop() on a ScalarArrayOpExpr node.
>
>> Reordering the common fields of OpExpr and ScalarArrayOpExpr at the
>>
ttached 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 100644
--- a/src/includ
e that happened in 9.5. I also 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
On 16/04/2016 20:45, Tom Lane wrote:
> Julien Rouhaud writes:
>
>> Also, in dataPlaceToPageLeaf() and ginVacuumPostingTreeLeaf(), shouldn't
>> the START_CRIT_SECTION() calls be placed before the xlog code?
>
> Yeah, they should. Evidently somebody kluged it to av
n a patch if
needed.
Also, 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-
torState memory context.
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/
On 13/04/2016 19:17, Robert Haas wrote:
> On Tue, Apr 12, 2016 at 6:31 PM, Julien Rouhaud
> wrote:
>> 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 t
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.
On 11/04/2016 17:44, Robert Haas wrote:
> On Mon, Apr 11, 2016 at 11:27 AM, Julien Rouhaud
> wrote:
>> On 11/04/2016 15:56, tushar wrote:
>>>
>>> I am assuming parallel_degree=0 is as same as not using it , i.e
>>> create table fok2(n int) with (parallel_de
)); analyze
> abd; vacuum abd;
> INSERT 0 100
> ANALYZE
>
> postgres=# set max_parallel_degree =262;
> ERROR: 262 is outside the valid range for parameter
> "max_parallel_degree" (0 .. 262143)
>
> postgres=# set max_parallel_degree =262143
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,
ine after
> bracket '(' 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.
> +
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 - 100 of 174 matches
Mail list logo
