[HACKERS] Race condition when starting and stopping test server in TestLib.pm?

Hi all, Within the last couple of days hamster has failed twice when running TAP tests because it was not able to start a test server with start_test_server: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-04-30%2019%3A07%3A31 http://buildfarm.postgresql.org/cgi-bin/show_log

Re: [HACKERS] alter user/role CURRENT_USER

Hello, At Thu, 30 Apr 2015 17:12:25 -0300, Alvaro Herrera wrote in <20150430201225.gv4...@alvh.no-ip.org> > Kyotaro HORIGUCHI wrote: > > Thank you for completing this and very sorry not to respond these > > days. > > > > I understood that it is committed after I noticed that rebasing > > my cod

Re: [HACKERS] Make more portable TAP tests of initdb

On Thu, Apr 30, 2015 at 12:17 PM, Noah Misch wrote: > On Wed, Apr 15, 2015 at 02:59:55PM +0900, Michael Paquier wrote: >> On Wed, Apr 15, 2015 at 2:38 PM, Noah Misch wrote: >> > Solaris 10 ships Perl 5.8.4, and RHEL 5.11 ships Perl 5.8.8. Therefore, >> > Perl >> > installations lacking this File

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On Thu, Apr 30, 2015 at 7:00 PM, Heikki Linnakangas wrote: > To fix that, we need to fix the "livelock insurance" check so that A does > not wait for B here. Because B is not a speculative insertion, A should > cancel its speculative insertion and retry instead. (I pushed the one-line > fix for th

Re: [HACKERS] feature freeze and beta schedule

On Fri, May 1, 2015 at 1:55 AM, Robert Haas wrote: > On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut wrote: >> On 4/30/15 12:01 PM, Robert Haas wrote: >>> So generally we have stamped in late April or early May and released >>> in September, but last year we didn't release until December. I >

Re: [HACKERS] Faster setup_param_list() in plpgsql

Review: What this patch does - it change a mechanism, how a values of variables are transmitted to SPI. In previous variant values are copied to ParamListInfo before every evaluation of any expression. New mechanism is smarter. It refresh only ROW, REC values when are marked as dirty (when these v

Re: [HACKERS] pg_rewind test race condition..?

On 04/29/2015 06:03 AM, Stephen Frost wrote: * Heikki Linnakangas (hlinn...@iki.fi) wrote: --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -7173,7 +7173,10 @@ StartupXLOG(void) * than is appropriate now that we're not in standby mode anymore.

Re: [HACKERS] BuildTupleFromCStrings Memory Documentation?

Jason Petersen writes: > Within the core codebase, BuildTupleFromCStrings is often called within a > temporary memory context cleared after the call. In dblink.c, this is > justified as being needed to “[clean up] not only the data we have direct > access to, but any cruft the I/O functions m

Re: [HACKERS] transforms vs. CLOBBER_CACHE_ALWAYS

On 4/30/15 2:49 PM, Andrew Dunstan wrote: > friarbird is a FreeBSD buildfarm animal running with > -DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours. > However, it's been stuck since Monday running the plpython regression > tests. The only relevant commit seems to be the transfo

Re: [HACKERS] shared_libperl, shared_libpython

On 4/28/15 11:48 PM, Tom Lane wrote: >> My preference would be to rip all that out and let the compiler or >> linker decide when it doesn't want to link something. > > Works for me, assuming that we get an understandable failure message and > not, say, a plperl.so that mysteriously doesn't work.

Re: [HACKERS] Reducing tuple overhead

On Thu, Apr 30, 2015 at 7:24 PM, Robert Haas wrote: > > On Thu, Apr 30, 2015 at 9:46 AM, Amit Kapila wrote: > > As the index expression contain table columns and all the functions > > or operators used in expression must be IMMUTABLE, won't that > > guarantee to avoid such a situation? > > The co

Re: [HACKERS] initdb -S and tablespaces

At 2015-04-30 16:56:17 -0700, t...@sss.pgh.pa.us wrote: > > As for the notion that this needs to be back-patched, I would say no. Not even just the "fsync after crash" part? I could separate that out from the control file changes and try to eliminate the duplication. I think that would be worth ba

Re: [HACKERS] initdb -S and tablespaces

At 2015-04-30 15:37:44 -0400, robertmh...@gmail.com wrote: > > 1. It doesn't do that. As soon as we fsync the data directory, we >reset the flag. That's not what "ever disabled" means to me. Could you suggest an acceptable alternative wording? I can't immediately think of anything better tha

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

It is done Dne 1.5.2015 3:11 napsal uživatel "Bruce Momjian" : > On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote: > > On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule > wrote: > > > 1. funcname_signature_string > > > 2. get_rule_expr > > > > Thanks. Patch attached. I'll commit this if

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Fri, May 1, 2015 at 1:38 AM, Robert Haas wrote: > On Thu, Apr 30, 2015 at 9:15 AM, Sawada Masahiko > wrote: >> On Thu, Apr 30, 2015 at 8:39 PM, Robert Haas wrote: >>> On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko >>> wrote: Attached v10 patch is latest version patch. The synta

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 04/27/2015 11:02 PM, Peter Geoghegan wrote: On Mon, Apr 27, 2015 at 8:31 PM, Heikki Linnakangas wrote: I thought we had an ironclad scheme to prevent deadlocks like this, so I'd like to understand why that happens. Okay. I think I know how it happens (I was always skeptical of the idea th

Re: [HACKERS] procost for to_tsvector

On Wed, Mar 11, 2015 at 02:40:16PM +, Andrew Gierth wrote: > An issue that comes up regularly on IRC is that text search queries, > especially on relatively modest size tables or for relatively > non-selective words, often misplan as a seqscan based on the fact that > to_tsvector has procost=1.

Re: [HACKERS] PATCH: adaptive ndistinct estimator v4

On 05/01/15 00:18, Robert Haas wrote: On Thu, Apr 30, 2015 at 5:31 PM, Heikki Linnakangas wrote: You can override the ndistinct estimate with ALTER TABLE. I think that's enough for an escape hatch. I'm not saying that isn't nice to have, but I don't think it really helps much here. Setting

Re: [HACKERS] PATCH: adaptive ndistinct estimator v4

Hi, On 04/30/15 22:57, Robert Haas wrote: On Tue, Mar 31, 2015 at 3:02 PM, Tomas Vondra wrote: attached is v4 of the patch implementing adaptive ndistinct estimator. So, I took a look at this today. It's interesting work, but it looks more like a research project than something we can commit

Re: [HACKERS] Final Patch for GROUPING SETS

On Thu, Apr 30, 2015 at 05:35:26AM +0100, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > >> + * TODO: AGG_HASHED doesn't support multiple grouping sets yet. > > Andres> Are you intending to resolve this before an eventual commit? > > Original plan was to tackle AGG_H

Re: [HACKERS] proposal: disallow operator "=>" and use it for named parameters

On Tue, Mar 10, 2015 at 02:51:30PM -0400, Robert Haas wrote: > On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule > wrote: > > 1. funcname_signature_string > > 2. get_rule_expr > > Thanks. Patch attached. I'll commit this if there are no objections. Robert, are you going to apply this? -- Bru

Re: [HACKERS] transforms vs. CLOBBER_CACHE_ALWAYS

* Andrew Dunstan: friarbird is a FreeBSD buildfarm animal running with -DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours. However, it's been stuck since Monday running the plpython regression tests. The only relevant commit seems to be the transforms feature. Here's what it's

[HACKERS] BuildTupleFromCStrings Memory Documentation?

Within the core codebase, BuildTupleFromCStrings is often called within a temporary memory context cleared after the call. In dblink.c, this is justified as being needed to “[clean up] not only the data we have direct access to, but any cruft the I/O functions might leak”.I wrote a pretty minimal c

Re: [HACKERS] One question about security label command

2015-05-01 7:40 GMT+09:00 Alvaro Herrera : > Kouhei Kaigai wrote: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> > > The idea of making the regression test entirely independent of the >> > > system's policy would presumably solve this problem, so I'd kind of >> > > like to see progress on that fron

Re: [HACKERS] Use outerPlanState() consistently in executor code

Robert Haas writes: > Yeah, that seems fine. Anyone want to object to this? This hunk: @@ -299,6 +301,7 @@ ExecReScanSort(SortState *node) return; /* must drop pointer to sort result tuple */ + outerPlan = outerPlanState(node); ExecClearTuple(node->ss.ps.p

Re: [HACKERS] initdb -S and tablespaces

Robert Haas writes: > On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera > wrote: >> Ah, so that's not the duplicate code that I was remembering -- I think >> it's walkdir() or something like that, which is in initdb IIRC. > Yeah, walkdir() is there too. But if we're going to add that to the > bac

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Thu, Apr 30, 2015 at 1:44 PM, Qingqing Zhou wrote: > On Thu, Apr 30, 2015 at 8:02 AM, Robert Haas wrote: >> I don't mind the MSDOS newlines, but the UTF-16le bit is inconvenient. >> UTF-8 would be much better, so I don't have to figure out how to >> convert. >> > > The patch is generated via g

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera >> wrote: >> >> Also, it seems awfully unfortunate to me that we're duplicating a >> >> whole pile of code into xlog.c here. Maybe there's no way to avoid >> >> the code

Re: [HACKERS] Broken handling of NULLs in TG_ARGV

Jim Nasby writes: > plpgsql's handling of NULLs in TG_ARGV turns actual nulls into text > 'null'. Hopefully we can all agree that's broken. You apparently have not read the CREATE TRIGGER reference page very carefully: arguments An optional comma-separated list of argum

[HACKERS] Broken handling of NULLs in TG_ARGV

plpgsql's handling of NULLs in TG_ARGV turns actual nulls into text 'null'. Hopefully we can all agree that's broken. I'd like to fix it, but wonder how to handle existing user code. My suspicion is that most users will never notice this and I can just fix it. I could also add a plpgsql opti

Re: [HACKERS] collations in shared catalogs?

On Thu, Apr 30, 2015 at 08:16:09AM -0700, Tom Lane wrote: > Bruce Momjian writes: > On 2015-02-25 12:08:32 -0500, Tom Lane wrote: > > The most obvious fix is to change "provider" to a NAME column. > > > Where are we on this? > > Not done yet, but we should make a point of making that fi

Re: [HACKERS] initdb -S and tablespaces

Robert Haas wrote: > On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera > wrote: > >> Also, it seems awfully unfortunate to me that we're duplicating a > >> whole pile of code into xlog.c here. Maybe there's no way to avoid > >> the code duplication, but pre_sync_fname() seems like it'd more > >> na

Re: [HACKERS] One question about security label command

Stephen Frost wrote: Hi, > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > Could you provide a buildfarm animal that runs the sepgsql test in all > > branches on a regular basis? > > Would be great if KaiGai can, of course, but I'm planning to stand one > up here soon in any case. I don

Re: [HACKERS] One question about security label command

Kouhei Kaigai wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > The idea of making the regression test entirely independent of the > > > system's policy would presumably solve this problem, so I'd kind of > > > like to see progress on that front. > > > > Apologies, I guess it wasn't clear, b

[HACKERS] Implementing SQL ASSERTION

Hi all, I’m wondering if there are other people out there working on implementing SQL ASSERTION functionality? I’ve recently spent a bit of time looking to implement the execution models described in “Applied Mathematics for Database Professionals” by Toon Koppelaars and Lex de Haan. I’ve got

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera wrote: >> Also, it seems awfully unfortunate to me that we're duplicating a >> whole pile of code into xlog.c here. Maybe there's no way to avoid >> the code duplication, but pre_sync_fname() seems like it'd more >> naturally go in fd.c than here.

Re: [HACKERS] PATCH: adaptive ndistinct estimator v4

On Thu, Apr 30, 2015 at 5:31 PM, Heikki Linnakangas wrote: > On 04/30/2015 01:57 PM, Robert Haas wrote: >> 2. There should be a compatibility GUC to restore the old behavior. >> The new behavior should be the default, because if we're not confident >> that the new behavior will be better for most

Re: [HACKERS] initdb -S and tablespaces

Robert Haas wrote: > Also, it seems awfully unfortunate to me that we're duplicating a > whole pile of code into xlog.c here. Maybe there's no way to avoid > the code duplication, but pre_sync_fname() seems like it'd more > naturally go in fd.c than here. I dunno where walkdir should go, but > a

Re: [HACKERS] PATCH: adaptive ndistinct estimator v4

On 04/30/2015 01:57 PM, Robert Haas wrote: 2. There should be a compatibility GUC to restore the old behavior. The new behavior should be the default, because if we're not confident that the new behavior will be better for most people, we have no business installing it in the first place (plus f

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> On Thu, Apr 30, 2015 at 9:16 AM, Kouhei Kaigai wrote: > > It seems to me the code block for T_ForeignScan and T_CustomScan in > > setrefs.c are a bit large. It may be better to have a separate > > function like T_IndexOnlyScan. > > How about your opinion? > > Either way is OK with me. Please d

Re: [HACKERS] PATCH: adaptive ndistinct estimator v4

On Tue, Mar 31, 2015 at 3:02 PM, Tomas Vondra wrote: > attached is v4 of the patch implementing adaptive ndistinct estimator. So, I took a look at this today. It's interesting work, but it looks more like a research project than something we can commit to 9.5. As far as I can see, this still co

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

On 12/20/14 12:11 PM, Steve Singer wrote: > 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: >> >> WA

Re: [HACKERS] pgbench -f and vacuum

On Thu, Apr 30, 2015 at 4:17 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes wrote: >>> But as far as what has been discussed on the central topic of this thread, I >>> think that doing the vacuum and making the failure for non-existent tables >>> be non-

Re: [HACKERS] pgbench -f and vacuum

Robert Haas writes: > On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes wrote: >> But as far as what has been discussed on the central topic of this thread, I >> think that doing the vacuum and making the failure for non-existent tables >> be non-fatal when -f is provided would be an improvement. Or m

Re: [HACKERS] alter user/role CURRENT_USER

Kyotaro HORIGUCHI wrote: > Thank you for completing this and very sorry not to respond these > days. > > I understood that it is committed after I noticed that rebasing > my code failed.. You'd do well to check your email, I guess :-) > Although after committed, I found some issues as I looked o

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

Robert Haas writes: > Tom, you're listed as the committer for this in the CF app. Are you > still planning to take care of this? > It seems that time is beginning to run short. Yeah, I will address this (and start looking at GROUPING SETS) next week. I'm out of town right now.

Re: [HACKERS] pgbench -f and vacuum

On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes wrote: > But as far as what has been discussed on the central topic of this thread, I > think that doing the vacuum and making the failure for non-existent tables > be non-fatal when -f is provided would be an improvement. Or maybe just > making it non-

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On Thu, Apr 16, 2015 at 2:55 AM, Etsuro Fujita wrote: > Ah, you are right. FOR NO KEY UPDATE and FOR KEY SHARE would be useful in > the Postgres FDW if we assume the user performs those properly based on > information about keys for a remote table. > > Sorry, my explanation was not correct, but I

Re: [HACKERS] initdb -S and tablespaces

On Thu, Apr 16, 2015 at 9:24 AM, Abhijit Menon-Sen wrote: > Here's a variation of the earlier patch that follows all links in > PGDATA. Does this look more like what you had in mind? I'm really confused by the additional control-file field. It is documented as indicating whether fsync was ever d

Re: [HACKERS] parallel mode and parallel contexts

On Wed, Apr 29, 2015 at 12:23 PM, Robert Haas wrote: > So, I think it makes sense to split up this patch in two. There's no > real debate, AFAICS, about anything in the patch other than the > heavyweight locking stuff. So I'd like to go ahead and commit the > rest. That's attached here as paral

Re: [HACKERS] ERROR: unexpected data beyond EOF

On 04/30/2015 12:09 PM, Alvaro Herrera wrote: Joshua D. Drake wrote: I take that back, it appears this table is heavily deleted from and also uses the lo_manage() triggers. Well, if it's heavily deleted, then it's probably also heavily vacuumed and from time to time empty pages at the tail

Re: [HACKERS] ERROR: unexpected data beyond EOF

Joshua D. Drake wrote: > > I take that back, it appears this table is heavily deleted from and also > uses the lo_manage() triggers. Well, if it's heavily deleted, then it's probably also heavily vacuumed and from time to time empty pages at the tail are removed by vacuum. It might also be the c

Re: [HACKERS] ERROR: unexpected data beyond EOF

I take that back, it appears this table is heavily deleted from and also uses the lo_manage() triggers. -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the w

Re: [HACKERS] Faster setup_param_list() in plpgsql

2015-04-29 9:26 GMT+02:00 Pavel Stehule : > Hi all > > I am looking on this patch. I can confirm 10-15% speedup - and the idea > behind this patch looks well. > > This patch > http://www.postgresql.org/message-id/4146.1425872...@sss.pgh.pa.us > contains two parts > > a) relative large refactoring

Re: [HACKERS] ERROR: unexpected data beyond EOF

On 04/30/2015 10:28 AM, Alvaro Herrera wrote: Joshua D. Drake wrote: Alright folks, So I have this error: postgres[21118]: [8-1] ERROR: unexpected data beyond EOF in block 9 of relation base/430666195/430666206 Which produces this lovely hint: postgres[21118]: [8-2] HINT: This has been

Re: [HACKERS] Relation extension scalability

On Fri, Apr 17, 2015 at 11:19 AM, Qingqing Zhou wrote: > > Most commercial database employs a DMS storage model, where it manages > object mapping and freespace itself. So different objects are sharing > storage within several files. Surely it has historic reasons, but it > has several advantages

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Thu, Apr 30, 2015 at 8:02 AM, Robert Haas wrote: > I don't mind the MSDOS newlines, but the UTF-16le bit is inconvenient. > UTF-8 would be much better, so I don't have to figure out how to > convert. > The patch is generated via github windows tool and that's possibly why. I regenerated it in

Re: [HACKERS] ERROR: unexpected data beyond EOF

Joshua D. Drake wrote: > > Alright folks, > > So I have this error: > > postgres[21118]: [8-1] ERROR: unexpected data beyond EOF > in block 9 of relation base/430666195/430666206 > > Which produces this lovely hint: > > postgres[21118]: [8-2] HINT: This has been seen to occur with buggy > ke

[HACKERS] cost_index() and path row estimate.

While looking into a customer performance problem, i saw this in costsize.c, cost_index() (9.3.6, but it looks the same in HEAD): /* Mark the path with the correct row estimate */ if (path->path.param_info) { path->path.rows = path->path.param_info->ppi_rows

[HACKERS] ERROR: unexpected data beyond EOF

Alright folks, So I have this error: postgres[21118]: [8-1] ERROR: unexpected data beyond EOF in block 9 of relation base/430666195/430666206 Which produces this lovely hint: postgres[21118]: [8-2] HINT: This has been seen to occur with buggy kernels; consider updating your system. Howev

Re: [HACKERS] feature freeze and beta schedule

On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut wrote: > On 4/30/15 12:01 PM, Robert Haas wrote: >> So generally we have stamped in late April or early May and released >> in September, but last year we didn't release until December. I >> assume that if we stamp beta1 in June instead of May, t

Re: [HACKERS] pg_upgrade: quote directory names in delete_old_cluster script

On Wed, Apr 29, 2015 at 11:59:26PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > > I have developed the attached patch to use platform-specific quoting of > > path names. > > Part of me wonders about initdb's existing DIR_SEP and QUOTE_PATH > definitions ... seems messy to reinvent thes

Re: [HACKERS] feature freeze and beta schedule

On 4/30/15 12:01 PM, Robert Haas wrote: > So generally we have stamped in late April or early May and released > in September, but last year we didn't release until December. I > assume that if we stamp beta1 in June instead of May, that's going to > somewhat delay the final release as well, but I

Re: [HACKERS] BRIN range operator class

Robert Haas wrote: > On Mon, Apr 6, 2015 at 5:17 PM, Alvaro Herrera > wrote: > > Thanks for the updated patch; I will at it as soon as time allows. (Not > > really all that soon, regrettably.) > > > > Judging from a quick look, I think patches 1 and 5 can be committed > > quickly; they imply no

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, Apr 30, 2015 at 9:15 AM, Sawada Masahiko wrote: > On Thu, Apr 30, 2015 at 8:39 PM, Robert Haas wrote: >> On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko >> wrote: >>> Attached v10 patch is latest version patch. >>> The syntax is, >>> REINDEX { INDEX | ... } name [ WITH ] [ VERBOSE ] >>

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, Apr 30, 2015 at 10:15 AM, Sawada Masahiko wrote: > > On Thu, Apr 30, 2015 at 8:39 PM, Robert Haas wrote: > > On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko wrote: > >> Attached v10 patch is latest version patch. > >> The syntax is, > >> REINDEX { INDEX | ... } name [ WITH ] [ VERBOSE ]

Re: [HACKERS] feature freeze and beta schedule

On Thu, Apr 30, 2015 at 8:39 AM, Peter Eisentraut wrote: > The schedule > > calls for beta in June. In light of that, the core team has agreed to > call for > > feature freeze on May 15 > > That means that all patche

Re: [HACKERS] Reducing tuple overhead

Robert Haas wrote: > On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby wrote: > > The problem with just having the value is that if *anything* changes between > > how you evaluated the value when you created the index tuple and when you > > evaluate it a second time you'll corrupt your index. This is act

Re: [HACKERS] pg_upgrade: quote directory names in delete_old_cluster script

Bruce Momjian wrote: > I have developed the attached patch to use platform-specific quoting of > path names. Part of me wonders about initdb's existing DIR_SEP and QUOTE_PATH definitions ... seems messy to reinvent these things all over again. -- Álvaro Herrerahttp://www.2ndQuad

Re: [HACKERS] collations in shared catalogs?

Bruce Momjian writes: On 2015-02-25 12:08:32 -0500, Tom Lane wrote: > The most obvious fix is to change "provider" to a NAME column. > Where are we on this? Not done yet, but we should make a point of making that fix before 9.5. Please add it to the open items page for 9.5. I am not su

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Thu, Apr 30, 2015 at 9:02 AM, Bruce Momjian wrote: > On Thu, Apr 30, 2015 at 08:46:55AM -0400, Robert Haas wrote: >> On Wed, Apr 15, 2015 at 3:38 PM, Qingqing Zhou >> wrote: >> > In executor context, outerPlanState(node) is the same as >> > node->ss.ps.lefttree. We follow this in most places e

Re: [HACKERS] Precedence of NOT LIKE, NOT BETWEEN, etc

Bruce Momjian writes: > On Wed, Apr 8, 2015 at 01:14:38PM -0400, Tom Lane wrote: >> Greg Stark writes: >>> On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote: Also, it strikes me that we could significantly reduce, maybe even fully eliminate, the funny behaviors around the existing base_

Re: [HACKERS] collations in shared catalogs?

On Wed, Feb 25, 2015 at 10:19:45PM +0100, Andres Freund wrote: > On 2015-02-25 15:59:55 -0500, Tom Lane wrote: > > Andres Freund writes: > > > On 2015-02-25 12:08:32 -0500, Tom Lane wrote: > > >> The most obvious fix is to change "provider" to a NAME column. > > > > > Yea. I'm not sure why that w

Re: [HACKERS] Turning recovery.conf into GUCs

On Sat, Feb 21, 2015 at 6:45 AM, Peter Eisentraut wrote: > On 2/19/15 4:33 PM, Josh Berkus wrote: >> On 02/19/2015 12:23 PM, Peter Eisentraut wrote: >>> On 1/6/15 4:22 PM, Peter Eisentraut wrote: That said, there is a much simpler way to achieve that specific functionality: Expose all th

Re: [HACKERS] Moving on to close the current CF 2015-02

On Wed, Apr 29, 2015 at 1:10 AM, Magnus Hagander wrote: > On Fri, Apr 17, 2015 at 4:57 PM, Magnus Hagander > wrote: >> >> On Fri, Apr 17, 2015 at 9:23 AM, Michael Paquier >> wrote: >>> >>> On Fri, Apr 17, 2015 at 4:22 PM, Michael Paquier wrote: >>> > @Magnus: having the possibility to mark a pat

Re: [HACKERS] contrib/fuzzystrmatch/dmetaphone.c license

On Wed, Feb 25, 2015 at 08:36:49PM -0500, Andrew Dunstan wrote: > >>>I doubt we want to rip it out without some suitable > >>>replacement -- do we? > >>> > >>> > >> > >>That's more than 10 years ago. I remember creating this for my then work > >>at the North Carolina State Highway Patrol and sendin

Re: [HACKERS] Reducing tuple overhead

On Thu, Apr 30, 2015 at 9:46 AM, Amit Kapila wrote: > As the index expression contain table columns and all the functions > or operators used in expression must be IMMUTABLE, won't that > guarantee to avoid such a situation? The concern is that they might be labeled as immutable but not actually

Re: [HACKERS] Reducing tuple overhead

On Thu, Apr 30, 2015 at 5:03 PM, Robert Haas wrote: > > On Thu, Apr 30, 2015 at 12:31 AM, Amit Kapila wrote: > > I think I am missing something here, but when this second > > evaluation is needed. Basically what I understand from index > > insertion is that it evaluates the value to be inserted

Re: [HACKERS] Loss of some parts of the function definition

2015-04-30 15:34 GMT+02:00 Sergey Grinko : > I agree that it is better to show what really works. > I propose to allow additional option through a source code which is made > on the basis of a compilation of metadata. > This will solve the problem. > You can to teach PostgreSQL function to use pr

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

On Thu, Apr 30, 2015 at 9:16 AM, Kouhei Kaigai wrote: > It seems to me the code block for T_ForeignScan and T_CustomScan in > setrefs.c are a bit large. It may be better to have a separate > function like T_IndexOnlyScan. > How about your opinion? Either way is OK with me. Please do as you think

Re: [HACKERS] Precedence of NOT LIKE, NOT BETWEEN, etc

On Wed, Apr 8, 2015 at 01:14:38PM -0400, Tom Lane wrote: > Greg Stark writes: > > On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote: > >> Also, it strikes me that we could significantly reduce, maybe even fully > >> eliminate, the funny behaviors around the existing base_yylex() > >> substitutions

Re: [HACKERS] Loss of some parts of the function definition

I agree that it is better to show what really works. I propose to allow additional option through a source code which is made on the basis of a compilation of metadata. This will solve the problem. 2015-04-30 16:19 GMT+03:00 Pavel Stehule : > > > 2015-04-30 15:08 GMT+02:00 Sergey Grinko : > >> Th

Re: [HACKERS] configure can't detect proper pthread flags

On Thu, Apr 30, 2015 at 3:51 PM, Robert Haas wrote: > On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov wrote: >> On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote: >>> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote: Ok, one more attempt: maybe instead of checking that stderr is empty >>

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> On Sun, Apr 26, 2015 at 10:00 PM, Kouhei Kaigai wrote: > > The attached patch v13 is revised one according to the suggestion > > by Robert. > > Thanks. > > The last hunk in foreign.c is a useless whitespace change. > Sorry, my oversight. > + /* actually, not shift members */ > > Change

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, Apr 30, 2015 at 8:39 PM, Robert Haas wrote: > On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko > wrote: >> Attached v10 patch is latest version patch. >> The syntax is, >> REINDEX { INDEX | ... } name [ WITH ] [ VERBOSE ] >> >> That is, WITH clause is optional. > > I thought we agreed on

Re: [HACKERS] Re: [BUGS] BUG #11805: Missing SetServiceStatus call during service shutdown in pg_ctl (Windows only)

On Thu, Apr 30, 2015 at 9:53 PM, Robert Haas wrote: > On Sat, Mar 21, 2015 at 9:00 AM, Michael Paquier > wrote: >> On Fri, Mar 20, 2015 at 9:48 PM, Bruce Momjian wrote: >>> On Tue, Oct 28, 2014 at 07:02:41AM +, krystian.bi...@gmail.com wrote: The following bug has been logged on the web

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Thu, Apr 30, 2015 at 08:46:55AM -0400, Robert Haas wrote: > On Wed, Apr 15, 2015 at 3:38 PM, Qingqing Zhou > wrote: > > In executor context, outerPlanState(node) is the same as > > node->ss.ps.lefttree. We follow this in most places except a few. This > > patch clean up the outliers and might s

Re: [HACKERS] Re: [BUGS] BUG #11805: Missing SetServiceStatus call during service shutdown in pg_ctl (Windows only)

On Sat, Mar 21, 2015 at 9:00 AM, Michael Paquier wrote: > On Fri, Mar 20, 2015 at 9:48 PM, Bruce Momjian wrote: >> On Tue, Oct 28, 2014 at 07:02:41AM +, krystian.bi...@gmail.com wrote: >>> The following bug has been logged on the website: >>> >>> Bug reference: 11805 >>> Logged by:

Re: [HACKERS] configure can't detect proper pthread flags

On Wed, Apr 8, 2015 at 2:31 AM, Max Filippov wrote: > On Sat, Mar 21, 2015 at 2:06 AM, Max Filippov wrote: >> On Fri, Mar 20, 2015 at 3:43 PM, Max Filippov wrote: >>> Ok, one more attempt: maybe instead of checking that stderr is empty >>> we could check that stderr has changed in the presence o

Re: [HACKERS] Use outerPlanState() consistently in executor code

On Wed, Apr 15, 2015 at 3:38 PM, Qingqing Zhou wrote: > In executor context, outerPlanState(node) is the same as > node->ss.ps.lefttree. We follow this in most places except a few. This > patch clean up the outliers and might save us a few instructions by > removing indirection. > > Most of change

Re: [HACKERS] Loss of some parts of the function definition

Hi 2015-04-30 13:44 GMT+02:00 Sergey Grinko : > Hi, > > Dear developers, I have a request to you. > > Now create a script in the application of its function parameters and > return values can be declared using %TYPE. > However, when you save the script is stored inside the server only what is > c

Re: [HACKERS] BRIN range operator class

On Mon, Apr 6, 2015 at 5:17 PM, Alvaro Herrera wrote: > Thanks for the updated patch; I will at it as soon as time allows. (Not > really all that soon, regrettably.) > > Judging from a quick look, I think patches 1 and 5 can be committed > quickly; they imply no changes to other parts of BRIN. (

[HACKERS] feature freeze and beta schedule

The schedule calls for beta in June. In light of that, the core team has agreed to call for feature freeze on May 15 That means that all patches that add or change features should be committed by then. If you have

Re: [HACKERS] json_populate_record issue - TupleDesc reference leak

Still issue is not fixed still create type pt as (a int, b int); postgres=# select json_populate_record('(10,20)'::pt, '{}'); WARNING: TupleDesc reference leak: TupleDesc 0x7f413ca325b0 (16560,-1) still referenced 2015-04-30 14:32 GMT+02:00 Bruce Momjian : > On Thu, Feb 26, 2015 at 05:31:44PM

Re: [HACKERS] Reducing tuple overhead

On Thu, Apr 30, 2015 at 8:05 AM, Simon Riggs wrote: > A much better idea is to work out how to avoid index bloat at cause. If we > are running an UPDATE and we cannot get a cleanup lock, we give up and do a > non-HOT update, causing the index to bloat. It seems better to wait for a > short period

Re: [HACKERS] json_populate_record issue - TupleDesc reference leak

On Thu, Feb 26, 2015 at 05:31:44PM -0500, Tom Lane wrote: > Andrew Dunstan writes: > > This doesn't look quite right. Shouldn't we unconditionally release the > > Tupledesc before the returns at lines 2118 and 2127, just as we do at > > the bottom of the function at line 2285? > > I think Pavel

Re: [HACKERS] Reducing tuple overhead

On 25 April 2015 at 01:12, Amit Kapila wrote: > On Sat, Apr 25, 2015 at 1:58 AM, Jim Nasby > wrote: > > > > On 4/23/15 10:40 PM, Amit Kapila wrote: > >> > >> I agree with you and what I think one of the major reasons of bloat is > that > >> Index segment doesn't have visibility information due t

Re: [HACKERS] Disabling trust/ident authentication configure option

On Thu, Apr 16, 2015 at 9:55 AM, Bernd Helmle wrote: > PostgreSQL is deployed as part of a larger technical solution (e.g. a > Telecommunication system) and a field engineer has to install/upgrade this > solution. The engineer is a specialist in the Telco domain and has only > little knowledge of

[HACKERS] Loss of some parts of the function definition

Hi, Dear developers, I have a request to you. Now create a script in the application of its function parameters and return values can be declared using %TYPE. However, when you save the script is stored inside the server only what is considered his body. Thus, we obtain: 1) loss of the custom for

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko wrote: > Attached v10 patch is latest version patch. > The syntax is, > REINDEX { INDEX | ... } name [ WITH ] [ VERBOSE ] > > That is, WITH clause is optional. I thought we agreed on moving this earlier in the command: http://www.postgresql.org/me

  1   2   >