Re: segmentation fault in pg head with SQL function.

On Fri, Mar 16, 2018 at 11:35:13AM +0530, Prabhat Sahu wrote: > I found a segmentation fault on pg master Head with below steps and > stacktrace. > > postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID > LANGUAGE SQL > AS $$ > select 10; > $$; > CREATE FUNCTION > > postgres=# select

Re: [HACKERS] plpgsql - additional extra checks

2018-03-16 2:46 GMT+01:00 Tomas Vondra : > On 03/04/2018 07:07 PM, Pavel Stehule wrote: > > > > ... > > > > I am sending updated patch with Tomas changes > > > > Seems 2cf8c7aa48 broke this patch, as it tweaked a number of regression > tests. Other than that, I think

Re: missing support of named convention for procedures

2018-03-15 22:13 GMT+01:00 Pavel Stehule : > Hi > > create or replace procedure proc2(in a int, in b int) > as $$ > begin > a := a * 10; > b := b * 10; > end; > $$ language plpgsql; > > postgres=# call proc2(a => 10,b => 20); > ERROR: XX000: unrecognized node type:

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-03-16 5:46 GMT+01:00 Michael Paquier : > On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote: > >> But, I suppose it is a bit too big. > > > > That's of course not backpatchable. > > So in this jungle attached is my counter-proposal. As the same code >

RE: [bug fix] Cascaded standby cannot start after a clean shutdown

From: Michael Paquier [mailto:mich...@paquier.xyz] > We use palloc_extended with MCXT_ALLOC_NO_OOM in 9.5~, and malloc() further > down, so once you remove the FATAL error caused by a record whose length > is higher than 1GB, you discard all the hard failures, no? Ouch, you're right. If memory

segmentation fault in pg head with SQL function.

Hi, I found a segmentation fault on pg master Head with below steps and stacktrace. postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID LANGUAGE SQL AS $$ select 10; $$; CREATE FUNCTION postgres=# select func1(); server closed the connection unexpectedly This probably means the server

Re: Ambigous Plan - Larger Table on Hash Side

Hi Jeff, I repeated the same query with a work_mem of 2000MB. It is faster than the one with two batches but still slower than hashing the smaller table. So in this case It makes more sense to hash the smaller table (less execution time and reduce hash table size). Explain

Re: WaitLatchOrSocket optimization

Hi, On 15.03.2018 20:25, Andres Freund wrote: Hi, On 2018-03-15 19:01:40 +0300, Konstantin Knizhnik wrote: Right now function WaitLatchOrSocket is implemented in very inefficient way: for each invocation it creates epoll instance, registers events and then closes this instance. Right,

Hash join in SELECT target list expression keeps consuming memory

Hi, If the SELECT target list expression is a join subquery, and if the subquery does a hash join, then the query keeps on consuming more and more memory. Below is such a query : SELECT (SELECT id FROM unnest((pg_catalog.acldefault('L',l.col1))) WITH ORDINALITY AS perm(acl,id),

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Mar 14, 2018 at 12:01 AM, Robert Haas wrote: > > 0003 introduces a new upper relation to represent the result of > applying the scan/join target to the topmost scan/join relation. I'll > explain further down why this seems to be needed. Since each path > must

Re: missing support of named convention for procedures

2018-03-16 8:43 GMT+01:00 Pavel Stehule : > > > 2018-03-15 22:13 GMT+01:00 Pavel Stehule : > >> Hi >> >> create or replace procedure proc2(in a int, in b int) >> as $$ >> begin >> a := a * 10; >> b := b * 10; >> end; >> $$ language plpgsql; >>

Re: missing support of named convention for procedures

2018-03-16 11:29 GMT+01:00 Pavel Stehule : > > > 2018-03-16 8:43 GMT+01:00 Pavel Stehule : > >> >> >> 2018-03-15 22:13 GMT+01:00 Pavel Stehule : >> >>> Hi >>> >>> create or replace procedure proc2(in a int, in b int) >>>

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Fri, Mar 16, 2018 at 10:21:39AM +0900, Michael Paquier wrote: > On Thu, Mar 15, 2018 at 01:33:51PM +0300, Arthur Zakirov wrote: > > I think your approach has a vulnerability too. I believe that a > > non GUC_LIST_INPUT extension GUC which was used to create a function may > > become

Re: ON CONFLICT DO UPDATE for partitioned tables

On Fri, Mar 2, 2018 at 9:06 PM, Alvaro Herrera wrote: > > @@ -106,6 +120,9 @@ typedef struct PartitionTupleRouting int num_subplan_partition_offsets; TupleTableSlot *partition_tuple_slot; TupleTableSlot *root_tuple_slot; + List

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

On Tue, Mar 13, 2018 at 8:34 PM, Stephen Frost wrote: > > It would really help to have some examples of exactly what is being > proposed here wrt solutions. > > WCO is defined at a view level, so I'm not following the notion that > we're going to depend on something remote to

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

At Fri, 16 Mar 2018 09:16:54 +0100, Pavel Stehule wrote in > 2018-03-16 5:46 GMT+01:00 Michael Paquier : > > > On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote: > >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-03-16 9:34 GMT+01:00 Kyotaro HORIGUCHI : > At Fri, 16 Mar 2018 09:16:54 +0100, Pavel Stehule > wrote in zyujawdnu...@mail.gmail.com> > > 2018-03-16 5:46 GMT+01:00 Michael Paquier

Re: [HACKERS] [PATCH] Incremental sort

On Fri, Mar 16, 2018 at 5:12 AM, Tomas Vondra wrote: > I agree those don't seem like an issue in the Incremental Sort patch, > but like a more generic costing problems. > Yes, I think so too. Do you think we can mark this patch RFC assuming that it have already got

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Thu, Mar 15, 2018 at 8:57 PM, Tom Lane wrote: > We've long made fun of Oracle(TM) for the fact that if you just want > to evaluate some expressions, you have to write "select ... from dual" > rather than just "select ...". But I've realized recently that there's > a bit of

Re: GSOC :Thrift datatype support (2018)

Hello Pranav, > I am interested in your GSOC projectidea. So I want to know ,can I get > more information regarding this project andfrom where to start and > what to study. > > So that I can submit the proposal as fastas possible . A few people asked about it recently. Please see these

Re: [HACKERS] Partition-wise aggregation/grouping

On Thu, Mar 15, 2018 at 7:46 PM, Robert Haas wrote: > On Thu, Mar 15, 2018 at 6:08 AM, Ashutosh Bapat > wrote: >> In current create_grouping_paths() (without any of your patches >> applied) we first create partial paths in partially grouped

Re: PL/pgSQL nested CALL with transactions

2018-03-16 18:35 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 3/16/18 00:24, Pavel Stehule wrote: > > What is benefit of DO command in PLpgSQL? Looks bizarre for me. > > Not very typical, but we apply the same execution context handling to > CALL and DO at the top level,

Re: [HACKERS] Partition-wise aggregation/grouping

On Thu, Mar 15, 2018 at 9:19 PM, Robert Haas wrote: > On Thu, Mar 15, 2018 at 9:46 AM, Jeevan Chalke > wrote: >> Hmm.. you are right. Done. > > I don't see a reason to hold off on committing 0002 and 0003, so I've > done that now; since they

Re: [HACKERS] Partition-wise aggregation/grouping

On Fri, Mar 16, 2018 at 12:16 AM, Robert Haas wrote: > > - partial_costs_set. The comment in compute_group_path_extra_data > doesn't look good. It says "Set partial aggregation costs if we are > going to calculate partial aggregates in make_grouping_rels()", but > what it

Re: PostgreSQL opens all the indexes of a relation for every Query during Planning Time?

> On Mar 15, 2018, at 4:18 AM, Meenatchi Sandanam wrote: > > On checking PostgreSQL code, we see it opens all indexes of a relation for > every query planning time as in the attachment. If that is the case, it might > lead to Performance degradation for relations with many

Re: chained transactions

On 3/15/18 12:39, Alvaro Herrera wrote: >> Subject: [PATCH v1 1/8] Update function comments >> Subject: [PATCH v1 2/8] Rename TransactionChain functions >> Subject: [PATCH v1 3/8] Simplify parse representation of savepoint commands >> Subject: [PATCH v1 4/8] Improve savepoint error messages >>

Re:Re: Re: [submit code] I develop a tool for pgsql, how can I submit it

so cool, thank you so much! -- Best regards, leapking At 2018-03-15 20:10:08, "Aleksander Alekseev" wrote: >Hello leap, > >> I don't know how to "submit a link to Reddit and/or Hacker News". if >> some people also like pgcheck after know pg_filedump, hope to help me

Re: segmentation fault in pg head with SQL function.

Michael Paquier writes: > On Fri, Mar 16, 2018 at 11:35:13AM +0530, Prabhat Sahu wrote: >> postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID >> LANGUAGE SQL >> AS $$ >> select 10; >> $$; > Problem reproducible here, and the bug has been introduced by fd1a421f. > It

Re: fixing more format truncation issues

On 3/15/18 12:12, Tom Lane wrote: > FWIW, I noticed while fooling with pre-release Fedora 28 that gcc 8.0.1 > emits a whole boatload of these warnings by default. I have some patches for that. I will send them in once gcc 8 is a bit closer to release. -- Peter Eisentraut

Re: SSL passphrase prompt external command

On 3/15/18 12:13, Daniel Gustafsson wrote: > * In src/backend/libpq/be-secure-common.c: > > +int > +run_ssl_passphrase_command(const char *prompt, bool is_server_start, char > *buf, int size) > +{ > [..] > + size_t len = 0; > [..] > + return len; > +} > >

Re: PL/pgSQL nested CALL with transactions

On 3/16/18 00:24, Pavel Stehule wrote: > What is benefit of DO command in PLpgSQL? Looks bizarre for me. Not very typical, but we apply the same execution context handling to CALL and DO at the top level, so it would be weird not to propagate that. -- Peter Eisentraut

Question about WalSndWriteData

Hi hackes, I confused by the following code in WalSndWriteData:     /* output previously gathered data in a CopyData packet */     pq_putmessage_noblock('d', ctx->out->data, ctx->out->len);     /*      * Fill the send timestamp last, so that it is taken as late as possible.      * This is

Re: SSL passphrase prompt external command

> On 16 Mar 2018, at 17:07, Peter Eisentraut > wrote: > > On 3/15/18 12:13, Daniel Gustafsson wrote: >> * The documentation for the passphrase command format states: >> >>"If the setting starts with -, then it will be ignored during a reload and >>the

Re: PATCH: Configurable file mode mask

On 3/15/18 3:17 AM, Michael Paquier wrote: > On Wed, Mar 14, 2018 at 02:08:19PM -0400, David Steele wrote: > > When taking a base backup from a data folder which has group access, > then the tar data, as well as the untar'ed data, are still using > 0600 as umask for files and 0700 for folders.

Re: MCV lists for highly skewed distributions

On 03/11/2018 10:23 AM, Dean Rasheed wrote: > ... > > I'm moving this back to a status of "Needs review" partly because the > code has changed significantly, but also because I want to do more > testing, particularly with larger datasets. > Thanks for working on this. The code seems fine to me,

Re: Re: pgbench randomness initialization

But now the documentation is back to its original state of silence on what base or how many bases might be allowed. Could it just say "or an unsigned decimal integer value"? Then no one will wonder. Done in the attached. Thanks for the reviews. -- Fabien.diff --git

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Ashutosh Bapat writes: > On Thu, Mar 15, 2018 at 8:57 PM, Tom Lane wrote: >> Suppose that, either in the rewriter or early in the planner, we were >> to replace such cases with nonempty FromExprs, by adding a dummy RTE >> representing a table

Re: PATCH: Configurable file mode mask

Greetings David, Michael, all, * David Steele (da...@pgmasters.net) wrote: > On 3/15/18 3:17 AM, Michael Paquier wrote: > > On Wed, Mar 14, 2018 at 02:08:19PM -0400, David Steele wrote: > > > > When taking a base backup from a data folder which has group access, > > then the tar data, as well as

Re: ON CONFLICT DO UPDATE for partitioned tables

Pavan Deolasee wrote: > Hmm, yeah, probably you're right. The reason I got confused is because the > patch uses ri_onConflictSetProj/ri_onConflictSetWhere to store the > converted projection info/where clause for a given partition in its > ResultRelationInfo. So I was wondering if we can > move

Re:Re: [submit code] I develop a tool for pgsql, how can I submit it

Thank you for getting back to me. I want to know what it is in every data file and the format, so I develop pgcheck. I also hope pgcheck can check data error in pgsql more easily, but there are a lot of work to do. It can not be finished by myself, so I hope more people can develop it

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

On 16 March 2018 at 03:57, Alexander Korotkov wrote: > On Tue, Mar 13, 2018 at 3:25 PM, Alvaro Herrera > wrote: > >> Alexander Korotkov wrote: >> >> > And what happen if somebody concurrently set (fastupdate = on)? >> > Can we miss conflicts

Re: [HACKERS] [PATCH] Incremental sort

On 03/16/2018 09:47 AM, Alexander Korotkov wrote: > On Fri, Mar 16, 2018 at 5:12 AM, Tomas Vondra > > wrote: > > I agree those don't seem like an issue in the Incremental Sort patch, > but like a more generic costing

Re: SQL/JSON: functions

On 14 Mar 2018 17:11, "Alexander Korotkov" wrote: On Wed, Mar 14, 2018 at 2:10 AM, Andres Freund wrote: > On 2018-03-14 07:54:35 +0900, Michael Paquier wrote: > > On Tue, Mar 13, 2018 at 04:08:01PM +0300, Oleg Bartunov wrote: > > > The docs are

GSOC :Thrift datatype support (2018)

Sir I am interested in your GSOC projectidea. So I want to know ,can I get more information regarding this project andfrom where to start and what to study. So that I can submit the proposal as fastas possible . Thank you Pranav Negi

Update doc links to https where appropriate?

Hi, Writing up docs for JITing I noticed that nearlyall wikipedia links on the acronyms page are http:// rather than https://. Seems like we should update links in the docs when alternatives are available? Any counterarguments? Greetings, Andres Freund

Re: PL/pgSQL nested CALL with transactions

Pavel Stehule writes: > 2018-03-16 18:35 GMT+01:00 Peter Eisentraut < > peter.eisentr...@2ndquadrant.com>: >> Not very typical, but we apply the same execution context handling to >> CALL and DO at the top level, so it would be weird not to propagate that. > Although it

Re: [HACKERS] Partition-wise aggregation/grouping

On Fri, Mar 16, 2018 at 3:19 AM, Robert Haas wrote: > On Thu, Mar 15, 2018 at 2:46 PM, Robert Haas wrote: >> I wonder if we could simplify things by copying more information from >> the parent grouping rel to the child grouping rels. > > On further

Re: ON CONFLICT DO UPDATE for partitioned tables

So ExecInsert receives the ModifyTableState, and separately it receives arbiterIndexes and the OnConflictAction, both of which are members of the passed ModifyTableState. I wonder why does it do that; wouldn't it be simpler to extract those members from the node? With the patch proposed

Re: ON CONFLICT DO UPDATE for partitioned tables

On Fri, Mar 16, 2018 at 11:21 AM, Alvaro Herrera wrote: > So ExecInsert receives the ModifyTableState, and separately it receives > arbiterIndexes and the OnConflictAction, both of which are members of > the passed ModifyTableState. I wonder why does it do that; wouldn't

Re: PL/pgSQL nested CALL with transactions

2018-03-16 18:49 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2018-03-16 18:35 GMT+01:00 Peter Eisentraut < > > peter.eisentr...@2ndquadrant.com>: > >> Not very typical, but we apply the same execution context handling to > >> CALL and DO at the

Re: Hash join in SELECT target list expression keeps consuming memory

Amit Khandekar writes: > If the SELECT target list expression is a join subquery, and if the > subquery does a hash join, then the query keeps on consuming more and > more memory. Below is such a query : Thanks for the report! I dug into this with valgrind, and found

Re: Update doc links to https where appropriate?

> On 16 Mar 2018, at 19:54, Andres Freund wrote: > Writing up docs for JITing I noticed that nearlyall wikipedia links on > the acronyms page are http:// rather than https://. Seems like we should > update links in the docs when alternatives are available? I don’t see a

Re: ON CONFLICT DO UPDATE for partitioned tables

Peter Geoghegan wrote: > On Fri, Mar 16, 2018 at 11:21 AM, Alvaro Herrera > wrote: > > So ExecInsert receives the ModifyTableState, and separately it receives > > arbiterIndexes and the OnConflictAction, both of which are members of > > the passed ModifyTableState. I

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

> On 25 Feb 2018, at 18:22, Chapman Flack wrote: > Here is a patch implementing the simpler approach Heikki suggested > (though my original leaning had been to wrench on AdvanceXLInsertBuffer > as Michael suggests). The sheer simplicity of the smaller change > eventually

Re: PATCH: Configurable file mode mask

On Fri, Mar 16, 2018 at 11:12:44AM -0400, Stephen Frost wrote: > Given that we're already, as I recall, including the owner/group of the > file being backed up through pg_basebackup in the tarball, it seems like > we should be including whatever the current dir/file mode is too. Those > files may

Re: ON CONFLICT DO UPDATE for partitioned tables

Hi, On 2018-03-16 18:23:44 -0300, Alvaro Herrera wrote: > Another thing I noticed is that the split of the ON CONFLICT slot and > its corresponding projection is pretty weird. The projection is in > ResultRelInfo, but the slot itself is in ModifyTableState. You can't > make the projection work

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Fri, Feb 9, 2018 at 1:05 PM, Claudio Freire wrote: > Turns out that it was a tad oversized. 300k tuples seems enough. > > Attached is a new patch version that: > > - Uses an unlogged table to make the large mwm test faster > - Uses a wait_barrier helper that waits for

Re: ON CONFLICT DO UPDATE for partitioned tables

Andres Freund wrote: > Hi, > > On 2018-03-16 18:23:44 -0300, Alvaro Herrera wrote: > > Another thing I noticed is that the split of the ON CONFLICT slot and > > its corresponding projection is pretty weird. The projection is in > > ResultRelInfo, but the slot itself is in ModifyTableState. You

Re: CURRENT OF causes an error when IndexOnlyScan is used

Yugo Nagata writes: > On Mon, 12 Mar 2018 13:56:24 -0400 > Tom Lane wrote: >> I took a quick look at this, but I'm concerned about a couple of points: > In addition, this patch fixes only nbtree indexes, but the simillar problem > will occur also on GIST

Re: ExplainProperty* and units

On 2018-03-14 13:32:10 -0400, Tom Lane wrote: > Andres Freund writes: > > Only thing I wonder is if we shouldn't just *remove* > > ExplainPropertyLong and make ExplainPropertyInteger accept 64bits of > > input - the effort of passing and printing a 64bit integer will never be

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

16.03.2018 04:23, Tomas Vondra пишет: > > > On 03/10/2018 03:11 AM, Yura Sokolov wrote: >> 08.03.2018 03:42, Tomas Vondra пишет: >>> On 03/06/2018 06:23 AM, Yura Sokolov wrote: 05.03.2018 18:00, Tom Lane пишет: > Tomas Vondra writes: >> Snapshots are

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

On 03/17/2018 12:03 AM, Yura Sokolov wrote: > 16.03.2018 04:23, Tomas Vondra пишет: >> >> ... >> >> OK, a few more comments. >> >> 1) The code in ExtendXipSizeForHash seems somewhat redundant with >> my_log2 (that is, we could just call the existing function). > > Yes, I could call my_log2 from

Re: [PROPOSAL] Shared Ispell dictionaries

On 03/07/2018 02:18 PM, Arthur Zakirov wrote: > On Wed, Mar 07, 2018 at 02:12:32PM +0100, Pavel Stehule wrote: >> 2018-03-07 14:10 GMT+01:00 Pavel Stehule : >>> 2018-03-07 13:58 GMT+01:00 Arthur Zakirov : Oh understood. Tomas suggested those

Re: [PROPOSAL] Shared Ispell dictionaries

Hello Tomas, Arthur, what are your plans with this patch in the current CF? I think dsm-based approach is in good shape already and works nice. I've planned only to improve the documentation a little. Also it seems I should change 0004 part, I found that extension upgrade scripts may be made in

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 16, 2018 at 3:36 PM, Amit Kapila wrote: > On Wed, Mar 14, 2018 at 12:01 AM, Robert Haas wrote: >> >> 0003 introduces a new upper relation to represent the result of >> applying the scan/join target to the topmost scan/join relation.

Re: parallel append vs. simple UNION ALL

On Wed, Mar 14, 2018 at 2:09 AM, Robert Haas wrote: > On Tue, Mar 13, 2018 at 12:35 AM, Ashutosh Bapat > wrote: >> It looks like it was not changed in all the places. make falied. I >> have fixed all the instances of these two functions in

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 16, 2018 at 6:06 AM, Amit Kapila wrote: > I think in the patch series this is the questionable patch wherein it > will always add an additional projection path (whether or not it is > required) to all Paths (partial and non-partial) for the scanjoin rel > and

Re: parallel append vs. simple UNION ALL

On Fri, Mar 9, 2018 at 1:04 AM, Robert Haas wrote: > Great. Committed 0001. Are you planning any further testing of this > patch series? Sorry I missed the mail. Yes, I have further tested patches and find no more issues. Thanks & Regards, Rajkumar Raghuwanshi QMG,

Re: ON CONFLICT DO UPDATE for partitioned tables

(2018/03/16 19:43), Pavan Deolasee wrote: On Fri, Mar 2, 2018 at 9:06 PM, Alvaro Herrera > wrote: @@ -106,6 +120,9 @@ typedef struct PartitionTupleRouting int num_subplan_partition_offsets; TupleTableSlot

Re: ON CONFLICT DO UPDATE for partitioned tables

On Fri, Mar 16, 2018 at 5:13 PM, Etsuro Fujita wrote: > (2018/03/16 19:43), Pavan Deolasee wrote: > >> On Fri, Mar 2, 2018 at 9:06 PM, Alvaro Herrera > > wrote: >> > > @@ -106,6 +120,9 @@ typedef struct