Re: [HACKERS] CTE inlining

> 1) we switch unmarked CTEs as inlineable by default in pg11. +1 from me for option 1 -- View this message in context: http://www.postgresql-archive.org/CTE-inlining-tp5958992p5959615.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers ma

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I suspect that most users would find it more useful to capture all of >> the rows that the statement actually touched, regardless of whether >> they hit the named table or an inheritance child. > > Yes, agreed. For the

Re: [HACKERS] CTE inlining

On 04/05/17 05:33, Alvaro Herrera wrote: > David Fetter wrote: > >> When we add a "temporary" GUC, we're taking on a gigantic burden. >> Either we support it forever somehow, or we put it on a deprecation >> schedule immediately and expect to be answering questions about it for >> years after it's

Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 4, 2017 at 9:12 PM, Prabhat Sahu wrote: > I have been testing this for a while and observed a server crash while > referencing table column value in a trigger procedure for AFTER DELETE > trigger. > > -- Steps to reproduce: > CREATE TABLE t1(c1 int); > CREATE TABLE t2(cc1 int); > INS

Re: [HACKERS] CTE inlining

On 30/04/17 16:28, Tom Lane wrote: Craig Ringer writes: - as you noted, it is hard to decide when it's worth inlining vs materializing for CTE terms referenced more than once. [ raised eyebrow... ] Please explain why the answer isn't trivially "never". There's already a pretty large hill to

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On 05/04/2017 08:01 AM, Robert Haas wrote: Patch attached. I tried at my end after applying the patch against PG HEAD, Case 1 - without setting statement_timeout i.e default X machine - create table test1(a int); Y machine - CREATE SERVER myserver_ppas FOREIGN DATA WRAPPER postgres_fdw OPTIO

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

On Tue, May 2, 2017 at 9:33 PM, Rahila Syed wrote: > Please find attached updated patch with review comments by Robert and Jeevan > implemented. > Patch v8 got clean apply on latest head but server got crash at data insert in the following test: -- Create test table CREATE TABLE test ( a int, b d

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On 05/04/2017 03:53 PM, tushar wrote: We can see statement_timeout is working but it is taking some extra time,not sure this is an expected behavior in above case or not. This is only when remote server is involved . in case when both the servers are on the same machine , then this is working a

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 6:23 AM, tushar wrote: > We can see statement_timeout is working but it is taking some extra time,not > sure this is an expected behavior in above case or not. Yeah, that's expected. To fix that, we'd need libpq to have an async equivalent of PQcancel(), which doesn't curr

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 1:19 AM, Robert Haas wrote: > On Thu, Apr 20, 2017 at 10:27 AM, Ashutosh Bapat > wrote: >> The logs above show that 34 seconds elapsed between starting to abort >> the transaction and knowing that the foreign server is unreachable. It >> looks like it took that much time fo

Re: [HACKERS] password_encryption, default and 'plain' support

On 05/03/2017 08:40 PM, Tom Lane wrote: The other question I can think to ask is what will happen during pg_upgrade, given an existing installation with one or more passwords stored plain. If the answer is "silently convert to MD5", I'd be good with that. Yes, it will silently convert to MD5.

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

Hello Amul, Thanks for reporting. Please find attached an updated patch which fixes the above. Also, the attached patch includes changes in syntax proposed upthread. The syntax implemented in this patch is as follows, CREATE TABLE p11 PARTITION OF p1 DEFAULT; Thank you, Rahila Syed On Thu, May

Re: [HACKERS] CTE inlining

On 04/05/2017 08:34, Petr Jelinek wrote: > On 03/05/17 23:24, Merlin Moncure wrote: >> On Wed, May 3, 2017 at 12:33 PM, Alvaro Herrera >> wrote: >>> David Fetter wrote: >>> When we add a "temporary" GUC, we're taking on a gigantic burden. Either we support it forever somehow, or we put i

Re: [HACKERS] Error message on missing SCRAM authentication with older clients

On 05/03/2017 03:12 PM, Aleksander Alekseev wrote: Hi Heikki, psql: SCRAM authentication not supported by this version of libpq Maybe it would be better to specify a minimum required version? Yeah, that could be helpful. Can you suggest a wording? My first thought was: psql: SCRAM authent

[HACKERS] Function to move the position of a replication slot

PFA a patch that adds a new function, pg_move_replication_slot, that makes it possible to move the location of a replication slot without actually consuming all the WAL on it. This can be useful for example to keep replication slots in sync between different servers in a replication cluster. (Obv

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

On Thu, May 4, 2017 at 5:14 PM, Rahila Syed wrote: > The syntax implemented in this patch is as follows, > > CREATE TABLE p11 PARTITION OF p1 DEFAULT; > > Applied v9 patches, table description still showing old pattern of default partition. Is it expected? create table lpd (a int, b int, c varch

Re: [HACKERS] Function to move the position of a replication slot

On 4 May 2017 at 20:05, Magnus Hagander wrote: > PFA a patch that adds a new function, pg_move_replication_slot, that makes > it possible to move the location of a replication slot without actually > consuming all the WAL on it. > This can be useful for example to keep replication slots in sync b

Re: [HACKERS] Function to move the position of a replication slot

On Thu, May 4, 2017 at 2:42 PM, Craig Ringer wrote: > On 4 May 2017 at 20:05, Magnus Hagander wrote: > > PFA a patch that adds a new function, pg_move_replication_slot, that > makes > > it possible to move the location of a replication slot without actually > > consuming all the WAL on it. > > >

Re: [HACKERS] Function to move the position of a replication slot

On 4 May 2017 at 20:45, Magnus Hagander wrote: > On Thu, May 4, 2017 at 2:42 PM, Craig Ringer wrote: >> >> On 4 May 2017 at 20:05, Magnus Hagander wrote: >> > PFA a patch that adds a new function, pg_move_replication_slot, that >> > makes >> > it possible to move the location of a replication sl

Re: [HACKERS] Reducing runtime of stats regression test

Tom Lane wrote: > The other significant delay in stats.sql is > > -- force the rate-limiting logic in pgstat_report_stat() to time out > -- and send a message > SELECT pg_sleep(1.0); > > Now, we do seem to need a delay there, because the rate-limiting logic > is unlikely to have permitted the co

Re: [HACKERS] Reducing runtime of stats regression test

Alvaro Herrera writes: > Tom Lane wrote: >> We can just start a new connection with \c, and >> let wait_for_stats wait for the old one to send its stats before quitting. >> Even on my oldest and slowest buildfarm machines, starting a new session >> takes well under one second. > So you changed ta

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 7:13 AM, Amit Kapila wrote: > In pgfdw_xact_callback, if the execution of ABORT TRANSACTION fails > due to any reason then I think it will close the connection. The > relavant code is: > if (PQstatus(entry->conn) != CONNECTION_OK || > PQtransactionStatus(entry->conn) != PQT

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Thu, May 4, 2017 at 4:46 AM, Thomas Munro wrote: > On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> I suspect that most users would find it more useful to capture all of >>> the rows that the statement actually touched, regardless of whether >>> they hit the n

Re: [HACKERS] Patch - Tcl 8.6 version support for PostgreSQL

Tom Lane wrote: > But I agree with Andres' complaint that just duplicating the code isn't > the best way. The configure script has a loop that's basically like > > for f in tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84 > tclsh8.3 tclsh83 > do >... break if $f is the right one

Re: [HACKERS] Patch - Tcl 8.6 version support for PostgreSQL

Alvaro Herrera writes: > Something like the (untested) attached perhaps? Looks plausible, I'm not in a position to test though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

Re: [HACKERS] Patch - Tcl 8.6 version support for PostgreSQL

On Thu, May 4, 2017 at 3:54 PM, Tom Lane wrote: > Alvaro Herrera writes: > > Something like the (untested) attached perhaps? > > Looks plausible, I'm not in a position to test though. Sandeep/Paresh - can you test please? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake Ente

[HACKERS] idea: custom log_line_prefix components besides application_name

Hi, At $work I am often entertained by log entries like: invalid input syntax for integer: "21' && 1=2)) Uni/**/ON SEl/**/eCT 0x646665743166657274,0x646665743266657274, 0x646665743366657274 -- " They're entertaining mostly because I know our web guy has heard of SQL injection and doesn't write s

Re: [HACKERS] CTE inlining

> On May 4, 2017, at 3:02 AM, Gavin Flower > wrote: > > On 30/04/17 16:28, Tom Lane wrote: >> Craig Ringer writes: >>> - as you noted, it is hard to decide when it's worth inlining vs >>> materializing for CTE terms referenced more than once. >> [ raised eyebrow... ] Please explain why the an

Re: [HACKERS] CTE inlining

Serge Rielau writes: >> On May 4, 2017, at 3:02 AM, Gavin Flower >> wrote: >> On 30/04/17 16:28, Tom Lane wrote: >>> There's already a pretty large hill to climb here in the way of >>> breaking peoples' expectations about CTEs being optimization >>> fences. Breaking the documented semantics abo

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 2 May 2017 at 00:10, David Rowley wrote: > On 20 April 2017 at 07:29, Euler Taveira wrote: >> 2017-04-19 1:32 GMT-03:00 Michael Paquier : >>> >>> I vote for "location" -> "lsn". I would expect complains about the >>> current inconsistency at some point, and the function names have been >>> alr

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

> Maybe we need another type of snapshot that would accept any > non-vacuumable tuple. I really don't want SnapshotAny semantics here, > but a tuple that was live more recently than the xmin horizon seems > like it's acceptable enough. HeapTupleSatisfiesVacuum already > implements the right beha

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 8:08 PM, Robert Haas wrote: > On Thu, May 4, 2017 at 7:13 AM, Amit Kapila wrote: > >>> - For bonus points, give pgfdw_exec_query() an optional timeout >>> argument, and set it to 30 seconds or so when we're doing abort >>> cleanup. If the timeout succeeds, it errors out (w

Re: [HACKERS] CTE inlining

On 05/04/2017 11:36 AM, Tom Lane wrote: > Serge Rielau writes: >>> On May 4, 2017, at 3:02 AM, Gavin Flower >>> wrote: >>> On 30/04/17 16:28, Tom Lane wrote: There's already a pretty large hill to climb here in the way of breaking peoples' expectations about CTEs being optimization >

Re: [HACKERS] CTE inlining

On Thu, May 4, 2017 at 9:22 AM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > Yeah, the idea that this won't cause possibly significant pain is quite > wrong. Quite by accident I came across an example just this morning where > rewriting as a CTE makes a big improvement. > > I wrote

Re: [HACKERS] CTE inlining

On 2017-05-04 09:34:19 -0700, David G. Johnston wrote: > On Thu, May 4, 2017 at 9:22 AM, Andrew Dunstan < > andrew.duns...@2ndquadrant.com> wrote: > > > > > Yeah, the idea that this won't cause possibly significant pain is quite > > wrong. Quite by accident I came across an example just this morni

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 12:18 PM, Amit Kapila wrote: > As soon as the first command fails due to timeout, we will set > 'abort_cleanup_failure' which will make a toplevel transaction to > abort and also won't allow other statements to execute. The patch is > trying to enforce a 30-second timeout a

Re: [HACKERS] Reducing runtime of stats regression test

On Thu, May 4, 2017 at 10:22 AM, Tom Lane wrote: > Yes, but that would be getting into the realm of new features, not > post-feature-freeze test adjustments. It certainly couldn't be > a candidate for back-patching. I'm not sure there's some bright line between adding a new SQL-callable function

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 10:18 PM, Robert Haas wrote: > On Thu, May 4, 2017 at 12:18 PM, Amit Kapila wrote: >> As soon as the first command fails due to timeout, we will set >> 'abort_cleanup_failure' which will make a toplevel transaction to >> abort and also won't allow other statements to execut

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, May 4, 2017 at 1:04 PM, Amit Kapila wrote: > On Thu, May 4, 2017 at 10:18 PM, Robert Haas wrote: >> On Thu, May 4, 2017 at 12:18 PM, Amit Kapila wrote: >>> As soon as the first command fails due to timeout, we will set >>> 'abort_cleanup_failure' which will make a toplevel transaction to

Re: [HACKERS] CTE inlining

On 05/04/2017 12:34 PM, David G. Johnston wrote: > On Thu, May 4, 2017 at 9:22 AM, Andrew Dunstan > >wrote: > > > Yeah, the idea that this won't cause possibly significant pain is > quite wrong. Quite by accident I came across an example just this >

[HACKERS] json_agg produces nonstandard json

Hello! I apologize in advanced if this has been previously discussed; A json(b)_agg() will produce the following result when no results are passed in: "[null]" per: select jsonb_agg((select 1 where false)); I believe, generally speaking, '[]' would be the more appropriate output. Would postg

Re: [HACKERS] CTE inlining

Andrew Dunstan wrote: > Hadn't though about LATERAL, good point. Still, there will be other cases. I'm not sure what your point is. We know that for some cases the optimization barrier semantics are useful, which is why the proposal is to add a keyword to install one explicitely: with

Re: [HACKERS] CTE inlining

On 05/04/2017 01:33 PM, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> Hadn't though about LATERAL, good point. Still, there will be other cases. > I'm not sure what your point is. We know that for some cases the > optimization barrier semantics are useful, which is why the proposal is > to

Re: [HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1

and here I send infrastructure patch which includes <...> Next 2 patches: Patch 'planning and execution', which includes: - replacement nonvolatile functions and operators by appropriate cached expressions; - planning and execution cached expressions; - regression tests. Patch 'costs', which

Re: [HACKERS] CTE inlining

On 05/04/2017 10:33 AM, Alvaro Herrera wrote: > I'm not sure what your point is. We know that for some cases the > optimization barrier semantics are useful, which is why the proposal is > to add a keyword to install one explicitely: > > with materialized r as > ( >

Re: [HACKERS] CTE inlining

On 05/04/2017 01:52 PM, Joe Conway wrote: > On 05/04/2017 10:33 AM, Alvaro Herrera wrote: >> I'm not sure what your point is. We know that for some cases the >> optimization barrier semantics are useful, which is why the proposal is >> to add a keyword to install one explicitely: >> >>

Re: [HACKERS] CTE inlining

On 5/4/17 7:56 PM, Andrew Dunstan wrote: On 05/04/2017 01:52 PM, Joe Conway wrote: On 05/04/2017 10:33 AM, Alvaro Herrera wrote: I'm not sure what your point is. We know that for some cases the optimization barrier semantics are useful, which is why the proposal is to add a keyword to instal

Re: [HACKERS] CTE inlining

On 05/04/2017 10:56 AM, Andrew Dunstan wrote: > > > On 05/04/2017 01:52 PM, Joe Conway wrote: >> On 05/04/2017 10:33 AM, Alvaro Herrera wrote: >>> I'm not sure what your point is. We know that for some cases the >>> optimization barrier semantics are useful, which is why the proposal is >>> to a

Re: [HACKERS] json_agg produces nonstandard json

Jordan Deitch writes: > A json(b)_agg() will produce the following result when no results are > passed in: > "[null]" > per: > select jsonb_agg((select 1 where false)); Looks fine to me. > I believe, generally speaking, '[]' would be the more appropriate output. Why? What you gave it was one n

Re: [HACKERS] Reducing runtime of stats regression test

Robert Haas writes: > On Thu, May 4, 2017 at 10:22 AM, Tom Lane wrote: >> Yes, but that would be getting into the realm of new features, not >> post-feature-freeze test adjustments. It certainly couldn't be >> a candidate for back-patching. > I'm not sure there's some bright line between adding

Re: [HACKERS] CTE inlining

Alvaro Herrera writes: > I'm not sure what your point is. We know that for some cases the > optimization barrier semantics are useful, which is why the proposal is > to add a keyword to install one explicitely: > with materialized r as > ( > select json_populate_rec

Re: [HACKERS] CTE inlining

On 5/4/17 8:03 PM, Joe Conway wrote: On 05/04/2017 10:56 AM, Andrew Dunstan wrote: On 05/04/2017 01:52 PM, Joe Conway wrote: On 05/04/2017 10:33 AM, Alvaro Herrera wrote: I'm not sure what your point is. We know that for some cases the optimization barrier semantics are useful, which is w

[HACKERS] Potential issue with alter system

Folks, So I did this: postgres=# alter system set archive_command to 'rsynv -av %p postgres@52.3.141.224:/data/archive/%f '; Note the new line. It properly created in postgresql.auto.conf: archive_command = 'rsynv -av %p postgres@52.3.141.224:/data/archive/%f ' (note the new line) I noticed

[HACKERS] Fix freeing of dangling IndexScanDesc.xs_hitup in GiST

Hello, hackers! The last query in the following script crashes Postgres: create table t (id serial, amount int); insert into t (amount) select random() * 1000 from generate_series(1, 100); create extension btree_gist; create index t_gist_idx on t using gist(id, amount); select p.id, p.amount, s

Re: [HACKERS] WITH clause in CREATE STATISTICS

Here's a patch implementing this idea. From gram.y's comment, the support syntax is now: /* * *QUERY : ! *CREATE STATISTICS stats_name [(stat types)] arguments ! ! *where 'ar

Re: [HACKERS] json_agg produces nonstandard json

Thank you for responding! Good points. However, I don't see consistency between the results of these two statements: select jsonb_agg((select 1 where false)); select sum((select 1 where false)); Therefore another option I would like to suggest is returning the same null value-types for the sum(

Re: [HACKERS] CTE inlining

Tomas Vondra writes: > On 5/4/17 8:03 PM, Joe Conway wrote: >>> I haven't been able to follow this incredibly long thread, so please >>> excuse me if way off base, but are we talking about that a CTE would be >>> silently be rewritten as an inline expression potentially unless it is >>> decorated

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On Wed, May 3, 2017 at 12:38 AM, Petr Jelinek wrote: > Ok, Let me be clear, I actually happen to agree with your proposal. The > reason I am moaning is that I always seem to find myself doing tons of > mechanical work to rewrite some cosmetic aspect of some patch based on > which committer is payi

Re: [HACKERS] CTE inlining

I haven't been keeping close tabs either, but surely we still have to have the optimization fence in (at least) all these cases: * CTE contains INSERT/UPDATE/DELETE * CTE contains SELECT FOR UPDATE/SHARE (else the set of rows that get locked might change) * CTE contains volatile functions I'm wil

Re: [HACKERS] json_agg produces nonstandard json

Jordan Deitch writes: > However, I don't see consistency between the results of these two > statements: > select jsonb_agg((select 1 where false)); > select sum((select 1 where false)); Well, SUM() is defined to ignore null input values, which is not too surprising as it couldn't do anything ver

Re: [HACKERS] Fix freeing of dangling IndexScanDesc.xs_hitup in GiST

Nikita Glukhov writes: > In gistrescan() IndexScanDesc.xs_hitup is not reset after > MemoryContextReset() of > so->queueCxt in which xs_hitup was allocated, then getNextNearest() tries to > pfree() > dangling xs_hitup, which results in the reuse of this pointer and the > subsequent crash. Righ

Re: [HACKERS] Potential issue with alter system

"Joshua D. Drake" writes: > So I did this: > postgres=# alter system set archive_command to 'rsynv -av %p > postgres@52.3.141.224:/data/archive/%f > '; > Note the new line. It properly created in postgresql.auto.conf: > archive_command = 'rsynv -av %p postgres@52.3.141.224:/data/archive/%f > '

Re: [HACKERS] Fix freeing of dangling IndexScanDesc.xs_hitup in GiST

On 04.05.2017 22:16, Tom Lane wrote: Nikita Glukhov writes: In gistrescan() IndexScanDesc.xs_hitup is not reset after MemoryContextReset() of so->queueCxt in which xs_hitup was allocated, then getNextNearest() tries to pfree() dangling xs_hitup, which results in the reuse of this pointer and

[HACKERS] what's up with IDENTIFIER_LOOKUP_EXPR?

plpgsql has an enum called IdentifierLookup which includes a value IDENTIFIER_LOOKUP_EXPR which is declared like this: IDENTIFIER_LOOKUP_EXPR /* In SQL expression --- special case */ It regrettably does not explain what exactly is special about it, and AFAICT, neither does any ot

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

Hi Rahila, I have started reviewing your latest patch, and here are my initial comments: 1. In following block, we can just do with def_index, and we do not need found_def flag. We can check if def_index is -1 or not to decide if default partition is present. @@ -166,6 +172,8 @@ RelationBuildPar

Re: [HACKERS] what's up with IDENTIFIER_LOOKUP_EXPR?

Robert Haas writes: > plpgsql has an enum called IdentifierLookup which includes a value > IDENTIFIER_LOOKUP_EXPR which is declared like this: > IDENTIFIER_LOOKUP_EXPR /* In SQL expression --- special case > */ > It regrettably does not explain what exactly is special about it, a

Re: [HACKERS] delta relations in AFTER triggers

On Fri, May 5, 2017 at 12:39 AM, Neha Sharma wrote: > While testing the feature we encountered one more crash,below is the > scenario to reproduce. > > create table t1 ( a int); > create table t2 ( a int); > insert into t1 values (11),(12),(13); > > create or replace function my_trig() returns tri

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

While reviewing the code I was trying to explore more cases, and I here comes an open question to my mind: should we allow the default partition table to be partitioned further? If we allow it(as in the current case) then observe following case, where I have defined a default partitioned which is

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Fri, May 5, 2017 at 2:40 AM, Robert Haas wrote: > On Thu, May 4, 2017 at 4:46 AM, Thomas Munro > wrote: >> On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera >> wrote: >>> Robert Haas wrote: I suspect that most users would find it more useful to capture all of the rows that the stateme

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

Hi Rahila, still thinking about the syntax (sorry): On 04.05.2017 13:44, Rahila Syed wrote: [...] The syntax implemented in this patch is as follows, CREATE TABLE p11 PARTITION OF p1 DEFAULT; Rewriting the following: On Thu, May 4, 2017 at 4:02 PM, amul sul > wrot

Re: [HACKERS] PG 10 release notes

Claudio Freire wrote: > On Tue, Apr 25, 2017 at 2:45 PM, Bruce Momjian wrote: > > However, given your explanation, I have added the item: > > > >Improve speed of VACUUM's removal of trailing empty > >heap pages (Alvaro Herrera) > > That's enough for me, thanks. Thanks! I amende

Re: [HACKERS] PG 10 release notes

Bruce Momjian wrote: > On Tue, Apr 25, 2017 at 04:03:53PM +1200, David Rowley wrote: > > ..On 25 April 2017 at 13:31, Bruce Momjian wrote: > > > The only unusual thing is that this release has ~180 items while most > > > recent release have had ~220. The pattern I see that there are more > > > l

Re: [HACKERS] what's up with IDENTIFIER_LOOKUP_EXPR?

On Thu, May 4, 2017 at 4:21 PM, Tom Lane wrote: > Robert Haas writes: >> plpgsql has an enum called IdentifierLookup which includes a value >> IDENTIFIER_LOOKUP_EXPR which is declared like this: >> IDENTIFIER_LOOKUP_EXPR /* In SQL expression --- special >> case */ >> It regretta

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Here's a patch implementing this idea. From gram.y's comment, the > support syntax is now: > > /* >* >*QUERY : > ! *CREATE STATISTICS stats_name [(stat types)]

Re: [HACKERS] Missing feature in Phrase Search?

Hi everybody, On 21.04.2017 20:47, Josh Berkus wrote: Oleg, Teodor, folks: I was demo'ing phrase search for a meetup yesterday, and the user feedback I got showed that there's a missing feature with phrase search. Let me explain by example: 'fix <-> error' will match 'fixed error', 'fixing

Re: [HACKERS] CTE inlining

On 05/05/17 06:39, Tomas Vondra wrote: On 5/4/17 8:03 PM, Joe Conway wrote: On 05/04/2017 10:56 AM, Andrew Dunstan wrote: On 05/04/2017 01:52 PM, Joe Conway wrote: On 05/04/2017 10:33 AM, Alvaro Herrera wrote: I'm not sure what your point is. We know that for some cases the optimization

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

Robert Haas writes: > On Wed, May 3, 2017 at 12:38 AM, Petr Jelinek > wrote: >> Ok, Let me be clear, I actually happen to agree with your proposal. The >> reason I am moaning is that I always seem to find myself doing tons of >> mechanical work to rewrite some cosmetic aspect of some patch based

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (amitlangot...@gmail.com) wrote: > On Wed, May 3, 2017 at 12:05 PM, Stephen Frost wrote: > > Assuming this looks good to you, I'll push it tomorrow, possibly with > > other minor adjustments and perhaps a few more tests. > > Your latest patch looks good to me. Found a few m

Re: [HACKERS] Row Level Security UPDATE Confusion

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 14, 2017 at 9:16 AM, Stephen Frost wrote: > > I agreed already up-thread that there's an issue there and will be > > looking to fix it. That comment was simply replying to Rod's point that > > the documentation could also be

Re: [HACKERS] PG 10 release notes

Thanks for doing this, looks great. A few notes: Add the ability to compute a correlation ratio and the number of distinct values on several columns (Tomas Vondra, David Rowley) I think this should be worded in terms of "extended data statistics" or suc

Re: [HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1

On Thu, May 4, 2017 at 7:51 PM, Marina Polyakova wrote: > and here I send infrastructure patch which includes <...> >> > > Next 2 patches: > > Patch 'planning and execution', which includes: > - replacement nonvolatile functions and operators by appropriate cached > expressions; > - planning and

Re: [HACKERS] what's up with IDENTIFIER_LOOKUP_EXPR?

Robert Haas writes: > The PLPGSQL_DTYPE_* constants are another thing that's not really > documented. Yeah :-(. Complain to Jan sometime. > You've mentioned that we should get rid of > PLPGSQL_DTYPE_ROW in favor of, uh, whatever's better than that, but > it's not clear to me what that really me

Re: [HACKERS] CTE inlining

On 05/04/2017 06:22 PM, Andrew Dunstan wrote: I wrote this query: select (json_populate_record(null::mytype, myjson)).* from mytable; It turned out that this was an order of magnitude faster: with r as ( select json_populate_record(null::mytype, myjson) as x from

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 04.05.2017 23:13, Tom Lane wrote: I'm not against what you've done here, because I had no love for USING in this context anyway; it conveys approximately nothing to the mind about what is in the list it's introducing. But I'm concerned whether we're boxing ourselves in by using ON. Actually,

Re: [HACKERS] PG 10 release notes

On Mon, May 1, 2017 at 7:02 AM, Robert Haas wrote: > On Tue, Apr 25, 2017 at 11:01 AM, Bruce Momjian wrote: >> I didn't think logical decoding was really more than a proof-of-concept >> until now. > > /me searches for jaw on floor. > > I would not in any way refer to logical decoding as being onl

Re: [HACKERS] PG 10 release notes

On 2017-04-25 15:29:01 -0400, Bruce Momjian wrote: > Uh, the only logical decoding code that I know we ship pre-PG 10 is > contrib/test_decoding/. That's completely wrong. src/backend/replication/logical/ is a a bit bigger than that... - Andres -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] PG 10 release notes

On 2017-05-04 17:33:13 -0500, Merlin Moncure wrote: > On Mon, May 1, 2017 at 7:02 AM, Robert Haas wrote: > > On Tue, Apr 25, 2017 at 11:01 AM, Bruce Momjian wrote: > >> I didn't think logical decoding was really more than a proof-of-concept > >> until now. > > > > /me searches for jaw on floor.

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 04/05/17 23:29, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 3, 2017 at 12:38 AM, Petr Jelinek >> wrote: >>> Ok, Let me be clear, I actually happen to agree with your proposal. The >>> reason I am moaning is that I always seem to find myself doing tons of >>> mechanical work to rewrite

Re: [HACKERS] PG 10 release notes

On Thu, Apr 27, 2017 at 10:21:44AM +0500, Andrew Borodin wrote: > Hi, Bruce! > > 2017-04-25 6:31 GMT+05:00 Bruce Momjian : > > The only unusual thing is that this release has ~180 items while most > > recent release have had ~220. The pattern I see that there are more > > large features in this r

Re: [HACKERS] PG 10 release notes

On Thu, Apr 27, 2017 at 10:43:34AM +0200, Fabien COELHO wrote: > > Hello Bruce, > > >I have committed the first draft of the Postgres 10 release notes. They > >are current as of two days ago, and I will keep them current. Please > >give me any feedback you have. > > About: > > """ > Fix psq

Re: [HACKERS] PG 10 release notes

On Thu, Apr 27, 2017 at 03:04:57PM +0200, Daniel Verite wrote: > Fabien COELHO wrote: > > >Fix psql \p to always print what would be executed by \g or \w (Daniel > >Vérité) > > > >Previously \p didn't properly print the reverted-to command after a > >buffer contents reset. C

Re: [HACKERS] PG 10 release notes

On Thu, Apr 27, 2017 at 04:05:09PM +0100, Dagfinn Ilmari Mannsåker wrote: > Bruce Momjian writes: > > > I have committed the first draft of the Postgres 10 release notes. They > > are current as of two days ago, and I will keep them current. Please > > give me any feedback you have. > > I noti

Re: [HACKERS] PG 10 release notes

On Fri, Apr 28, 2017 at 01:12:34PM +0900, Masahiko Sawada wrote: > On Tue, Apr 25, 2017 at 10:31 AM, Bruce Momjian wrote: > > I have committed the first draft of the Postgres 10 release notes. They > > are current as of two days ago, and I will keep them current. Please > > give me any feedback

Re: [HACKERS] Potential issue with alter system

On 05/04/2017 12:49 PM, Tom Lane wrote: "Joshua D. Drake" writes: So I did this: If you have other entries you want to keep in the postgresql.auto.conf file, you could get away with manually editing it to remove the newline. Got it. Thanks for digging in. This is actually a very real and

Re: [HACKERS] PG 10 release notes

On Mon, May 1, 2017 at 08:02:46AM -0400, Robert Haas wrote: > On Tue, Apr 25, 2017 at 11:01 AM, Bruce Momjian wrote: > >> Or the ability of logical decoding to follow timeline switches. > > > > I didn't think logical decoding was really more than a proof-of-concept > > until now. > > /me searche

Re: [HACKERS] snapbuild woes

Hi, On 2017-05-02 08:55:53 +0200, Petr Jelinek wrote: > Aah, now I understand we talked about slightly different things, I > considered the running thing to be first step towards tracking aborted > txes everywhere. > I think > we'll have to revisit tracking of aborted transactions in PG11 then > t

Re: [HACKERS] CTE inlining

On 5 May 2017 02:52, "Tom Lane" wrote: Tomas Vondra writes: > On 5/4/17 8:03 PM, Joe Conway wrote: >>> I haven't been able to follow this incredibly long thread, so please >>> excuse me if way off base, but are we talking about that a CTE would be >>> silently be rewritten as an inline expressio

Re: [HACKERS] PG 10 release notes

On Mon, May 1, 2017 at 10:20:38AM -0400, Robert Haas wrote: > I'm pretty sure this is not the first year in which your policy of > excluding certain performance-related items has met with opposition. > I agree that there are some improvements that are sufficiently small > and boring that they do n

Re: [HACKERS] PG 10 release notes

On 2017-05-04 19:56:21 -0400, Bruce Momjian wrote: > On Mon, May 1, 2017 at 08:02:46AM -0400, Robert Haas wrote: > > On Tue, Apr 25, 2017 at 11:01 AM, Bruce Momjian wrote: > > >> Or the ability of logical decoding to follow timeline switches. > > > > > > I didn't think logical decoding was really

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 06:02:58PM -0300, Alvaro Herrera wrote: > > I can't see how this can be added to an existing BRIN entry, so it would > > have to be new. The text would be: > > > > Improve accuracy in determining if a BRIN index scan is beneficial > > > > though this not something I w

  1   2   >