Re: [HACKERS] multivariate statistics / patch v6

Hello, At Thu, 14 May 2015 12:35:50 +0200, Tomas Vondra wrote in <55547a86.8020...@2ndquadrant.com> > > On 05/13/15 10:31, Kyotaro HORIGUCHI wrote: > > Hello, this might be somewhat out of place but strongly related > > to this patch so I'll propose this here. > > > > This is a proposal of new

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, May 14, 2015 at 10:29 PM, Andrew Dunstan wrote: > > > On 05/14/2015 10:52 AM, Robert Haas wrote: >> >> On Thu, May 14, 2015 at 12:12 AM, Amit Kapila wrote: >>> >>> On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan wrote: How about if we simply abort if we find a non-symlink where

[HACKERS] log bloating with shortlife bgworkers?

Hi I am planning to use short living bg workers. I was little bit surprised so any start and finish does entry in log. Is there any plan to decrease a log level for these purposes? Regards Pavel

Re: [HACKERS] upper planner path-ification

On Thu, May 14, 2015 at 8:24 PM, Tom Lane wrote: > Robert Haas writes: > > On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote: > >> For the reasons I mentioned, I'd like to get to a point where > >> subquery_planner's output is Paths not Plans as soon as possible. But > the > >> idea of coarse r

Re: [HACKERS] BackendPidGetProc doesn't return PGPROC for background worker?

On 2015-05-15 PM 02:13, Pavel Stehule wrote: > 2015-05-15 3:39 GMT+02:00 Amit Langote : >> One reason for this may be that the worker was not started with the flag >> BGWORKER_SHMEM_ACCESS which is necessary to perform InitProcess() that >> would >> initialize a PGPROC entry for it. But if you'd us

Re: [HACKERS] proposal: contrib module - generic command scheduler

2015-05-14 19:12 GMT+02:00 Jim Nasby : > On 5/14/15 1:36 AM, Pavel Stehule wrote: > >> I don't think we want to log statements, but we should be able to >> log when a job has run and whether it succeeded or not. (log in a >> table, not just a logfile). >> >> This isn't something th

Re: [HACKERS] BackendPidGetProc doesn't return PGPROC for background worker?

2015-05-15 3:39 GMT+02:00 Amit Langote : > On 2015-05-15 AM 05:01, Pavel Stehule wrote: > > > > I am trying to start bgworker from bgworker and create communication > > between these process. I have a code based on test_shm_mq. This code > fails > > because BackendPidGetProc doesn't find related b

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On Tue, May 5, 2015 at 6:48 AM, Peter Eisentraut wrote: > On 5/1/15 12:33 PM, Andres Freund wrote: >> On 2015-04-08 19:19:29 +0100, Greg Stark wrote: >>> I'm not sure what the best way to handle the hand-off from patch >>> contribution to reviewer/committer. If I start tweaking things then >>> you

Re: [HACKERS] best place for "rtree" strategy numbers

Tom Lane wrote: > Alvaro Herrera writes: > > I can, of course, just leave these files well enough alone and just rely > > on the numbers not changing (which surely they won't anyway) and > > remaining consistent with numbers used in new opclasses (which surely > > they will lest they be born inco

Re: [HACKERS] upper planner path-ification

On Thu, May 14, 2015 at 7:09 AM, Robert Haas wrote: > Hi, > > I've been pulling over Tom's occasional remarks about redoing > grouping_planner - and maybe further layers of the planner - to work > with Paths instead of Plans. I've had difficulty locating all of the > relevant threads. Here's ev

Re: [HACKERS] Fix token exceeding NAMELEN

"Aaron W. Swenson" writes: > On 2015-05-13 18:16, Christopher Browne wrote: >> I thought that this restriction was alleviated years ago, so I'm a bit >> surprised to see this come up in 2015. (Or perhaps Gentoo hasn't >> yet opened up some limits??? :-) ) > The restriction is alleviated (patche

Re: [HACKERS] BackendPidGetProc doesn't return PGPROC for background worker?

On 2015-05-15 AM 10:59, Amit Langote wrote: > On 2015-05-15 AM 10:39, Amit Langote wrote: >> On 2015-05-15 AM 05:01, Pavel Stehule wrote: >>> >>> I am trying to start bgworker from bgworker and create communication >>> between these process. I have a code based on test_shm_mq. This code fails >>> b

Re: [HACKERS] pg_upgrade cleanup

On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote: > This patch makes pg_upgrade controldata checks more consistent, and adds > a missing check for float8_pass_by_value. Sorry, I should have mentioned I applied this patch to head. It isn't significant enough to backpatch. -- Bruce

Re: [HACKERS] BackendPidGetProc doesn't return PGPROC for background worker?

On 2015-05-15 AM 10:39, Amit Langote wrote: > On 2015-05-15 AM 05:01, Pavel Stehule wrote: >> >> I am trying to start bgworker from bgworker and create communication >> between these process. I have a code based on test_shm_mq. This code fails >> because BackendPidGetProc doesn't find related bgwor

[HACKERS] pg_upgrade cleanup

This patch makes pg_upgrade controldata checks more consistent, and adds a missing check for float8_pass_by_value. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/src/bin/pg_upgrade/co

Re: [HACKERS] BackendPidGetProc doesn't return PGPROC for background worker?

On 2015-05-15 AM 05:01, Pavel Stehule wrote: > > I am trying to start bgworker from bgworker and create communication > between these process. I have a code based on test_shm_mq. This code fails > because BackendPidGetProc doesn't find related bgworker process, although > the registrant process is

Re: [HACKERS] Fix token exceeding NAMELEN

On 2015-05-13 18:16, Christopher Browne wrote: > On 13 May 2015 at 17:55, Tom Lane wrote: > > > "Aaron W. Swenson" writes: > > > Trying to build HEAD and ran into this issue building the docs: > > > openjade:logicaldecoding.sgml:575:62:Q: length of name token must > > > not exceed NAMELE

Re: [HACKERS] Final Patch for GROUPING SETS

On Thu, May 14, 2015 at 08:59:45AM +0200, Andres Freund wrote: > On 2015-05-14 02:51:42 -0400, Noah Misch wrote: > > Covering hash aggregation might entail a large preparatory refactoring > > of nodeHash.c, but beyond development cost I can't malign that. > > You mean execGrouping.c? Afaics nodeHa

Re: [HACKERS] Add pg_settings.pending_restart column

On 4/22/15 2:32 AM, Michael Paquier wrote: > Attached is a rebased patch with previous comments addressed as I was > looking at it. > Switching this patch as "Ready for committer". Committed, thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

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

> A possible compromise that we could perhaps still wedge into 9.5 is to > extend CustomPath with a List of child Paths, and CustomScan with a List > of child Plans, which createplan.c would know to build from the Paths, > and other modules would then also be aware of these children. I find that >

Re: [HACKERS] best place for "rtree" strategy numbers

Alvaro Herrera writes: > In Emre Hasegeli's patch for range/inet/geometry opclasses for BRIN, he > chose to move strategy numbers from gist.h to a more central place. He > chose skey.h because that's where btree strategy numbers are defined, > but I'm not sure I agree with that choice. Yeah, put

Re: [HACKERS] KNN-GiST with recheck

On 05/15/2015 02:28 AM, Heikki Linnakangas wrote: I think this is now ready for committing, but I'm pretty tired now so I'll read through this one more time in the morning, so that I won't wake up to a red buildfarm. Forgot to attach the latest patch, here you go. - Heikki From df00d9c972a760e

Re: [HACKERS] KNN-GiST with recheck

On 05/14/2015 01:43 PM, Alexander Korotkov wrote: On Wed, May 13, 2015 at 10:17 PM, Alexander Korotkov wrote: One quick comment: It would be good to avoid the extra comparisons of the distances, when the index doesn't return any lossy items. As the patch stands, it adds one extra copyDistanc

Re: [HACKERS] Triaging the remaining open commitfest items

On 15/05/15 10:58, Bruce Momjian wrote: On Thu, May 14, 2015 at 06:57:24PM -0400, Tom Lane wrote: Stephen Frost writes: * Bruce Momjian (br...@momjian.us) wrote: I will call for a vote that the freeze deadline be changed if this patch is rejected to due to time. I might lose the vote, but I

[HACKERS] best place for "rtree" strategy numbers

In Emre Hasegeli's patch for range/inet/geometry opclasses for BRIN, he chose to move strategy numbers from gist.h to a more central place. He chose skey.h because that's where btree strategy numbers are defined, but I'm not sure I agree with that choice. It's been clear for a while now that thes

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 06:57:24PM -0400, Tom Lane wrote: > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> I will call for a vote that the freeze deadline be changed if this patch > >> is rejected to due to time. I might lose the vote, but I am going to > >> try because

Re: [HACKERS] Triaging the remaining open commitfest items

Stephen Frost writes: > * Bruce Momjian (br...@momjian.us) wrote: >> I will call for a vote that the freeze deadline be changed if this patch >> is rejected to due to time. I might lose the vote, but I am going to >> try because if we lose our reputation for fairness, we have lost a lot >> more t

Re: [HACKERS] Triaging the remaining open commitfest items

Bruce Momjian writes: > On Thu, May 14, 2015 at 05:37:07PM -0400, Tom Lane wrote: >> [ shrug... ] Andrew had unilaterally removed me as committer from that >> patch back in January or so, so it dropped way down my priority list. >> I'm willing to move it back up now, but I could do without people

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 6:03 PM, Peter Geoghegan wrote: > On Thu, May 14, 2015 at 2:28 PM, Andres Freund wrote: >> On 2015-05-14 17:10:29 -0400, Tom Lane wrote: >>> FWIW, I did go look at this patch, and concluded it was not close enough >>> to ready to try to squeeze it in now. (I think Andres

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 5:54 PM, Bruce Momjian wrote: >> Life is unfair. > > True, but I have problems with leaders acting in a way that is unfair to > those with less power. Have you considered how demoralizing it is to > work in an unfair environment? Unfairness happens, but as leaders, we > a

Re: [HACKERS] Triaging the remaining open commitfest items

* Bruce Momjian (br...@momjian.us) wrote: > On Thu, May 14, 2015 at 11:28:33PM +0200, Andres Freund wrote: > > On 2015-05-14 17:10:29 -0400, Tom Lane wrote: > > > FWIW, I did go look at this patch, and concluded it was not close enough > > > to ready to try to squeeze it in now. (I think Andres is

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 2:28 PM, Andres Freund wrote: > On 2015-05-14 17:10:29 -0400, Tom Lane wrote: >> FWIW, I did go look at this patch, and concluded it was not close enough >> to ready to try to squeeze it in now. (I think Andres isn't convinced >> of that yet, but time grows short, and I qu

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 05:37:07PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote: > >> The good news on this front is that Salesforce has recently taken an > >> interest in having GROUPING SETS capability, so I should be able to > >> fi

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, May 14, 2015 at 12:59 PM, Andrew Dunstan wrote: >> I'm not sure I understand this issue in detail, but why would using >> rmtree() on something you expect to be a symlink ever be a good idea? >> It seems like if things are the way you expect them to be, it has no >> benefit, but if they ar

Re: [HACKERS] Triaging the remaining open commitfest items

Bruce Momjian writes: > On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote: >> The good news on this front is that Salesforce has recently taken an >> interest in having GROUPING SETS capability, so I should be able to >> find more time to work on this over the next month or two. What I am

Re: [HACKERS] upper planner path-ification

On Thu, May 14, 2015 at 12:19:44PM -0400, Robert Haas wrote: > Well, I'm just shooting from the hip here, but it seems to me that the > basic pipeline as it exists today is Join -> Aggregate -> SetOp -> > Limit -> LockRows. I don't think Limit or LockRows can be moved any > earlier. SetOps have a

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 11:28:33PM +0200, Andres Freund wrote: > On 2015-05-14 17:10:29 -0400, Tom Lane wrote: > > FWIW, I did go look at this patch, and concluded it was not close enough > > to ready to try to squeeze it in now. (I think Andres isn't convinced > > of that yet, but time grows shor

Re: [HACKERS] Triaging the remaining open commitfest items

On 2015-05-14 17:10:29 -0400, Tom Lane wrote: > FWIW, I did go look at this patch, and concluded it was not close enough > to ready to try to squeeze it in now. (I think Andres isn't convinced > of that yet, but time grows short, and I quite agree with Robert that > committing almost-ready patches

Re: [HACKERS] Triaging the remaining open commitfest items

On Thu, May 14, 2015 at 05:10:29PM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 05/13/2015 11:38 AM, Tom Lane wrote: > >> * Grouping Sets > >> > >> I had originally promised to be committer for this one, and still want > >> to go look at it, but Robert's nearby message about not committ

Re: [HACKERS] Triaging the remaining open commitfest items

Andrew Dunstan writes: > On 05/13/2015 11:38 AM, Tom Lane wrote: >> * Grouping Sets >> >> I had originally promised to be committer for this one, and still want >> to go look at it, but Robert's nearby message about not committing stuff >> in haste definitely seems to apply. > That makes me sad.

Re: [HACKERS] Patch for bug #12845 (GB18030 encoding)

I wrote: > Robert Haas writes: >> On Wed, May 6, 2015 at 11:13 AM, Alvaro Herrera >> wrote: >>> Maybe not, but at the very least we should consider getting it fixed in >>> 9.5 rather than waiting a full development cycle. Same as in >>> https://www.postgresql.org/message-id/20150428131549.ga25..

[HACKERS] Query Deparsing Support

The DDL deparse support that just landed looks impressive, but I’ve needed query deparsing for some time now. Within pg_shard we took the fast-and-dirty approach of merging in a modified ruleutils.c, though I’d (obviously) like to get away from that. Man

[HACKERS] BackendPidGetProc doesn't return PGPROC for background worker?

Hi I am trying to start bgworker from bgworker and create communication between these process. I have a code based on test_shm_mq. This code fails because BackendPidGetProc doesn't find related bgworker process, although the registrant process is living registrant = BackendPidGetProc(MyBgworkerEn

Re: [HACKERS] trust authentication behavior

On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov wrote: > Yeah, but the idea is to do that without the pg_hba.conf > You may want to try describing the problem and not just ask if the chosen solution is possible - of which I am doubtful but I have never used selinux or studied it in any depth.

Re: [HACKERS] trust authentication behavior

Yeah, but the idea is to do that without the pg_hba.conf - Ursprüngliche Mail - Von: "David G. Johnston" An: "Denis Kirjanov" CC: pgsql-hackers@postgresql.org Gesendet: Donnerstag, 14. Mai 2015 18:22:45 Betreff: Re: [HACKERS] trust authentication behavior On Thu, May 14, 2015 at 2:16 AM

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Ah, ok. > > Pushed that, but some further notes: Thanks! Looking much better. > * The actual audit reports ought to be ereport() not elog(). I made them > so but did not insert an errcode(). ISTM that it would likely be a goo

Re: [HACKERS] trust authentication behavior

Andrew Dunstan writes: > On 05/14/2015 11:59 AM, Robert Haas wrote: >> On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov wrote: >>> Is it possible to restrict the trust auth method to accept local >>> connections only using the selinux policy? >> I would guess that it probably is, but I can't tel

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> At least on dromedary, this seems to be the problem: >> >> pg_audit.c: In function 'stack_pop': >> pg_audit.c:387: warning: format '%ld' expects type 'long int', but argument >> 3 has type 'int64' >> pg_audit.c: In function 'stack

Re: [HACKERS] Final Patch for GROUPING SETS

On 2015-05-14 09:16:10 +0100, Andrew Gierth wrote: > Andres> A rough sketch of what I'm thinking of is: > > I'm not sure I'd do it quite like that. It was meant as a sketch, so there's lots of things it's probably missing ;) > Rather, have a wrapper function get_outer_tuple that calls > ExecPro

Re: [HACKERS] proposal: contrib module - generic command scheduler

On 5/14/15 1:36 AM, Pavel Stehule wrote: I don't think we want to log statements, but we should be able to log when a job has run and whether it succeeded or not. (log in a table, not just a logfile). This isn't something that can be done at higher layers either; only the sch

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On 05/14/2015 10:52 AM, Robert Haas wrote: On Thu, May 14, 2015 at 12:12 AM, Amit Kapila wrote: On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan wrote: How about if we simply abort if we find a non-symlink where we want the symlink to be, and only remove something that is actually a symlink (

[HACKERS] Changes to backup.sgml

-hackers, After my brain flatulence last week on backups, I decided to read the docs again. There are some improvements that I would like to make and wanted some feedback: 1. File System Level Backup The section should be a note within the larger document. It is largely a legacy section fr

Re: [HACKERS] trust authentication behavior

On 05/14/2015 11:59 AM, Robert Haas wrote: On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov wrote: Is it possible to restrict the trust auth method to accept local connections only using the selinux policy? I would guess that it probably is, but I can't tell you how. I would have guessed n

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Alvaro Herrera writes: > Tom Lane wrote: >> Another thing that looks not amazingly well-thought-out about that >> regression test is that it creates a superuser role with a known name >> (and no password, not that adding a password would make it better). > We create a lot of roles in other tests

Re: [HACKERS] upper planner path-ification

On Thu, May 14, 2015 at 10:54 AM, Tom Lane wrote: > In any case, the key question if we're to have Paths representing > higher-level computations is "what do we hang our lists of such Paths > off of?". Yeah, I was wondering about that, too. > If we have say both GROUP BY and LIMIT, it's importan

Re: [HACKERS] PATCH: pgbench allow '=' in \set

[...] I tend to agree with the bottom line that that's just more complication than is justified. I sympathize with Robert's dislike for backslash continuations; but doing it the other way would be a huge amount of up-front work and a nontrivial amount of continuing maintenance, for which we

[HACKERS] pgbench - allow backslash-continuations in custom scripts

Add backslash continuations to pgbench custom scripts. The benefit of this approach is that it is upward compatible, and it is also pretty simple to implement. The downside is that backslash continuation is not the best syntax ever invented, but then you do not have to use it if you do not li

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Tom Lane wrote: > Stephen Frost writes: > > I've pushed a change which should clean it up by simply loading the > > module after each reconnects is done, more-or-less simulating having it > > be in shared_preload_libraries. It also wasn't using the correct > > database for reconnecting. > > > I'

Re: [HACKERS] trust authentication behavior

On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov wrote: > Is it possible to restrict the trust auth method to accept local connections > only using the selinux policy? I would guess that it probably is, but I can't tell you how. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enter

Re: [HACKERS] trust authentication behavior

On Thu, May 14, 2015 at 2:16 AM, Denis Kirjanov wrote: > Hello guys, > > Is it possible to restrict the trust auth method to accept local > connections only using the selinux policy? > You want selinux to prevent trust connections from non-local clients even if pg_hba.conf explicitly allows them

Re: [HACKERS] upper planner path-ification

Robert Haas writes: > On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote: >> For the reasons I mentioned, I'd like to get to a point where >> subquery_planner's output is Paths not Plans as soon as possible. But the >> idea of coarse representation of steps that we aren't trying to be smart >> abo

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, May 14, 2015 at 12:12 AM, Amit Kapila wrote: > On Thu, May 14, 2015 at 2:10 AM, Andrew Dunstan wrote: >> How about if we simply abort if we find a non-symlink where we want the >> symlink to be, and only remove something that is actually a symlink (or a >> junction point, which is more or

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, May 11, 2015 at 9:07 PM, David Steele wrote: > > The attached v12 patch removes the code that became redundant with > > Alvaro committing the event trigger/deparse work. I've updated the > > regression tests to reflect the chang

Re: [HACKERS] a few thoughts on the schedule

On Wed, May 13, 2015 at 8:39 PM, Tom Lane wrote: > > Robert Haas writes: > > > I am already concerned about some of the commits that have gone in > > very recently, particularly these: > > There is going to need to be a mop-up period, and we ought to be willing > to revert anything we feel wasn't

Re: [HACKERS] PATCH: pgbench allow '=' in \set

Hello Robert, Also, having ";" as a end of commands could also help by allowing multiline commands, but that would break compatibility. Maybe allowing continuations (\\\n) would be an acceptable compromise. I loathe violently the convention of using a backslash at the end of a line, because

Re: [HACKERS] PATCH: pgbench allow '=' in \set

Fabien COELHO writes: >> Another option, breaking backward compatibility, would be to decide >> that backslash commands have to be terminated by a semicolon token. > I do not like it much, as it is inconsistent/incompatible with "psql". >> [...] multi-line SQL queries. If we wanted to make that

Re: [HACKERS] PATCH: pgbench allow '=' in \set

On Thu, May 14, 2015 at 3:20 AM, Fabien COELHO wrote: >> I loathe violently the convention of using a backslash at the end of a >> line, because it's too easy to write backslash-space-newline or >> backslash-tab-newline when you meant to write backslash-newline. But maybe >> we should do it anyway

[HACKERS] broken documentation: BackgroundWorkerInitializeConnection(NULL, NULL);

Hi The documentation (or this feature) is broken still If dbname is NULL or dboid is InvalidOid, the session is not connected to any particular database, but shared catalogs can be accessed. If username is NULL or useroid is InvalidOid, the process will run as the superuser created during initdb.

Re: [HACKERS] KNN-GiST with recheck

On Wed, May 13, 2015 at 10:17 PM, Alexander Korotkov wrote: > One quick comment: >> >> It would be good to avoid the extra comparisons of the distances, when >> the index doesn't return any lossy items. As the patch stands, it adds one >> extra copyDistances() call and a cmp_distances() call for

Re: [HACKERS] Missing importing option of postgres_fdw

On 2015/04/30 2:10, Robert Haas wrote: On Mon, Apr 27, 2015 at 7:47 AM, Michael Paquier wrote: Authorizing ALTER FOREIGN TABLE as query string that a FDW can use with IMPORT FOREIGN SCHEMA is a different feature than what is proposed in this patch, aka an option for postgres_fdw and meritates a

Re: [HACKERS] multivariate statistics / patch v6

On 05/13/15 10:31, Kyotaro HORIGUCHI wrote: Hello, this might be somewhat out of place but strongly related to this patch so I'll propose this here. This is a proposal of new feature for this patch or asking for your approval for my moving on this as a different (but very close) project. ===

[HACKERS] trust authentication behavior

Hello guys, Is it possible to restrict the trust auth method to accept local connections only using the selinux policy? Thank you! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pgAdmin4 Bug fix or my Fault ?

Hi, owww So sorry :( On Thu, May 14, 2015 at 11:46 AM, Dave Page wrote: > Hi > > On Thu, May 14, 2015 at 7:44 AM, Seçkin Alan wrote: >> Bruce, >> Thank you for "webpage" trick, I send subscrible mail to >> pgadmin-hackers-request. >> >> Actually I want to developer for pgadmin4. >> I talk with D

Re: [HACKERS] pgAdmin4 Bug fix or my Fault ?

Hi On Thu, May 14, 2015 at 7:44 AM, Seçkin Alan wrote: > Bruce, > Thank you for "webpage" trick, I send subscrible mail to > pgadmin-hackers-request. > > Actually I want to developer for pgadmin4. > I talk with Dave, > He say, "... You should use "git > diff" to create patches and then submit the

Re: [HACKERS] Final Patch for GROUPING SETS

> "Andres" == Andres Freund writes: Andres> My problem is that, unless I very much misunderstand something, Andres> the current implementation can end up requiring roughly #sets * Andres> #input of additional space for the "sidechannel tuplestore" in Andres> some bad cases. That happens

[HACKERS] Minor improvement to create_foreign_table.sgml

Hi, The attached patch adds missing NO INHERIT to the CHECK clause in the synopsis section in the reference page on CREATE FOREIGN TABLE. Best regards, Etsuro Fujita diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml index abadd83..413b033 100644

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

This version contains one little change. In order to be consistent with “\d+ viewname” it uses pg_get_viewdef(oid, /* pretty */ true) to produce “pretty” output (without additional parentheses). psql-ev-sv-support-v2.diff Description: Binary data > On 05 May 2015, at 16:42, Robert Haas wrote:

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Thu, May 14, 2015 at 9:58 AM, Robert Haas wrote: > On Wed, May 13, 2015 at 8:25 PM, Sawada Masahiko > wrote: >> The v15 patch emits a line for each table when reindexing multiple >> tables, and emits a line for each index when reindexing single table. >> But v14 patch emits a line for each in

Re: [HACKERS] upper planner path-ification

Hello, this topic lured me on.. At Wed, 13 May 2015 23:43:57 -0400, Robert Haas wrote in > On Wed, May 13, 2015 at 10:27 PM, Tom Lane wrote: > > Both of those are problems all right, but there is more context here. > > Thanks for providing the context. > > >> I'm inclined to think that it wo

Re: [HACKERS] PATCH: pgbench allow '=' in \set

Hello Robert, Also, having ";" as a end of commands could also help by allowing multiline commands, but that would break compatibility. Maybe allowing continuations (\\\n) would be an acceptable compromise. I loathe violently the convention of using a backslash at the end of a line, becaus

Re: [HACKERS] Final Patch for GROUPING SETS

On 2015-05-14 02:51:42 -0400, Noah Misch wrote: > Covering hash aggregation might entail a large preparatory refactoring > of nodeHash.c, but beyond development cost I can't malign that. You mean execGrouping.c? Afaics nodeHash.c isn't involved, and it doesn't look very interesting to make it so?