Re: [HACKERS] Bitmap index scans use of filters on available columns

On Fri, Nov 6, 2015 at 7:11 PM, Tomas Vondra wrote: >> I think LEAKPROOF is probably fine for this. How would the new thing >> be different? > > I don't think so - AFAIK "leakproof" is about not revealing information > about arguments, nothing more and nothing less.

Re: [HACKERS] Some questions about the array.

On 11/5/15 10:55 PM, Craig Ringer wrote: Omitted bounds are common in other languages and would be handy. I don't think they'd cause any issues with multi-dimensional arrays or variable start-pos arrays. +1 I'd love negative indexes, but the variable-array-start (mis)feature means we can't

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/3/15 8:44 AM, Merlin Moncure wrote: Actually, one other thing that would help is to have the ability to turn >this into an ERROR: > >begin; >WARNING: there is already a transaction in progress curious: does the SQL standard define this behavior? Anyways, we've pretty studiously avoided

[HACKERS] Minor regexp bug

Happened across this while investigating something else ... The regexp documentation says: Lookahead and lookbehind constraints cannot contain back references (see ), and all parentheses within them are considered non-capturing. This is true if you try a simple case, eg

Re: [HACKERS] Bitmap index scans use of filters on available columns

Hi, On 11/05/2015 07:36 PM, Robert Haas wrote: On Thu, Nov 5, 2015 at 1:29 PM, Tomas Vondra wrote: But then again, can we come up with a way to distinguish operators that are safe to evaluate on indexes - either automatic or manual? We already do that with the

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Aug 19, 2015 at 7:24 PM, Peter Geoghegan wrote: > I'll start a new thread for this, since my external sorting patch has > now evolved well past the original "quicksort with spillover" > idea...although not quite how I anticipated it would. It seems like > I've reached a

Re: [HACKERS] Parallel Seq Scan

On Fri, Oct 23, 2015 at 9:22 PM, Amit Kapila wrote: > The base rel's consider_parallel flag won't be percolated to childrels, so > even > if we mark base rel as parallel capable, while generating the path it won't > be considered. I think we need to find a way to pass on

Re: [HACKERS] nodes/*funcs.c inconsistencies

On Mon, Aug 3, 2015 at 10:00 AM, Alvaro Herrera wrote: >> Couldn't we adopt >> AssertVariableIsOfType()/AssertVariableIsOfTypeMacro() to macros like >> READ_UINT_FIELD()? >> >> I'm surprised that this stuff was only ever used for logical decoding >> infrastructure so

Re: [HACKERS] Bitmap index scans use of filters on available columns

Hi, On 11/07/2015 02:18 AM, Robert Haas wrote: On Fri, Nov 6, 2015 at 7:11 PM, Tomas Vondra wrote: I think LEAKPROOF is probably fine for this. How would the new thing be different? I don't think so - AFAIK "leakproof" is about not revealing information about

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Sat, Nov 7, 2015 at 1:52 AM, Andres Freund wrote: > On 2015-11-06 11:42:56 -0500, Robert Haas wrote: >> On Fri, Nov 6, 2015 at 2:47 AM, Michael Paquier >> wrote: >> > I have as well thought a bit about adding a space-related constraint >> > on

Re: [HACKERS] extend pgbench expressions with functions

1. It's really not appropriate to fold the documentation changes raised on the other thread into this patch. I'm not going to commit something where the commit message is a laundry list of unrelated changes. Please separate out the documentation changes as a separate patch. Let's do that

Re: [HACKERS] ALTER INDEX...SET tab completion

On Tue, Sep 8, 2015 at 4:23 PM, Jeff Janes wrote: > I can never remember the syntax for setting index storage parameters. Is it > =, TO, or just a space between the parameter name and the setting? > > This makes the tab completion more helpful, by providing the (mandatory)

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Sat, Nov 7, 2015 at 12:07 AM, Robert Haas wrote: > > On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat > wrote: > > The previous patch would not compile on the latest HEAD. Here's updated > > patch. > > Perhaps unsurprisingly, this doesn't

Re: [HACKERS] extend pgbench expressions with functions

Thanks. Part 1 looks, on the whole, fine to me, although I think the changes to use less whitespace and removing decimal places in the documentation are going in the wrong direction. That is: - About 67% of values are drawn from the middle 1.0 / threshold + About 67% of values

Re: [HACKERS] Bitmap index scans use of filters on available columns

On Fri, Nov 6, 2015 at 10:28 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > Hello, > > At Fri, 6 Nov 2015 09:49:30 +0530, Amit Kapila wrote in > > Apart from other problems

Re: [HACKERS] Minor regexp bug

On Fri, Nov 6, 2015 at 7:32 PM, Tom Lane wrote: > What I'm wondering about is whether to back-patch this. It's possible > that people have written patterns like this and not realized that they > aren't doing quite what's expected. Getting a failure instead might not > be

Re: [HACKERS] SortSupport for UUID type

Hello, I tried to look on this as far as I can referring to numeric.c.. 1. Patch application This patch applies on the current master cleanly. And looks to be work as expected. 2. uuid.c pg_bswap.h is included under hash.h so it is not needed to be included but I don't object if you

Re: [HACKERS] Some questions about the array.

On Thursday 05 November 2015 22:33:37 you wrote: > Would something like array[1:~1] as a syntax be acceptable to denote > backward counting? Very interesting idea! I could implement it. I just need to check for side effects. -- YUriy Zhuravlev Postgres Professional: http://www.postgrespro.com

Re: [HACKERS] Some questions about the array.

On Thursday 05 November 2015 23:45:53 you wrote: > On Thu, Nov 5, 2015 at 9:57 AM, YUriy Zhuravlev > > wrote: > > Hello hackers. > > There are comments to my patch? Maybe I should create a separate thread? > > Thanks. > > You should add this on

Re: [HACKERS] extend pgbench expressions with functions

Those can be avoided in other ways. For example: Ok, ok, I surrender:-) Here is a v15 which hides conversions and assignment details in macros and factors out type testing of overloaded operators so that the code expansion is minimal (basically the operator evaluation is duplicated for

Re: [HACKERS] [PATCH] RFC: Add length parameterised dmetaphone functions

Christian Marie wrote: > A developer I work with was trying to use dmetaphone to group people names > into > equivalence classes. He found that many long names would be grouped together > when they shouldn't be, this turned out to be because dmetaphone has an > undocumented upper bound on its

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

Hello again! Patches === I had implemented support for FLAG long, FLAG num and AF parameters. I attached patch to the e-mail (hunspell-dict.patch). This patch allow to use Hunspell dictionaries listed in the previous e-mail: ar, br_fr, ca, ca_valencia, en_ca, en_gb, en_us, fr, gl_es,

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

06.11.2015 12:33, Artur Zakirov пишет: Hello again! Patches === Link to commitfest: https://commitfest.postgresql.org/8/420/ -- Artur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] SortSupport for UUID type

On Thu, Nov 5, 2015 at 7:10 PM, Peter Geoghegan wrote: > On Thu, Oct 8, 2015 at 5:27 PM, Peter Geoghegan wrote: >> This is more or less lifted from numeric_abbrev_convert_var(). Perhaps >> you should change it there too. The extra set of parenthesis are >>

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On November 6, 2015 6:21:50 PM GMT+01:00, Robert Haas wrote: >On Fri, Nov 6, 2015 at 11:52 AM, Andres Freund >wrote: >> Seems like it'd be doable in ReserveXLogInsertLocation(). >> >> Whether it's actually worthwhile I'm not all that sure tho. > >Why

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Fri, Nov 6, 2015 at 9:42 AM, Kouhei Kaigai wrote: > This patch needs to be rebased. > One thing different from the latest version is fdw_recheck_quals of > ForeignScan was added. So, ... > > (1) Principle is that FDW driver knows what qualifiers were pushed down > and how

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Fri, Nov 6, 2015 at 11:52 AM, Andres Freund wrote: > On 2015-11-06 11:42:56 -0500, Robert Haas wrote: >> On Fri, Nov 6, 2015 at 2:47 AM, Michael Paquier >> wrote: >> > I have as well thought a bit about adding a space-related constraint >> > on

Re: [HACKERS] Adjust errorcode in background worker code

On Sun, Jun 28, 2015 at 10:43 PM, Amit Langote wrote: > On 2015-06-29 AM 11:36, Amit Langote wrote: >> Hi, >> >> How about the attached that adjusts errorcode for the error related to >> checking the flag bgw_flags in BackgroundWorkerInitializeConnection*() >>

Re: [HACKERS] SortSupport for UUID type

On Fri, Nov 6, 2015 at 9:19 AM, Robert Haas wrote: > This is a good catch, so I pushed a fix. Thanks for your help. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Friday, November 6, 2015 10:32 AM, Robert Haas wrote: > I think this approach is generally reasonable, but I suggested > parts of it, so may be biased. I would be interested in hearing > the opinions of others. Has anyone taken a close look at what happens if the two

Re: [HACKERS] patch for geqo tweaks

Nathan Wagner writes: > On Fri, Nov 06, 2015 at 11:45:38AM -0500, Tom Lane wrote: >> (There's a fair amount of dead code in /geqo/, which I've never had >> the energy to clean up, but maybe we should do that sometime. It >> seems unlikely that anyone will ever be

Re: [HACKERS] SortSupport for UUID type

On Fri, Nov 6, 2015 at 12:35 AM, Kyotaro HORIGUCHI wrote: > Hello, I tried to look on this as far as I can referring to > numeric.c.. Thank you for the review, Horiguchi-san. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Friday, November 06, 2015 9:40 PM > To: Kaigai Kouhei(海外 浩平) > Cc: Etsuro Fujita; Tom Lane; Kyotaro HORIGUCHI; pgsql-hackers@postgresql.org; >

Re: [HACKERS] Patch: Implement failover on libpq connect level.

Craig Ringer wrote: > On 6 November 2015 at 13:34, Robert Haas wrote: > > >> But some options control how > >> next host should be choosen (i.e. use random order for load-balancing > >> or sequential order for high availability), so they should be specified > >> only once

Re: [HACKERS] [BUGS] BUG #12989: pg_size_pretty with negative values

On Thu, Nov 5, 2015 at 4:19 PM, Adrian.Vondendriesch wrote: > New patch attached and rebased on HEAD > (8c75ad436f75fc629b61f601ba884c8f9313c9af). I've committed this with some modifications: - I changed the comment for the half_rounded() macros because the one

Re: [HACKERS] patch for geqo tweaks

Nathan Wagner writes: > I see you committed a modified version of my patch in commit > 59464bd6f928ad0da30502cbe9b54baec9ca2c69. > You changed the tour[0] to be hardcoded to 1, but it should be any of > the possible gene numbers from 0 to remainder. How so? The intent is

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Thu, Nov 5, 2015 at 11:54 PM, Ashutosh Bapat wrote: > Hi All, > PFA patch to get data sorted from the foreign server (postgres_fdw) > according to the pathkeys useful for merge join. > > For a given base relation (extendable to join when that becomes available

Re: [HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

On Fri, Nov 6, 2015 at 12:52 AM, Michael Paquier wrote: >> I guess I'm wondering whether there's really enough of this to need >> its own category. > > We have a category "Code comments" as well. Let's give it a shot so I > am adding it. We could always remove it later

Re: [HACKERS] CustomScan support on readfuncs.c

On Fri, Nov 6, 2015 at 2:02 AM, Kouhei Kaigai wrote: > I tried to split the previous version into two portions. > > - custom-scan-on-readfuncs.v2.patch > It allows to serialize/deserialize CustomScan node as discussed upthread. > Regarding of get_current_library_filename(),

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Fri, Nov 6, 2015 at 2:47 AM, Michael Paquier wrote: > I have as well thought a bit about adding a space-related constraint > on the standby snapshot generated by the bgwriter, so as to not rely > entirely on the interval of 15s. I finished with the attached that >

Re: [HACKERS] patch for geqo tweaks

Nathan Wagner writes: > On Wed, Nov 04, 2015 at 12:51:52PM -0500, Tom Lane wrote: >> I'm not very impressed with the first patch: it might save a few >> geqo_randint() calls, but it seems to do so at the price of making the >> swap choices less random --- for instance it

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On 2015-11-06 11:42:56 -0500, Robert Haas wrote: > On Fri, Nov 6, 2015 at 2:47 AM, Michael Paquier > wrote: > > I have as well thought a bit about adding a space-related constraint > > on the standby snapshot generated by the bgwriter, so as to not rely > > entirely on

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Wed, 23 Sep 2015 11:46:00 -0400 Robert Haas wrote: > On Wed, Sep 23, 2015 at 11:22 AM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev > >> wrote: > >>

Re: [HACKERS] SortSupport for UUID type

On Fri, Nov 6, 2015 at 3:35 AM, Kyotaro HORIGUCHI wrote: > Hello, I tried to look on this as far as I can referring to > numeric.c.. Oops, I didn't see this review before committing. > 6. uuid_abbrev_convert() > > > memcpy((char *) , authoritative->data,

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Nov 3, 2015 at 8:15 AM, Kouhei Kaigai wrote: > A challenge is that junk wholerow references on behalf of ROW_MARK_COPY > are injected by preprocess_targetlist(). It is earlier than the main path > consideration by query_planner(), thus, it is not predictable how

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Fri, Nov 6, 2015 at 12:26 PM, Andres Freund wrote: > On November 6, 2015 6:21:50 PM GMT+01:00, Robert Haas > wrote: >>On Fri, Nov 6, 2015 at 11:52 AM, Andres Freund >>wrote: >>> Seems like it'd be doable in

Re: [HACKERS] [BUGS] BUG #12989: pg_size_pretty with negative values

Am 06.11.2015 um 17:06 schrieb Robert Haas: > On Thu, Nov 5, 2015 at 4:19 PM, Adrian.Vondendriesch > wrote: >> New patch attached and rebased on HEAD >> (8c75ad436f75fc629b61f601ba884c8f9313c9af). > > I've committed this with some modifications: > > - I changed

Re: [HACKERS] extend pgbench expressions with functions

On Fri, Nov 6, 2015 at 5:00 AM, Fabien COELHO wrote: >> Those can be avoided in other ways. For example: > > Ok, ok, I surrender:-) > > Here is a v15 which hides conversions and assignment details in macros and > factors out type testing of overloaded operators so that the

Re: [HACKERS] [BUGS] BUG #12989: pg_size_pretty with negative values

On Fri, Nov 6, 2015 at 12:44 PM, Adrian Vondendriesch wrote: > Am 06.11.2015 um 17:06 schrieb Robert Haas: >> On Thu, Nov 5, 2015 at 4:19 PM, Adrian.Vondendriesch >> wrote: >>> New patch attached and rebased on HEAD >>>

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev wrote: > There is a patch that splits SLRU LWLocks to separate tranches and > moves them to SLRU Ctl. It does some work from the main patch from > this thread, but can be commited separately. It also simplifies >

Re: [HACKERS] patch for geqo tweaks

On Fri, Nov 06, 2015 at 11:19:00AM -0500, Tom Lane wrote: > Nathan Wagner writes: > > I see you committed a modified version of my patch in commit > > 59464bd6f928ad0da30502cbe9b54baec9ca2c69. > > > You changed the tour[0] to be hardcoded to 1, but it should be any > > of

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat wrote: > The previous patch would not compile on the latest HEAD. Here's updated > patch. Perhaps unsurprisingly, this doesn't apply any more. But we have bigger things to worry about. The recent eXtensible

Re: [HACKERS] patch for geqo tweaks

On Fri, Nov 06, 2015 at 11:45:38AM -0500, Tom Lane wrote: > However, really the whole argument is moot, because I notice that > geqo_mutation() is only called in the "#ifdef CX" code path, which > we don't use. I suppose someone could turn it on via a compiler define. > So there's little point

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, On 11/06/2015 03:38 PM, Andres Freund wrote: While I saw an improvement for the 'synchronous_commit = on' case - there is a small regression for 'off', using -M prepared + Unix Domain Socket. If that is something that should be considered right now. What tests where you running, in which

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 10/29/2015 01:18 PM, Alexander Korotkov wrote: We got a consensus with Andres that we should commit the CAS version first and look to other optimizations. Refactored version of atomic state patch is attached. The changes are following: 1) Macros are used for access refcount and usagecount. 2)

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, On November 6, 2015 9:31:37 PM GMT+01:00, Jesper Pedersen wrote: >I have been testing this on a smaller system than yours - 2 socket >Intel(R) Xeon(R) CPU E5-2683 v3 w/ 2 x RAID10 SSD disks (data + xlog), >so focused on a smaller number of clients. Thanks for

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, 1. It's really not appropriate to fold the documentation changes raised on the other thread into this patch. I'm not going to commit something where the commit message is a laundry list of unrelated changes. Please separate out the documentation changes as a separate patch.

Re: [HACKERS] Better name for PQsslAttributes()

On Fri, Nov 6, 2015 at 10:38 PM, Heikki Linnakangas wrote: > On 11/06/2015 11:31 PM, Lars Kanis wrote: > >> As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to >> bridge the new SSL related functions to Ruby methods. However I wonder >> whether

Re: [HACKERS] patch for geqo tweaks

On Fri, Nov 06, 2015 at 02:16:41PM -0500, Tom Lane wrote: > Uh, what? It's not by any means turned off by default. > > postgres=# select name,setting from pg_settings where name like '%geqo%'; > name | setting > -+- > geqo| on [snip]

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Fri, Nov 6, 2015 at 10:38 AM, Alvaro Herrera wrote: > Craig Ringer wrote: >> On 6 November 2015 at 13:34, Robert Haas wrote: >> >> >> But some options control how >> >> next host should be choosen (i.e. use random order for load-balancing >> >>

Re: [HACKERS] patch for geqo tweaks

On 07/11/15 09:59, Nathan Wagner wrote: [...] My day to make a fool of myself in public I guess. You're right of course. I can only plead distraction by having too many projects in mind at once and not focusing properly. Sorry for taking up your time on things I should have checked better.

Re: [HACKERS] extend pgbench expressions with functions

On Fri, Nov 6, 2015 at 3:44 PM, Fabien COELHO wrote: >> 1. It's really not appropriate to fold the documentation changes >> raised on the other thread into this patch. I'm not going to commit >> something where the commit message is a laundry list of unrelated >> changes.

[HACKERS] Better name for PQsslAttributes()

As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to bridge the new SSL related functions to Ruby methods. However I wonder whether PQsslAttributes() is the best name for the function. Based on this name, I would expect to get key+value pairs instead of only the keys. IMHO

Re: [HACKERS] Better name for PQsslAttributes()

On 11/06/2015 11:31 PM, Lars Kanis wrote: As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to bridge the new SSL related functions to Ruby methods. However I wonder whether PQsslAttributes() is the best name for the function. Based on this name, I would expect to get key+value

Re: [HACKERS] Better name for PQsslAttributes()

On Fri, Nov 6, 2015 at 1:38 PM, Heikki Linnakangas wrote: > Thoughts? I'm leaning towards changing it now. +1 to the idea of changing it. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] a raft of parallelism-related bug fixes

On Mon, Nov 2, 2015 at 9:29 PM, Robert Haas wrote: > On Wed, Oct 28, 2015 at 10:23 AM, Robert Haas wrote: >> On Sun, Oct 18, 2015 at 12:17 AM, Robert Haas wrote: So reviewing patch 13 isn't possible without prior

Re: [HACKERS] Better name for PQsslAttributes()

Heikki Linnakangas writes: > On 11/06/2015 11:31 PM, Lars Kanis wrote: >> As a co-maintainer of the PostgreSQL adapter for Ruby, I would like to >> bridge the new SSL related functions to Ruby methods. However I wonder >> whether PQsslAttributes() is the best name for the