[HACKERS] Commit Fest 2014-12, Status after week 1

Hi all, I have been though the patches of the current CF, looking at their related threads and updating each patch status if needed. After one week in this CF, we have done progress on many patches, more than 2/3 of them getting some comments, reviews and/or refreshed versions. Looking at the CF

[HACKERS] ExplainModifyTarget doesn't work as expected

Hi, I think ExplainModifyTarget should show the parent of the inheritance tree in multi-target-table cases, as described there, but noticed that it doesn't always work like that. Here is an example. postgres=# create table parent (a int check (a < 0) no inherit); CREATE TABLE postgres=# create t

Re: [HACKERS] pgbench -f and vacuum

> Hi, > > On 21.12.2014 15:58, Tatsuo Ishii wrote: >>> On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: > If we care enough about that case to attempt the vacuum anyway > then we need to do something about the error message; either > squelch it or check for the existence of the t

Re: [HACKERS] documentation update for doc/src/sgml/func.sgml

On Sat, Oct 18, 2014 at 4:12 AM, Andreas 'ads' Scherbaum wrote: > On 09/14/2014 06:32 PM, Peter Eisentraut wrote: >> >> On 9/12/14 3:13 PM, Andreas 'ads' Scherbaum wrote: >>> >>> Of course a general rule how to link to WP would be nice ... >> >> >> I think Wikipedia links should be avoided altoget

Re: Suppressing elog.c context messages (was Re: [HACKERS] Wait free LW_SHARED acquisition)

On Fri, Dec 19, 2014 at 9:36 PM, Andres Freund wrote: > > Hi, > > When debugging lwlock issues I found PRINT_LWDEBUG/LOG_LWDEBUG rather > painful to use because of the amount of elog contexts/statements > emitted. Given the number of lwlock acquirations that's just not doable. > > To solve that du

Re: [HACKERS] install libpq.dll in bin directory on Windows / Cygwin

On Wed, Feb 26, 2014 at 6:11 AM, Peter Eisentraut wrote: > On 2/1/14, 3:22 PM, Andrew Dunstan wrote: >> In the end I went with the way I had suggested, because that's what the >> MSVC system does - it doesn't copy any other DLLs to the bin directory. >> So doing that seemed sane for backpatching,

Re: [HACKERS] Parallel Seq Scan

On Mon, Dec 22, 2014 at 7:34 AM, Jim Nasby wrote: > > On 12/21/14, 12:42 AM, Amit Kapila wrote: >> >> On Fri, Dec 19, 2014 at 6:21 PM, Stephen Frost mailto:sfr...@snowman.net>> wrote: >> a. Instead of passing value array, just pass tuple id, but retain the >> buffer pin till master backend reads t

Re: [HACKERS] no test programs in contrib

On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> On 11/27/14 3:10 PM, Tom Lane wrote: >> > I'm not too happy with that approach, because packagers are going to >> > tend to think they should package any files installed by install-world. >> > The entire point of t

Re: [HACKERS] Fractions in GUC variables

On Tue, Dec 16, 2014 at 12:19 AM, Peter Eisentraut wrote: > On 12/15/14 8:56 AM, Heikki Linnakangas wrote: >> Overall, I feel that this isn't really worth the trouble. We use >> fractions consistently now, so there isn't much room for confusion over >> what the current values mean. Using a percent

Re: [HACKERS] [PATCH] Add transforms feature

On Mon, Dec 15, 2014 at 3:10 PM, Peter Eisentraut wrote: > fixed This patch needs a rebase, it does not apply correctly in a couple of places on latest HEAD (699300a): ./src/include/catalog/catversion.h.rej ./src/include/catalog/pg_proc.h.rej ./src/pl/plpython/plpy_procedure.c.rej Regards, -- Mic

Re: [HACKERS] Re[3]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code

On Tue, Nov 4, 2014 at 6:25 AM, Alexey Vasiliev wrote: > Added new patch. Seems useful to me to be able to tune this interval of time. I would simply reword the documentation as follows: If restore_command returns nonzero exit status code, retry command after the interval of time specified by thi

Re: [HACKERS] Proposal "VACUUM SCHEMA"

Em segunda-feira, 22 de dezembro de 2014, Jim Nasby < jim.na...@bluetreble.com> escreveu: > On 12/21/14, 3:30 PM, Fabrízio de Royes Mello wrote: > >> >> On Sun, Dec 21, 2014 at 5:18 PM, Tom Lane > t...@sss.pgh.pa.us>> wrote: >> > >> > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= >

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

On 12/21/14, 7:08 PM, Ali Akbar wrote: Another positive benefit is that this won't break the code unless it uses the new API. This is a problem especially with external code (e.g. extensions), but the new API (initArray*) is not part of 9.4 so there's no such code. So that's nice.

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Dec 22, 2014 at 11:20 AM, Peter Geoghegan wrote: > On Sun, Dec 21, 2014 at 6:10 PM, Michael Paquier > wrote: >> Looking at this thread, the last version of this patch is available here: >> http://www.postgresql.org/message-id/CAM3SWZRvkCKc=1Y6_Wn8mk97_Vi8+j-aX-RY-=msrjvu-ec...@mail.gmail.

Re: [HACKERS] Proposal "VACUUM SCHEMA"

On 12/21/14, 3:30 PM, Fabrízio de Royes Mello wrote: On Sun, Dec 21, 2014 at 5:18 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: > > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= mailto:fabriziome...@gmail.com>> writes: > > I work with some customer that have databases with a lot of schemas and

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Sun, Dec 21, 2014 at 6:10 PM, Michael Paquier wrote: > Looking at this thread, the last version of this patch is available here: > http://www.postgresql.org/message-id/CAM3SWZRvkCKc=1Y6_Wn8mk97_Vi8+j-aX-RY-=msrjvu-ec...@mail.gmail.com > And they do not apply correctly, so this patch needs a reb

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Sun, Dec 21, 2014 at 6:56 AM, Peter Geoghegan wrote: > On Thu, Dec 18, 2014 at 9:31 AM, Peter Geoghegan wrote: >>> So I think there needs to be some kind of logic to de-recognize the table >>> alias "foo". >>> >>> Once I rewrote the query to use TARGET and EXCLUDED correctly, I've put this >>>

Re: [HACKERS] Parallel Seq Scan

On 12/21/14, 12:42 AM, Amit Kapila wrote: On Fri, Dec 19, 2014 at 6:21 PM, Stephen Frost mailto:sfr...@snowman.net>> wrote: a. Instead of passing value array, just pass tuple id, but retain the buffer pin till master backend reads the tuple based on tupleid. This has side effect that we have to r

Re: [HACKERS] Using 128-bit integers for sum, avg and statistics aggregates

On Tue, Dec 16, 2014 at 7:04 PM, David Rowley wrote: > It also looks like your OIDs have been nabbed by some jsonb stuff. > DETAIL: Key (oid)=(3267) is duplicated. Use src/include/catalog/unused_oids to track the OIDs not yet used in the catalogs when adding new objects for a feature. -- Michael

Re: [HACKERS] btree_gin and ranges

On Thu, Dec 18, 2014 at 4:13 AM, Heikki Linnakangas wrote: > On 10/22/2014 01:55 PM, Teodor Sigaev wrote: >> >> Suggested patch adds GIN support contains operator for ranges over scalar >> column. >> >> It allows more effective GIN scan. Currently, queries like >> SELECT * FROM test_int4 WHERE i <

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

> > Another positive benefit is that this won't break the code unless it > uses the new API. This is a problem especially with external code (e.g. > extensions), but the new API (initArray*) is not part of 9.4 so there's > no such code. So that's nice. > > The one annoying thing is that this makes

Re: [HACKERS] parallel mode and parallel contexts

On Thu, Dec 18, 2014 at 4:53 AM, Robert Haas wrote: > On Wed, Dec 17, 2014 at 9:16 AM, Simon Riggs wrote: >> On 12 December 2014 at 22:52, Robert Haas wrote: >> >>> I would be remiss if I failed to mention that this patch includes work >>> by my colleagues Amit Kapila, Rushabh Lathia, and Jeevan

Re: [HACKERS] TABLESAMPLE patch

On Mon, Dec 22, 2014 at 2:38 AM, Tomas Vondra wrote: > (1) The patch adds a new catalog, but does not bump CATVERSION. FWIW, this part is managed by the committer when this patch is picked up. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] pgbench -f and vacuum

Hi, On 21.12.2014 15:58, Tatsuo Ishii wrote: >> On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: If we care enough about that case to attempt the vacuum anyway then we need to do something about the error message; either squelch it or check for the existence of the tables befo

Re: [HACKERS] pgbench -f and vacuum

> - Error to apply to the current master: Works for me. $ git apply ~/pgbench-f-noexit-v2.patch $ Maybe git version difference or the patch file was malformed by mail client? > +static void executeStatement2(PGconn *con, const char *sql, const char > *table); > > I think we can use a better

Re: [HACKERS] Proposal "VACUUM SCHEMA"

On Sun, Dec 21, 2014 at 5:18 PM, Tom Lane wrote: > > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > > I work with some customer that have databases with a lot of schemas and > > sometimes we need to run manual VACUUM in one schema, and would be nice to > > have a new option to run vacuum in r

Re: [HACKERS] Final Patch for GROUPING SETS

On Sat, Dec 13, 2014 at 04:37:48AM +, Andrew Gierth wrote: > > "Tom" == Tom Lane writes: > > >> I'd already explained in more detail way back when we posted the > >> patch. But to reiterate: the ChainAggregate nodes pass through > >> their input data unchanged, but on group boundaries

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 12/21/2014 02:12 PM, Tom Lane wrote: Andrew Dunstan writes: On 12/21/2014 01:23 PM, Alvaro Herrera wrote: The point, I think, is that without atomic instructions you have to hold a lock while incrementing the counters. Hmm, do we do that now? We already have a spinlock mutex around the c

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

On 21.12.2014 20:19, Tomas Vondra wrote: > > However, I got a segfault on the very first query I tried :-( > > create table test_hash_agg as select i AS a, i AS b, i AS c, i AS d > from generate_series(1,1000) s(i); > > analyze test_hash_agg; > > select a, count(*) from test_hash_a

Re: [HACKERS] controlling psql's use of the pager a bit more

On 11/15/2014 05:56 PM, Andrew Dunstan wrote: On 11/13/2014 11:41 AM, Andrew Dunstan wrote: On 11/13/2014 11:09 AM, Tom Lane wrote: Andrew Dunstan writes: I often get annoyed because psql is a bit too aggressive when it decides whether to put output through the pager, and the only way to a

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

On 2.12.2014 06:14, Jeff Davis wrote: > On Sun, 2014-11-30 at 17:49 -0800, Peter Geoghegan wrote: >> On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis wrote: >>> I can also just move isReset there, and keep mem_allocated as a uint64. >>> That way, if I find later that I want to track the aggregated val

Re: [HACKERS] Proposal "VACUUM SCHEMA"

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > I work with some customer that have databases with a lot of schemas and > sometimes we need to run manual VACUUM in one schema, and would be nice to > have a new option to run vacuum in relations from a specific schema. I'm pretty skeptical of th

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

Andrew Dunstan writes: > On 12/21/2014 01:23 PM, Alvaro Herrera wrote: >> The point, I think, is that without atomic instructions you have to hold >> a lock while incrementing the counters. > Hmm, do we do that now? We already have a spinlock mutex around the counter adjustment code, so I'm not

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 12/21/2014 01:23 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: On my blog Peter Geoghegan mentioned something about "atomic fetch-and-add" being useful here, but I'm not quite sure what that's referring to. Perhaps someone can give me a pointer. The point, I think, is that without atomic

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On December 21, 2014 7:23:27 PM CET, Alvaro Herrera wrote: >Andrew Dunstan wrote: > >> On my blog Peter Geoghegan mentioned something about "atomic >fetch-and-add" >> being useful here, but I'm not quite sure what that's referring to. >Perhaps >> someone can give me a pointer. > >The point, I thi

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

Andrew Dunstan wrote: > On my blog Peter Geoghegan mentioned something about "atomic fetch-and-add" > being useful here, but I'm not quite sure what that's referring to. Perhaps > someone can give me a pointer. The point, I think, is that without atomic instructions you have to hold a lock while

Re: [HACKERS] PrivateRefCount patch has got issues

Andres Freund writes: > On 2014-12-16 18:25:13 -0500, Tom Lane wrote: >> I just happened to look into bufmgr.c for the first time in awhile, and >> noticed the privaterefcount-is-no-longer-a-simple-array stuff. It doesn't >> look too well thought out to me. In particular, PinBuffer_Locked calls

Re: [HACKERS] PrivateRefCount patch has got issues

Hi, On 2014-12-16 18:25:13 -0500, Tom Lane wrote: > I just happened to look into bufmgr.c for the first time in awhile, and > noticed the privaterefcount-is-no-longer-a-simple-array stuff. It doesn't > look too well thought out to me. In particular, PinBuffer_Locked calls > GetPrivateRefCountEnt

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

Tomas Vondra writes: > i.e. either destroy the whole context if possible, and just free the > memory when using a shared memory context. But I'm afraid this would > penalize the shared memory context, because that's intended for cases > where all the build states coexist in parallel and then at so

Re: [HACKERS] TABLESAMPLE patch

Hi, On 18.12.2014 13:14, Petr Jelinek wrote: > Hi, > > v2 version of this patch is attached. I did a review of this v2 patch today. I plan to do a bit more testing, but these are my comments/questions so far: (0) There's a TABLESAMPLE page at the wiki, not updated since 2012: https://wiki.

[HACKERS] Proposal "VACUUM SCHEMA"

Hi all, I work with some customer that have databases with a lot of schemas and sometimes we need to run manual VACUUM in one schema, and would be nice to have a new option to run vacuum in relations from a specific schema. The new syntax could be: VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] { [ tab

Re: [HACKERS] pgbench -f and vacuum

On Sun, Dec 21, 2014 at 12:58 PM, Tatsuo Ishii wrote: > > > On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: > >>> If we care enough about that case to attempt the vacuum anyway then we > >>> need to do something about the error message; either squelch it or > >>> check for the existence of

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 04/07/2014 04:19 PM, Tom Lane wrote: Alvaro Herrera writes: I just noticed that this patch not only adds min,max,stddev, but it also adds the ability to reset an entry's counters. This hasn't been mentioned in this thread at all; there has been no discussion on whether this is something we

Re: [HACKERS] pgbench -f and vacuum

> On Sun, Dec 14, 2014 at 11:43 AM, Tatsuo Ishii wrote: >>> If we care enough about that case to attempt the vacuum anyway then we >>> need to do something about the error message; either squelch it or >>> check for the existence of the tables before attempting to >>> vacuum. Since there's no way

Re: [HACKERS] PATCH: decreasing memory needlessly consumed by array_agg

On 21.12.2014 02:54, Alvaro Herrera wrote: > Tomas Vondra wrote: >> Attached is v5 of the patch, fixing an error with releasing a shared >> memory context (invalid flag values in a few calls). > > The functions that gain a new argument should get their comment updated, > to explain what the new ar