Re: [HACKERS] Change GetLastImportantRecPtr's definition? (wasSkip checkpoints, archiving on idle systems.)

On Fri, May 5, 2017 at 6:54 AM, Andres Freund wrote: > Hi, > > On 2016-12-22 19:33:30 +, Andres Freund wrote: >> Skip checkpoints, archiving on idle systems. > > As part of an independent bugfix I noticed that Michael & I appear to > have introduced an off-by-one here. A

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Wed, May 3, 2017 at 12:25 AM, Peter Eisentraut wrote: > On 5/2/17 10:08, Michael Paquier wrote: >> On Tue, May 2, 2017 at 9:30 PM, Peter Eisentraut >> wrote: >>> On 5/2/17 03:11, Petr Jelinek wrote: logical decoding can

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

On Thu, May 4, 2017 at 10:40 PM, Robert Haas wrote: > 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

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: >> In pgfdw_xact_callback, if the execution of ABORT TRANSACTION fails >> due to any reason then I think it will close the connection. The >>

Re: [HACKERS] compiler warning with VS 2017

Haribabu Kommi writes: > I am getting a compiler warning when I build the latest HEAD PostgreSQL with > visual studio 2017. > The code at the line is, > tuple->values[i] = (char *) (Size)0xdeadbeef; /* make bad usage more obvious > */ Yeah, you're not the first to

Re: [HACKERS] CTE inlining

Hi, On 2017-05-04 19:57:21 -0700, Joe Conway wrote: > One thought, is that we treat a CTE in a similar way to foreign tables, > with the same set of push downs. A bit surprised about that suggestion - there seems to be very little similarity between the cases. What'd be the benefit of that?

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On Fri, May 5, 2017 at 2:23 PM, David Rowley wrote: > On 5 May 2017 at 13:37, Andres Freund wrote: >> On 2017-05-02 15:13:58 -0400, Robert Haas wrote: >>> Multiple people (including David Rowley >>> as well as folks here at EnterpriseDB) have

Re: [HACKERS] CTE inlining

On 05/04/2017 07:04 PM, Tom Lane wrote: > Craig Ringer writes: >> We're carefully maintaining this bizarre cognitive dissonance where we >> justify the need for using this as a planner hint at the same time as >> denying that we have a hint. That makes it hard to

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 2017-05-04 19:45:33 -0700, Andres Freund wrote: > Increment phs_cblock without checking rs_nblocks, but outside of the > lock do a % scan->rs_nblocks, to get the "actual" position. Finish if > (phs_cblock - phs_startblock) / scan->rs_nblocks >= 1. Err, as I've been pointed to: It should be

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 2017-05-05 14:40:43 +1200, David Rowley wrote: > On 5 May 2017 at 14:36, Andres Freund wrote: > > I wonder how much doing the atomic ops approach alone can help, that > > doesn't have the issue that the work might be unevenly distributed > > between pages. > > I wondered

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 5 May 2017 at 14:36, Andres Freund wrote: > I wonder how much doing the atomic ops approach alone can help, that > doesn't have the issue that the work might be unevenly distributed > between pages. I wondered that too, since I though the barrier for making this change

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 3 May 2017 at 07:13, Robert Haas wrote: > Multiple people (including David Rowley > as well as folks here at EnterpriseDB) have demonstrated that for > certain queries, we can actually use a lot more workers and everything > works great. The problem is that for other

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

Hi, On 2017-05-05 14:20:48 +1200, David Rowley wrote: > Yeah, I did get some time to look over the contention in Parallel Seq > Scan a while back and I discovered that on the machine that I was > testing on. the lock obtained in heap_parallelscan_nextpage() was > causing workers to have to wait

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 5 May 2017 at 13:37, Andres Freund wrote: > On 2017-05-02 15:13:58 -0400, Robert Haas wrote: >> Multiple people (including David Rowley >> as well as folks here at EnterpriseDB) have demonstrated that for >> certain queries, we can actually use a lot more workers and

[HACKERS] compiler warning with VS 2017

I am getting a compiler warning when I build the latest HEAD PostgreSQL with visual studio 2017. src/backend/replication/logical/proto.c(482): warning C4312: 'type cast': conversion from 'unsigned int' to 'char *' of greater size Details of the warning is available in the link [1]. The code at

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 3 May 2017 at 07:13, Robert Haas wrote: > It is of course possible that the Parallel Seq Scan could run into > contention problems if the number of workers is large, but in my > experience there are bigger problems here. The non-parallel Seq Scan > can also contend --

Re: [HACKERS] CTE inlining

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Craig Ringer writes: > > We're carefully maintaining this bizarre cognitive dissonance where we > > justify the need for using this as a planner hint at the same time as > > denying that we have a hint. That makes

Re: [HACKERS] CTE inlining

In my past life when I was faced with such debates I argued that the number of customers We are hoping to attract in the future is much bigger than the ones we risk offending. Doesn't mean I wanted to piss everyone off. Just that I didn't want to be held hostage by history. Cheers Serge PS: On

Re: [HACKERS] CTE inlining

Craig Ringer writes: > We're carefully maintaining this bizarre cognitive dissonance where we > justify the need for using this as a planner hint at the same time as > denying that we have a hint. That makes it hard to make progress here. > I think there's fear that

Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)

On 2017-05-02 15:13:58 -0400, Robert Haas wrote: > On Tue, Apr 18, 2017 at 2:48 AM, Amit Khandekar > wrote: > The main things that keeps this from being a crippling issue right now > is the fact that we tend not to use that many parallel workers in the > first place.

Re: [HACKERS] CTE inlining

On 5 May 2017 at 08:17, Joe Conway wrote: > On 05/04/2017 05:03 PM, Craig Ringer wrote: >> On 5 May 2017 02:52, "Tom Lane" wrote: >> I haven't been keeping close tabs either, but surely we still have >> to have >> the optimization fence in (at least) all these

Re: [HACKERS] PG 10 release notes

On 2017-05-04 18:23:38 -0700, Peter Geoghegan wrote: > On Thu, May 4, 2017 at 6:08 PM, Robert Haas wrote: > >> E.g. to power amazon's data migration service (yes, that scares me). > > > > If you recall, I did predict prior to commit that test_decoding would > > get put into

[HACKERS] Change GetLastImportantRecPtr's definition? (wasSkip checkpoints, archiving on idle systems.)

Hi, On 2016-12-22 19:33:30 +, Andres Freund wrote: > Skip checkpoints, archiving on idle systems. As part of an independent bugfix I noticed that Michael & I appear to have introduced an off-by-one here. A few locations do comparisons like: /* * Only log if enough

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 6:08 PM, Robert Haas wrote: >> E.g. to power amazon's data migration service (yes, that scares me). > > If you recall, I did predict prior to commit that test_decoding would > get put into production use regardless of the name. I thought you were

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 8:46 PM, Bruce Momjian wrote: > On Thu, May 4, 2017 at 05:09:40PM -0700, Andres Freund wrote: >> > > I would not in any way refer to logical decoding as being only a proof >> > > of concept, even before logical replication. >> > >> > The community ships a

Re: [HACKERS] PG 10 release notes

On 2017-05-04 21:08:41 -0400, Robert Haas wrote: > On Thu, May 4, 2017 at 8:09 PM, Andres Freund wrote: > > On Mon, May 1, 2017 at 08:02:46AM -0400, Robert Haas wrote: > >> Even test_decoding is (perhaps regrettably) being used to build production > >> solutions. > > > >

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 8:09 PM, Andres Freund wrote: > On Mon, May 1, 2017 at 08:02:46AM -0400, Robert Haas wrote: >> Even test_decoding is (perhaps regrettably) being used to build production >> solutions. > > E.g. to power amazon's data migration service (yes, that scares

Re: [HACKERS] PG 10 release notes

On 2017-05-04 20:46:24 -0400, Bruce Momjian wrote: > On Thu, May 4, 2017 at 05:09:40PM -0700, Andres Freund wrote: > > > > I would not in any way refer to logical decoding as being only a proof > > > > of concept, even before logical replication. > > > > > > The community ships a reliable

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 7:56 PM, Bruce Momjian wrote: > The community ships a reliable logical _encoding_, and a test logical > _decoding_. As far as I am aware, logical encoding is a term you just made up, because it's not referenced anywhere in the commit log or the source

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 05:09:40PM -0700, Andres Freund wrote: > > > I would not in any way refer to logical decoding as being only a proof > > > of concept, even before logical replication. > > > > The community ships a reliable logical _encoding_, and a test logical > > _decoding_. > > Yes, so

Re: [HACKERS] snapbuild woes

On 2017-05-04 17:00:04 -0700, Andres Freund wrote: > Attached is a prototype patch for that. Oops. Andres >From b6eb46e376e40f3e2e9a55d16b1b37b27904564b Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Thu, 4 May 2017 16:40:52 -0700 Subject: [PATCH 1/2] WIP: Fix off-by-one

[HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

Hackers, just FYI, I cannot find any regression test coverage of this part of the grammar, not even in the contrib/ directory or TAP tests. I was going to submit a patch to help out, and discovered it is not so easy to do, and perhaps that is why the coverage is missing. My apologies for the

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: > This came up from discussion related to this item: > > the ability of logical decoding to follow timeline switches > > My point was that based on the text it is test_decoding

Re: [HACKERS] PG 10 release notes

On Thu, May 4, 2017 at 07:01:17PM -0300, Alvaro Herrera wrote: > 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) >

Re: [HACKERS] CTE inlining

On 05/04/2017 05:03 PM, Craig Ringer wrote: > On 5 May 2017 02:52, "Tom Lane" wrote: > 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

Re: [HACKERS] CTE inlining

On 5 May 2017 06:04, "Andreas Karlsson" wrote: 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

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

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

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

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

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 >

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

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

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 > >

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

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.

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

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

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

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

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

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

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.

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

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

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 >

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

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

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

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

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] 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

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

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

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.

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

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

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] 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

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

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 @@

[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

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

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

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

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

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

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

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

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

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

[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,

[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

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

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 > ( >

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

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

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

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

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 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] 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',

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] 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

[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

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

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

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 >>

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

  1   2   >