Re: [HACKERS] Hash Indexes

On Fri, Jun 24, 2016 at 2:38 PM, Mithun Cy wrote: > On Thu, Jun 16, 2016 at 12:58 PM, Amit Kapila > wrote: > > I have a question regarding code changes in _hash_first. > > +/* > + * Conditionally get the lock on primary bucket

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 21:34, Tom Lane wrote: > > TBH, this looks more like a compiler bug than anything else. I tend to agree. Especially since valgrind has no complaints on x64 linux, and neither does DrMemory for 32-bit builds with the same toolchain on the same Windows and

Re: [HACKERS] Memory leak in Pl/Python

For test I wrote script in Python, which calls a test function via psycopg2: #!/usr/bin/env python2 import psycopg2 conn = psycopg2.connect('xxx') cursor = conn.cursor() cursor.execute('set application_name to \'TEST\'') for i in range(1, 100): cursor.execute('select test()')

Re: [HACKERS] Improving executor performance

On Fri, Jun 24, 2016 at 4:29 PM, Andres Freund wrote: > As a motivation, here's a somewhat juicy example of the benefits that > can be gained (disabled parallelism, results vary too much): > SELECT l_linestatus, SUM(l_quantity) FROM lineitem GROUP BY 1 ORDER BY 2 DESC > LIMIT

Re: [HACKERS] Protocol buffer support for Postgres

On Fri, Jun 24, 2016 at 11:35 AM, Álvaro Hernández Tortosa wrote: > > > On 24/06/16 14:23, Flavius Anton wrote: >> >> On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton >> wrote: >>> >>> On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:

Re: [HACKERS] Improving executor performance

Hi, On 2016-06-24 16:29:53 -0700, Andres Freund wrote: > Comments so far? Different suggestions on how to get improvements > around this merged? Oh, and if somebody is interested on collaborating on some of these... This is far too big for me to tackle alone. Andres -- Sent via

[HACKERS] Improving executor performance

Hi, at pgcon, in [1], and various other threads and conferences we talked about our executor performance needing improvements to perform well in !OLTP workloads, and how we can get there. I've played with various techniques, on and off over the last few weeks. Including trying to make

Re: [HACKERS] Memory leak in Pl/Python

On Fri, Jun 24, 2016 at 6:41 PM, Andrey Zhidenkov < andrey.zhiden...@gmail.com> wrote: > For example, when I call this procedure > many times, ​Call how? Specifically, how are you handling transactions in the calling client? And what/how are you measuring memory consumption? ​David J. ​

Re: [HACKERS] MultiXactId error after upgrade to 9.3.4

After some further testing, I noticed a case that wasn't handled in heap_update, which I also fixed. I reworded some comments here and there, and pushed to all branches. Further testing and analysis is welcome. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Bug in to_timestamp().

On 06/24/2016 02:16 PM, Tom Lane wrote: Robert Haas writes: On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford wrote: To me, 2016-02-30 is an invalid date that should generate an error. I don't particularly disagree with that, but on

[HACKERS] Memory leak in Pl/Python

I have postgresql 9.4.8 on my server and I've noticed always growing memory when I use plpython. I've made some tests and find a few situations, when memory leaks. For example, when I call this procedure many times, I can see an always growing memory: create or replace function test() returns

Re: [HACKERS] Bug in to_timestamp().

On 25/06/16 08:33, Robert Haas wrote: On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford wrote: My observation has been that the PostgreSQL development group aims for correctness and the elimination of surprising results. This was part of the reason to eliminate a

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane wrote: > Uh, why? It's not a large amount of code and it seems like removing > it puts a fair-size hole in the symmetry of tuplesort's capabilities. It's not a small amount of code either. Removing the code clarifies the division of

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

Peter Geoghegan writes: > On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote: >> I think this may be premature in view of bug #14210. Even if we >> don't reinstate use of this function to fix that, I'm not really >> convinced we want to get rid of it; it seems

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford > wrote: >> To me, 2016-02-30 is an invalid date that should generate an error. > I don't particularly disagree with that, but on the other hand, as > mentioned earlier,

Re: [HACKERS] tuplesort.c's copytup_index() is dead code

On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote: > I think this may be premature in view of bug #14210. Even if we > don't reinstate use of this function to fix that, I'm not really > convinced we want to get rid of it; it seems likely to me that > we might want it again.

Re: [HACKERS] Bug in to_timestamp().

On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford wrote: > My observation has been that the PostgreSQL development group aims for > correctness and the elimination of surprising results. This was part of the > reason to eliminate a number of automatic casts to dates

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On Wed, Jun 22, 2016 at 5:16 AM, Ashutosh Bapat wrote: >> However, if we support deparsing subqueries, the remote query in the above >> example could be rewritten into something like this: >> >> SELECT ss.c2 FROM t1 LEFT JOIN (SELECT t2.a, ROW(a, b) FROM t2)

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On Wed, Jun 22, 2016 at 4:11 AM, Amit Langote wrote: >> In an outer join we have to differentiate between a row being null (because >> there was no joining row on nullable side) and a non-null row with all >> column values being null. If we cast the whole-row

Re: [HACKERS] Odd behavior with domains

On Thu, Jun 23, 2016 at 11:00 PM, Alvaro Herrera wrote: > Well, it's not specifically related to domains -- it's related to the > fact that pg_catalog objects mask the domain you created in the public > schema, because pg_catalog is by default in front of all other

Re: [HACKERS] Cleanup in contrib/postgres_fdw/deparse.c

On Mon, Jun 20, 2016 at 4:47 AM, Etsuro Fujita wrote: > Here is a small patch to remove an unnecessary return from > deparseFromExprForRel in contrib/postgres_fdw/deparse.c. Seems like a good cleanup. Committed. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Protocol buffer support for Postgres

On 24/06/16 14:23, Flavius Anton wrote: On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton wrote: On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote: On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote: I'd love to talk more about

Re: [HACKERS] Protocol buffer support for Postgres

On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton wrote: > On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote: >> On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote: >>> >>> I'd love to talk more about this. >> >> I thought quite a bit

Re: [HACKERS] Rethinking behavior of force_parallel_mode = regress

On Tue, Jun 21, 2016 at 4:41 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane wrote: >>> With that thought in mind, I propose that the behavior of >>> force_parallel_mode = regress is

Re: [HACKERS] Odd behavior with domains

Joshua D. Drake wrote: > Yes but what makes it weird is this: > > postgres=# create domain text char(3); > CREATE DOMAIN > > -- cool, no problem > > postgres=# create domain text char(2); > ERROR: type "text" already exists > > -- as expected > > postgres=# \dD > List of

Re: [HACKERS] Odd behavior with domains

On Fri, Jun 24, 2016 at 1:08 PM, Joshua D. Drake wrote: > On 06/23/2016 08:00 PM, Alvaro Herrera wrote: > >> Joshua D. Drake wrote: >> >>> Hey, >>> >>> So this came across my twitter feed: >>> >>> https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png >>> >>> I have verified the

Re: [HACKERS] Bug in to_timestamp().

On 06/24/2016 09:26 AM, Steve Crawford wrote: My observation has been that the PostgreSQL development group aims for correctness and the elimination of surprising results. This was part of the reason to eliminate a number of automatic casts to dates in earlier versions. To me, 2016-02-30 is an

Re: [HACKERS] Odd behavior with domains

On 06/23/2016 08:00 PM, Alvaro Herrera wrote: Joshua D. Drake wrote: Hey, So this came across my twitter feed: https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png I have verified the oddness with a newer version: Well, it's not specifically related to domains -- it's related to the fact that

Re: [HACKERS] Bug in to_timestamp().

My observation has been that the PostgreSQL development group aims for correctness and the elimination of surprising results. This was part of the reason to eliminate a number of automatic casts to dates in earlier versions. To me, 2016-02-30 is an invalid date that should generate an error.

Re: [HACKERS] Bug in to_timestamp().

Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 20.06.2016 17:09, Albe Laurenz wrote: Tom Lane wrote: I don't necessarily have an opinion yet. I would like to see more than just an unsupported assertion about what Oracle's behavior is. Also,

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 20:40, Tom Lane wrote: Robert Haas writes: On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston wrote: My understanding is that is not going to change for 9.6. That's exactly what is under discussion here. I would definitely

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

> On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer wrote: > > I'd like more details from those whose installs are crashing. What exact > > vcvars env did you run under, with which exact cl.exe version? This is a Windows server 2012 R2 Standard. Devenv: Microsoft

Re: [HACKERS] Declarative partitioning

Hi Amit, I tried creating 2-level partitioned table and tried to create simple table using CTAS from the partitioned table. It gives a cache lookup error. Here's the test CREATE TABLE pt1_l (a int, b varchar, c int) PARTITION BY RANGE(a); CREATE TABLE pt1_l_p1 PARTITION OF pt1_l FOR VALUES START

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer writes: > I have absolutely no idea why it's trying to access memory at what looks > like (uint64)(-1) though. Nothing in the auto vars list: > + 0x0043f7b0 {0x09e32600 {type=T_List (656) > length=1 head=0x09e325e0

[HACKERS] Odd behavior with domains

Hey, So this came across my twitter feed: https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png I have verified the oddness with a newer version: psql -U postgres psql (9.5.3) Type "help" for help. postgres=# create domain text char(3); CREATE DOMAIN postgres=# create domain text char(2); ERROR:

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer wrote: >> I was helping Haroon with this last night. I don't have access to the >> original thread and he's not around so I don't know how much he said. I'll >> repeat our findings here. Craig, I am around now looking

[HACKERS] bug in citext's upgrade script for parallel aggregates

Seems there's a small error in the upgrade script for citext for 1.1 to 1.2 which will cause min(citext) not to be parallel enabled. max(citext)'s combinefunc is first set incorrectly, but then updated to the correct value. I assume it was meant to set the combine function for min(citext)

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

I have been running bisect, it breaks at this commit: *commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a* *Author: Tom Lane >* *Date: Sat Jun 18 15:22:34 2016 -0400* *Restore foreign-key-aware estimation of join relation sizes.* *This patch

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/24 17:38, Ashutosh Bapat wrote: > On Fri, Jun 24, 2016 at 1:59 PM, Amit Langote wrote: >> I'm now starting to wonder if it would be outright wrong to just use the >> alias names of corresponding foreign tables directly for whole-row >> references? So, instead of these in target lists

Re: [HACKERS] Hash Indexes

On Thu, Jun 16, 2016 at 12:58 PM, Amit Kapila wrote: I have a question regarding code changes in *_hash_first*. +/* + * Conditionally get the lock on primary bucket page for search while +* holding lock on meta page. If we have to wait, then

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Wed, Jun 22, 2016 at 10:51 AM, Michael Paquier wrote: > This connection string is stored in shared memory in WalRcvData, and > that's the case for a couple of releases now, so it has already a high > footprint, though I agree that making that available at SQL level >

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On Fri, Jun 24, 2016 at 1:59 PM, Amit Langote wrote: > On 2016/06/24 15:44, Ashutosh Bapat wrote: > >> > >> I think the proposed idea of applying record::text explicit coercion to > a > >> whole-row reference in the IS NOT NULL condition in the CASE WHEN > >>

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/24 15:44, Ashutosh Bapat wrote: >> >> I think the proposed idea of applying record::text explicit coercion to a >> whole-row reference in the IS NOT NULL condition in the CASE WHEN >> conversion would work as expected as you explained, but I'm concerned that >> the cost wouldn't be

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer wrote: >> I was helping Haroon with this last night. I don't have access to the >> original thread and he's not around so I don't know how much he said. I'll >> repeat our findings here. Craig, I am around now looking

Re: [HACKERS] PQconnectdbParams vs PQconninfoParse

On 23 June 2016 at 21:59, Tom Lane wrote: > Craig Ringer writes: > > While writing some code that takes a connstring and adds some > parameters, I > > noticed that PQconninfoParse doesn't play well with PQconnectdbParams. > > > PQconnectdbParams takes

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

> > I think the proposed idea of applying record::text explicit coercion to a > whole-row reference in the IS NOT NULL condition in the CASE WHEN > conversion would work as expected as you explained, but I'm concerned that > the cost wouldn't be negligible when the foreign table has a lot of

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jun 24, 2016 at 3:22 PM, Craig Ringer wrote: > > > On 24 June 2016 at 10:28, Michael Paquier wrote: >> >> On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer >> wrote: >> > * Launch a VS x86 command prompt >> > *

Re: [HACKERS] Postgres_fdw join pushdown - wrong results with whole-row reference

On 2016/06/22 19:37, Ashutosh Bapat wrote: On Wed, Jun 22, 2016 at 3:57 PM, Etsuro Fujita Maybe I'm confused, but I think that in the system-column case it's the user's responsibility to specify system columns for foreign tables in a local query only when that makes sense on the

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 24 June 2016 at 10:28, Michael Paquier wrote: > On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer > wrote: > > * Launch a VS x86 command prompt > > * devenv /debugexe bin\initdb.exe -D test > > * Set a breakpoint in initdb.c:3557 and