Re: [HACKERS] Parallel Seq Scan

On Fri, Dec 19, 2014 at 6:21 PM, Stephen Frost wrote: > > Amit, > > * Amit Kapila (amit.kapil...@gmail.com) wrote: > > 1. Parallel workers help a lot when there is an expensive qualification > > to evaluated, the more expensive the qualification the more better are > > results. > > I'd certainly h

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

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 argument is for. Also, what is it with this hunk? > @

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Sat, Dec 20, 2014 at 3:17 PM, Peter Geoghegan wrote: > Attached patch implements this scheme. I had another thought: "NAMEDATALEN + 1" is a better representation of "infinity" for matching purposes than INT_MAX. I probably should have made that change, too. It would then not have been necessar

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

On Tue, Dec 16, 2014 at 12:18 PM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> So my two cents is that when considering a qualified name, this patch >> should take levenshtein distance across the two components equally. >> There's no good reason to suppose that typos will attac

Re: [HACKERS] Role Attribute Bitmask Catalog Representation

Alvaro and Stephen, I propose this patch on top of Adam's v5. Also included is a full patch > against master. > I have attached an updated patch for review (role-attribute-bitmask-v7.patch). This patch incorporates the 'v5a' patch proposed by Alvaro, input validation (Assert) check in 'check_ro

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

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 >> through an adaptation of my usual torture test, and it ran fine

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

On Sat, Dec 20, 2014 at 2:16 AM, Martijn van Oosterhout wrote: >> What I find curious about the opclass thing is: when do you ever have >> an opclass that has a different idea of equality than the default >> opclass for the type? In other words, when is B-Tree strategy number 3 >> not actually '='

Re: [HACKERS] GiST kNN search queue (Re: KNN-GiST with recheck)

On Wed, Dec 17, 2014 at 6:07 AM, Heikki Linnakangas wrote: > How about adding a src/backend/lib/README for that, per attached? I took a quick look at this. Some observations: * I like the idea of adding a .../lib README. However, the README fails to note that ilist.c implements an *integrated* l

Re: hash_create API changes (was Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber)

On 12/20/14, 11:51 AM, Tom Lane wrote: Andres Freund writes: On 2014-12-19 22:03:55 -0600, Jim Nasby wrote: What I am thinking is not using all of those fields in their raw form to calculate the hash value. IE: something analogous to: hash_any(SharedBufHash, (rot(forkNum, 2) | dbNode) ^ relNo

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

Attached is v5 of the patch, fixing an error with releasing a shared memory context (invalid flag values in a few calls). kind regards Tomas Vondra diff --git a/src/backend/executor/nodeSubplan.c b/src/backend/executor/nodeSubplan.c index d9faf20..9c97755 100644 --- a/src/backend/executor/nodeSubp

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

Hi! First of all, thanks for the review - the insights and comments are spot-on. More comments below. On 20.12.2014 09:26, Ali Akbar wrote: > > 2014-12-16 11:01 GMT+07:00 Ali Akbar >: > > > > 2014-12-16 10:47 GMT+07:00 Ali Akbar

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 20.12.2014 19:35, Tom Lane wrote: > Tomas Vondra writes: >> On 20.12.2014 19:05, Tom Lane wrote: >>> I am betting that you recreated them differently from before. > >> And you're probably right. Apparently, I recreated them like this: > >> $ localedef -v -c -i cs_CZ -f WIN-1250 cs_CZ.WI

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 20.12.2014 07:39, Noah Misch wrote: > Buildfarm members magpie, treepie and fulmar went absent on > 2014-10-29. Since returning on 2014-11-16, they have consistently > failed with 'initdb: invalid locale name "cs_CZ.WIN-1250"'. No > commits in that period readily explain a regression in this are

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

Tomas Vondra writes: > On 20.12.2014 19:05, Tom Lane wrote: >> I am betting that you recreated them differently from before. > And you're probably right. Apparently, I recreated them like this: > $ localedef -v -c -i cs_CZ -f WIN-1250 cs_CZ.WIN-1250 > but the correct way seems to be this:

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 20.12.2014 19:05, Tom Lane wrote: > Tomas Vondra writes: >> I believe the locale system (at the OS level) works just like before. I >> remember I had to manually create the locales while initially setting up >> the animals. Then, ~2 months ago something happened (I asssume a yum >> update) and

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

Tomas Vondra writes: > But clearly, something changed between RH 6.5 and 6.6, because on 6.5 I > get this: > $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC > , > � > 3;3 > 44 > 160 > CP1250 > while on 6.6 I get this: > $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC > , > 3;3 > 44 > 160 > ANSI_X3.4-1968 T

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

Tomas Vondra writes: > I believe the locale system (at the OS level) works just like before. I > remember I had to manually create the locales while initially setting up > the animals. Then, ~2 months ago something happened (I asssume a yum > update) and some of the locales disappeared. But I have

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 20.12.2014 18:32, Tom Lane wrote: > Tomas Vondra writes: >> On 20.12.2014 18:13, Pavel Stehule wrote: >>> It is Microsoft encoding, - it is not available on Linux > >> Not true. It is available on Linux, and the regression tests were >> running with it for a long time (essentially from the mo

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 20.12.2014 17:48, Noah Misch wrote: > On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote: >> On 20.12.2014 07:39, Noah Misch wrote: >>> Buildfarm members magpie, treepie and fulmar went absent on >>> 2014-10-29. Since returning on 2014-11-16, they have consistently >>> failed with 'initdb: in

Re: hash_create API changes (was Re: [HACKERS] speedup tidbitmap patch: hash BlockNumber)

Andres Freund writes: > On 2014-12-19 22:03:55 -0600, Jim Nasby wrote: >> What I am thinking is not using all of those fields in their raw form to >> calculate the hash value. IE: something analogous to: >> hash_any(SharedBufHash, (rot(forkNum, 2) | dbNode) ^ relNode) << 32 | >> blockNum) >> >>

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 12/20/2014 12:32 PM, Tom Lane wrote: Immediate recommendation is to restart the buildfarm critters with the missing locale removed from their configurations. If you can find the locale again somewhere, by all means re-enable it, but better less testing than no testing in the meantime.

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

Tomas Vondra writes: > On 20.12.2014 18:13, Pavel Stehule wrote: >> It is Microsoft encoding, - it is not available on Linux > Not true. It is available on Linux, and the regression tests were > running with it for a long time (essentially from the moment magpie was > added to the buildfarm). We

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

2014-12-20 18:17 GMT+01:00 Tomas Vondra : > On 20.12.2014 18:13, Pavel Stehule wrote: > > > > 2014-12-20 17:48 GMT+01:00 Noah Misch > > > $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC > > > > > > It is Microsoft encoding, - it is not available on Linux > > Not true. It is available on Linux, and th

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On 20.12.2014 18:13, Pavel Stehule wrote: > > 2014-12-20 17:48 GMT+01:00 Noah Misch > $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC > > > It is Microsoft encoding, - it is not available on Linux Not true. It is available on Linux, and the regression tests were running with it for a long time (es

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

2014-12-20 17:48 GMT+01:00 Noah Misch : > On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote: > > On 20.12.2014 07:39, Noah Misch wrote: > > > Buildfarm members magpie, treepie and fulmar went absent on > > > 2014-10-29. Since returning on 2014-11-16, they have consistently > > > failed with 'i

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

Noah Misch writes: > On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote: >> On 20.12.2014 07:39, Noah Misch wrote: >>> Buildfarm members magpie, treepie and fulmar went absent on >>> 2014-10-29. Since returning on 2014-11-16, they have consistently >>> failed with 'initdb: invalid locale name "

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 12/19/2014 10:41 AM, Alex Shulgin wrote: I don't think so. The scenario this patch relies on assumes that the DBA will remember to look in the log if something goes wrong, and in your case there would be a message like the following: WARNING: pg_hba.conf not reloaded So an extra hint about

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote: > On 20.12.2014 07:39, Noah Misch wrote: > > Buildfarm members magpie, treepie and fulmar went absent on > > 2014-10-29. Since returning on 2014-11-16, they have consistently > > failed with 'initdb: invalid locale name "cs_CZ.WIN-1250"'. No >

Re: [HACKERS] POLA violation with \c service=

On Fri, Dec 19, 2014 at 07:03:36PM -0700, David Johnston wrote: > On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] < > ml-node+s1045698n5831124...@n5.nabble.com> wrote: > > > On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote: > > > > > > > > On 12/17/2014 04:11 AM, Heikk

Re: [HACKERS] Table-level log_autovacuum_min_duration

On Thu, Dec 18, 2014 at 11:15 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> Hi all, >> >> Today I spent a bit of time looking at the activity of autovacuum for >> one table particularly bloated. log_autovacuum_min_duration was >> enabled and set to a high value but even with that I had to

Re: [HACKERS] Re: [pgsql-pkg-debian] Updated libpq5 packages cause connection errors on postgresql 9.2

On Fri, Dec 19, 2014 at 3:57 PM, Tom Lane wrote: > > Magnus Hagander writes: > > On Fri, Dec 19, 2014 at 11:52 AM, Christoph Berg wrote: > >> Googling for "digest too big for rsa key" seems to indicate that this > >> problem occurs when you are using (client?) certificates with short > >> RSA ke

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On Wed, Dec 17, 2014 at 11:32 AM, Amit Kapila wrote: > On Tue, Dec 16, 2014 at 10:11 PM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > > > > On 12/16/2014 06:30 PM, Andrew Dunstan wrote: > >> > >> I'm not clear why human readability is the major criterion here. As for > >> that, it will b

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

On Fri, Dec 19, 2014 at 05:32:43PM -0800, Peter Geoghegan wrote: > > Most people would list the columns, but if there is a really bizarre > > constraint, with non-default opclasses, or an exclusion constraint, it's > > probably been given a name that you could use. > > What I find curious about th

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

2014-12-16 11:01 GMT+07:00 Ali Akbar : > > > > 2014-12-16 10:47 GMT+07:00 Ali Akbar : >> >> >> 2014-12-16 6:27 GMT+07:00 Tomas Vondra : >> Just fast-viewing the patch. >> >> The patch is not implementing the checking for not creating new context >> in initArrayResultArr. I think we should implement

Re: [HACKERS] New Python vs. old PG on raccoon and jaguarundi

* From: Noah Misch [mailto:n...@leadboat.com] > Buildfarm member jaguarundi, which has Python 3.4, activated --with- > python for REL9_1_STABLE as of its 2014-12-15 run. Please remove -- > with-python or test against an older Python. It already omits --with- > python for REL9_0_STABLE. Done; so