Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

Le lundi 16 juin 2014 11:32:38 Atri Sharma a écrit : > On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier > wrote: > > Just wondering: what about the case where the same data type is > > defined on both local and remote, but with *different* definitions? Is > > it the responsibility of the fdw to c

[HACKERS] 9.5 CF1

Hi. There are 92 outstanding patches in this CommitFest, and 63 of them do not have any reviewer. Those are very large numbers, so I hope everyone will pitch in to keep things moving along. There's quite a variety of patches available for review this time, and any level of feedback about them is

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier wrote: > On Mon, May 26, 2014 at 6:23 AM, Ronan Dunklau > wrote: > > Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit : > >> On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote: > >> > Hello, > >> > > >> > Since my last proposal di

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

On Mon, May 26, 2014 at 6:23 AM, Ronan Dunklau wrote: > Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit : >> On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote: >> > Hello, >> > >> > Since my last proposal didn't get any strong rebuttal, please find >> > attached a more complete v

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Kevin, * Kevin Grittner (kgri...@ymail.com) wrote: > Robert Haas wrote: > > Even aside from security exposures, how > > does a non-superuser who runs pg_dump know whether they've got a > > complete backup or a filtered dump that's missing some rows? > > This seems to me to be a killer objection

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jun 11, 2014 at 8:59 PM, Stephen Frost wrote: > > In this case the user-defined code needs to return a boolean. We don't > > currently do anything to prevent it from having side-effects, no, but > > the same is true with views which

Re: [HACKERS] Proposal for CSN based snapshots

On 05/30/2014 11:14 PM, Heikki Linnakangas wrote: > > Yeah. To recap, the failure mode is that if the master crashes and > restarts, the transaction becomes visible in the master even though it > was never replicated. Wouldn't another pg_clog bit for the transaction be able to sort that out? --

Re: [HACKERS] How to change the pgsql source code and build it??

On 06/13/2014 07:08 AM, Shreesha wrote: > I need to initialize the db as the root and start the database server Assuming there's no way around doing this (it's generally not a good idea), you can just use the simple program 'fakeroot'. This program changes the return values from system calls via

Re: [HACKERS] Built-in support for a memory consumption ulimit?

On 06/16/2014 11:56 AM, Amit Kapila wrote: > On Sat, Jun 14, 2014 at 8:07 PM, Tom Lane > wrote: >> >> After giving somebody advice, for the Nth time, to install a >> memory-consumption ulimit instead of leaving his database to the tender >> mercies of the Linux OOM kille

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Craig Ringer writes: > > I agree, and now that the urgency of trying to deliver this for 9.4 is > > over it's worth seeing if we can just run as table owner. > > > Failing that, we could take the approach a certain other RDBMS does and > > make the ability

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Adam Brightwell writes: > > Through this effort, we have concluded that for RLS the case of > > invalidating a plan is only necessary when switching between a superuser > > and a non-superuser. Obviously, re-planning on every role change would be > > too c

Re: [HACKERS] Built-in support for a memory consumption ulimit?

On Sat, Jun 14, 2014 at 8:07 PM, Tom Lane wrote: > > After giving somebody advice, for the Nth time, to install a > memory-consumption ulimit instead of leaving his database to the tender > mercies of the Linux OOM killer, it occurred to me to wonder why we don't > provide a built-in feature for t

Re: [HACKERS] postgresql.auto.conf read from wrong directory

On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg wrote: > > Re: Amit Kapila 2014-06-13 > > Agreed, I had mentioned in Notes section of document. Apart from that > > I had disallowed parameters that are excluded from postgresql.conf by > > initdb (Developer options) and they are recommended in use

Re: [HACKERS] [GSoC] Clustering in MADlib - status update

Hi! Here is my report for the last two weeks.Weeks 3 and 4 - 2014/06/15 During my third week, I haven't had time to work on GSoC a lot, because of my exams and my relocation (that's why I didn't deem necessary to post a report last Sunday). But last week has been much more productive, as I am now

Re: [HACKERS] Why is it "JSQuery"?

On 06/15/2014 04:58 PM, Josh Berkus wrote: I've been poking at the various json-query syntaxes you forwarded, and none of them really work for the actual jsquery features. Also, the existing syntax has the advantage of being *simple*, relatively speaking, and reasonably similar to JSONPATH. In

Re: [HACKERS] Why is it "JSQuery"?

On 06/10/2014 02:46 PM, David E. Wheeler wrote: > On Jun 10, 2014, at 12:06 PM, Oleg Bartunov wrote: > >> we have many other tasks than guessing the language name. >> jsquery is just an extension, which we invent to test our indexing >> stuff. Eventually, it grew out. I think we'll think on bet

Re: [HACKERS] make check For Extensions

On Jun 15, 2014, at 12:25 AM, Fabien COELHO wrote: > I'm not sure the extension is sought for in the cluster (ie the database data > directory). If you do "make install" the shared object is installed in some > /usr/lib/postgresql/... directory (under unix), and it is loaded from there, > but

Re: [HACKERS] delta relations in AFTER triggers

David Fetter wrote: > Any chance we might be able to surface the old version for the > case of UPDATE ... RETURNING? Not as part of this patch. Of course, once delta relations are available, who knows what people might do with them.  I have a hard time imagining exactly how you would expose wha

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Jun 14, 2014 at 04:56:44PM -0700, Kevin Grittner wrote: > Attached is a WIP patch for implementing the capture of delta > relations for a DML statement, in the form of two tuplestores -- > one for the old versions and one for the new versions. Thanks! Any chance we might be able to surfac

Re: [HACKERS] postgresql.auto.conf read from wrong directory

Re: Amit Kapila 2014-06-13 > Agreed, I had mentioned in Notes section of document. Apart from that > I had disallowed parameters that are excluded from postgresql.conf by > initdb (Developer options) and they are recommended in user manual > to be not used in production. Excluding developer opt

Re: [HACKERS] make check For Extensions

I would suggest to add that to https://wiki.postgresql.org/wiki/Todo. I may look into it when I have time, over the summer. The key point is that there is no need for a temporary installation, but only of a temporary cluster, and to trick this cluster into loading the uninstalled extension,