Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism

On Sat, Jun 3, 2017 at 9:34 PM, Andres Freund wrote: > Hi, > > On 2017-06-03 17:40:08 +0530, Amit Kapila wrote: >> The standard_planner check is sufficient to not generate parallel >> plans for such statements, but it won't prevent if such commands >> (which shouldn't be

Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour

On Sun, Jun 4, 2017 at 10:11 AM, Tom Lane wrote: > Amit Kapila writes: >> In order to avoid losing track of this patch, I think it is better to >> add it in open items list for 10. > > This is an entirely new feature, not a bug fix, and thus certainly

Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour

Amit Kapila writes: > In order to avoid losing track of this patch, I think it is better to > add it in open items list for 10. This is an entirely new feature, not a bug fix, and thus certainly not an open item for v10. Please stick it in the next commitfest, instead.

Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour

On Thu, Jun 1, 2017 at 6:40 PM, Alexander Korotkov wrote: > On Wed, May 31, 2017 at 7:18 PM, Alexander Korotkov > wrote: >> >>> >>> Don't like either of those particularly, but what about just targeting >>> a column by column number,

Re: [HACKERS] Default Partition for Range

On Fri, Jun 2, 2017 at 5:48 PM, Robert Haas wrote: > On Fri, Jun 2, 2017 at 8:09 AM, Amit Kapila wrote: >> I think if you have found spelling mistakes unrelated to this patch, >> then it is better to submit those as a separate patch in a new

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

On Sun, Jun 4, 2017 at 10:41 AM, Kevin Grittner wrote: > On Fri, Jun 2, 2017 at 8:46 PM, Thomas Munro > wrote: > >> So, afterTriggers.query_stack is used to handle the reentrancy that >> results from triggers running further statements that might

Re: [HACKERS] Extra Vietnamese unaccent rules

On Mon, May 29, 2017 at 10:47 AM, Thomas Munro wrote: >> [Quoting Michael] >>> Actually, with the recent work that has been done with >>> unicode_norm_table.h which has been to transpose UnicodeData.txt into >>> user-friendly tables, shouldn't the python script of

Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT

On 2017-06-03 18:23:33 -0400, Tom Lane wrote: > Attached is a proposed patch that closes off this problem. I've tested > it to the extent that it blocks Albe's example and passes check-world. Cool. > I'm unsure whether to back-patch or not; the main argument for not doing > so is that if any

Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT

On Sun, Jun 4, 2017 at 7:23 AM, Tom Lane wrote: > I'm unsure whether to back-patch or not; the main argument for not doing > so is that if any extensions are calling DefineIndex() directly, this > would be an API break for them. Given what a weird case this is, I'm not > sure

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

On Fri, Jun 2, 2017 at 8:46 PM, Thomas Munro wrote: > So, afterTriggers.query_stack is used to handle the reentrancy that > results from triggers running further statements that might fire > triggers. It isn't used for dealing with extra ModifyTable nodes that >

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 4:33 PM, Kuntal Ghosh wrote: > On Sat, Jun 3, 2017 at 2:14 AM, Petr Jelinek > wrote: >> However, I am not sure about the bgw_name_extra. I think I would have >> preferred keeping full bgw_name field which would be

Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT

I wrote: > Andres Freund writes: >> Hm, strategically sprinkled CheckTableNotInUse() might do the trick? > +1. We can't reasonably make it work: the outer query already has its > list of indexes that need to be inserted into. Also, if you try to > make the index via ALTER

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Sat, Jun 3, 2017 at 1:51 AM, Mengxing Liu wrote: > I tried 30 cores. But the CPU utilization is about 45%~70%. > How can we distinguish where the problem is? Is disk I/O or Lock? A simple way is to run `vmstat 1` for a bit during the test. Can you post a

Re: [HACKERS] Tweaking tab completion for some backslash commands

Masahiko Sawada writes: > Attached patch tweaks tab completion for some backslash commands. Pushed, thanks! regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Create subscription with `create_slot=false` and incorrect slot name

> On 26 May 2017 at 23:05, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > On 5/25/17 19:16, Petr Jelinek wrote: > >> The reported error is just one of many errors that can happen when DROP > >> SUBSCRIPTION tries to drop the slot (doens't exist, still active, no > >> permission,

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On 6/2/17 14:52, Peter Eisentraut wrote: > On 5/24/17 15:14, Petr Jelinek wrote: >> All the locking works just fine the way it is in master. The issue with >> deadlock with apply comes from the wrong handling of the SIGTERM in the >> apply (we didn't set InterruptPending). I changed the SIGTERM

Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism

Hi, On 2017-06-03 17:40:08 +0530, Amit Kapila wrote: > The standard_planner check is sufficient to not generate parallel > plans for such statements, but it won't prevent if such commands > (which shouldn't be executed by parallel workers) are present in > functions. Consider a hypothetical case

Re: [HACKERS] Extra Vietnamese unaccent rules

On May 30, 29 Heisei, at 00:22, Dang Minh Huong wrote: unaccent.patch Description: Binary data On May 29, 29 Heisei, at 10:47, Thomas Munro wrote:On Sun, May 28, 2017 at 7:55 PM, Dang Minh Huong wrote:Thanks for reporting

Re: [HACKERS] logical replication - still unstable after all these months

On Fri, Jun 2, 2017 at 4:10 PM, Petr Jelinek wrote: > > While I was testing something for different thread I noticed that I > manage transactions incorrectly in this patch. Fixed here, I didn't test > it much yet (it takes a while as you know :) ). Not sure if it's

Re: [HACKERS] [POC] hash partitioning

On Thu, May 25, 2017 at 9:59 AM, amul sul wrote: > On Mon, May 22, 2017 at 2:23 PM, amul sul wrote: >> >> Updated patch attached. Thanks a lot for review. >> > Minor fix in the document, PFA. Patch need rebase --- Function header is not consistent with

Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)

On Fri, Jun 2, 2017 at 7:20 PM, Petr Jelinek wrote: > On 02/06/17 15:37, Amit Kapila wrote: >> >> No, it is to avoid calling free of memory which is not reserved on >> retry. See the comment: >> + * On the first try, release memory region reservation that was made

Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism

On Thu, Jun 1, 2017 at 10:16 PM, Andres Freund wrote: > On 2017-06-01 21:37:56 +0530, Amit Kapila wrote: >> On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund wrote: >> > On 2017-06-01 21:23:04 +0530, Amit Kapila wrote: >> >> On a related note, I think it might

Re: [HACKERS] Adding support for Default partition in partitioning

Here's some detailed review of the code. @@ -1883,6 +1883,15 @@ heap_drop_with_catalog(Oid relid) if (OidIsValid(parentOid)) { /* + * Default partition constraints are constructed run-time from the + * constraints of its siblings(basically by negating them), so

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 8:53 AM, Peter Eisentraut wrote: > On 6/2/17 15:08, Peter Eisentraut wrote: >> On 5/30/17 23:10, Peter Eisentraut wrote: >>> Here is a proposed solution that splits bgw_name into bgw_type and >>> bgw_name_extra. bgw_type shows up in

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 2:14 AM, Petr Jelinek wrote: > On 02/06/17 21:05, Peter Eisentraut wrote: >> On 6/2/17 02:31, Masahiko Sawada wrote: >>> I'd say current patch makes the user difficult to >>> distinguish between apply worker and table sync worker. >> >> We

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

> -Original Messages- > From: "Kevin Grittner" > Sent Time: 2017-06-03 01:44:16 (Saturday) > To: "Alvaro Herrera" > Cc: "Mengxing Liu" , > "pgsql-hackers@postgresql.org" >

Re: [HACKERS] Range Merge Join v1

2017-06-02 19:42 GMT+05:00 Jeff Davis : > On Tue, May 30, 2017 at 11:44 PM, Andrew Borodin wrote: >> 1. Are there any types, which could benefit from Range Merge and are >> not covered by this patch? > > I thought about this for a while, and the only thing

Re: [HACKERS] walsender & parallelism

On 2017-06-02 22:12:46 -0700, Noah Misch wrote: > On Fri, Jun 02, 2017 at 11:27:55PM -0400, Peter Eisentraut wrote: > > On 5/31/17 23:54, Peter Eisentraut wrote: > > > On 5/29/17 22:01, Noah Misch wrote: > > >> On Tue, May 23, 2017 at 01:45:59PM -0400, Andres Freund wrote: > > >>> On May 23, 2017