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

2017-05-04 Thread Robert Haas
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

Re: [HACKERS] CTE inlining

2017-05-04 Thread Andres Freund
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

Re: [HACKERS] CTE inlining

2017-05-04 Thread David G. Johnston
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

2017-05-04 Thread Andrew Dunstan
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

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

2017-05-04 Thread Amit Kapila
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 >>>

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

2017-05-04 Thread Dmitriy Sarafannikov
> 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

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

2017-05-04 Thread David Rowley
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

Re: [HACKERS] CTE inlining

2017-05-04 Thread Tom Lane
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

2017-05-04 Thread Serge Rielau
> 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

[HACKERS] idea: custom log_line_prefix components besides application_name

2017-05-04 Thread Chapman Flack
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

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

2017-05-04 Thread Dave Page
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:

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

2017-05-04 Thread Tom Lane
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

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

2017-05-04 Thread Alvaro Herrera
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

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

2017-05-04 Thread Robert Haas
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

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

2017-05-04 Thread Robert Haas
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 || >

Re: [HACKERS] Reducing runtime of stats regression test

2017-05-04 Thread Tom Lane
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

Re: [HACKERS] Reducing runtime of stats regression test

2017-05-04 Thread Alvaro Herrera
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

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

2017-05-04 Thread Craig Ringer
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 >>

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

2017-05-04 Thread Magnus Hagander
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

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

2017-05-04 Thread Craig Ringer
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

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

2017-05-04 Thread Rajkumar Raghuwanshi
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

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

2017-05-04 Thread Magnus Hagander
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.

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

2017-05-04 Thread Heikki Linnakangas
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

Re: [HACKERS] CTE inlining

2017-05-04 Thread Julien Rouhaud
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

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

2017-05-04 Thread Rahila Syed
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,

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

2017-05-04 Thread Heikki Linnakangas
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] statement_timeout is not working as expected with postgres_fdw

2017-05-04 Thread Amit Kapila
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

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

2017-05-04 Thread Robert Haas
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

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

2017-05-04 Thread tushar
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

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

2017-05-04 Thread amul sul
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

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

2017-05-04 Thread tushar
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

Re: [HACKERS] CTE inlining

2017-05-04 Thread Gavin Flower
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

Re: [HACKERS] delta relations in AFTER triggers

2017-05-04 Thread Thomas Munro
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); >

Re: [HACKERS] CTE inlining

2017-05-04 Thread Gavin Flower
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

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

2017-05-04 Thread Thomas Munro
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.

Re: [HACKERS] CTE inlining

2017-05-04 Thread Thomas Kellerer
> 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

Re: [HACKERS] CTE inlining

2017-05-04 Thread Petr Jelinek
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 it on a deprecation >>>

Re: [HACKERS] snapbuild woes

2017-05-04 Thread Petr Jelinek
On 04/05/17 07:45, Noah Misch wrote: > On Thu, Apr 27, 2017 at 09:42:58PM -0700, Andres Freund wrote: >> >> >> On April 27, 2017 9:34:44 PM PDT, Noah Misch wrote: >>> On Fri, Apr 21, 2017 at 10:36:21PM -0700, Andres Freund wrote: On 2017-04-17 21:16:57 -0700, Andres Freund

<    1   2