Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Fri, Mar 30, 2012 at 10:55 AM, Daniel Farina wrote: > On Thu, Mar 29, 2012 at 6:37 PM, Dobes Vandermeer > wrote: > > On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina > wrote: > >> > >> On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina > >> wrote: > >> > >> More technical concerns: > >> > * Prot

Re: [HACKERS] Speed dblink using alternate libpq tuple storage

> I've applied a modified form of the conname update patch. It seemed to > me that the fault is really in the DBLINK_GET_CONN and > DBLINK_GET_NAMED_CONN macros, which ought to be responsible for setting > the surrounding function's conname variable along with conn, rconn, etc. > There was actuall

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 6:37 PM, Dobes Vandermeer wrote: > On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina wrote: >> >> On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina >> wrote: >> >> More technical concerns: >> > * Protocol compression -- but a bit of sand in the gears is *which* >> > compressio

Re: [HACKERS] Odd out of memory problem.

On tis, 2012-03-27 at 00:53 +0100, Greg Stark wrote: > Hm. So my original plan was dependent on adding the state-merge > function we've talked about in the past. Not all aggregate functions > necessarily can support such a function but I think all or nearly all > the builtin aggregates can. Certain

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Fri, Mar 30, 2012 at 3:57 AM, Daniel Farina wrote: > On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan > wrote: > > Lastly, a case that can not as easily be fixed without some more > thinking is leveraging caching semantics of HTTP. think people would > really, really like that, if they cou

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina wrote: > On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina > wrote: More technical concerns: > > * Protocol compression -- but a bit of sand in the gears is *which* > > compression -- for database workloads, the performance of zlib can be > > a meani

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 6:25 PM, Dobes Vandermeer wrote: >> 2. You might find htsql interesting. > > > As a reference, or should we just bundle / integrate that with PostgreSQL > somehow? It's a totally different language layer without wide-spread popularity and, as of last ye

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 11:04 PM, Andrew Dunstan wrote: > > On 03/29/2012 10:37 AM, Dobes Vandermeer wrote: > >> Hi guys, >> >> Something from Josh's recent blog post about summer of code clicked with >> me - the HTTP / SQL concept. >> >> > 1. I've been in discussion with some people about addin

Re: [HACKERS] query cache

On Thu, Mar 29, 2012 at 4:57 PM, Tom Lane wrote: >> It's also probably worth keeping in mind the next time we >> bump the protocol version: it would be nice to have a way of doing >> prepare-bind-execute in a single protocol message, which I believe to >> be not possible at present. > > Huh?  That

Re: [HACKERS] Speed dblink using alternate libpq tuple storage

Marko Kreen writes: > My conclusion is that row-processor API is low-level expert API and > quite easy to misuse. It would be preferable to have something more > robust as end-user API, the PQgetRow() is my suggestion for that. > Thus I see 3 choices: > 1) Push row-processor as main API anyway a

Re: [HACKERS] Command Triggers patch v18

On Thu, Mar 29, 2012 at 4:21 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> Well, preceding and before are synonyms, so I don't see any advantage >> in that change.  But I really did mean AT permissions_checking time, >> not before or after it.  That is, we'd have a hook where instead of >>

Re: [HACKERS] Speed dblink using alternate libpq tuple storage

Kyotaro HORIGUCHI writes: > I'm sorry to have coded a silly bug. > The previous patch has a bug in realloc size calculation. > And separation of the 'connname patch' was incomplete in regtest. > It is fixed in this patch. I've applied a modified form of the conname update patch. It seemed to me

Re: [HACKERS] Command Triggers patch v18

Robert Haas writes: > Apropos of nothing and since I haven't found a particularly good time > to say this in amidst all the technical discussion, I appreciate very > much all the work you've been putting into this. Hey, thanks, I very much appreciate your support here! >> (1) is not hard to fix

Re: [HACKERS] query cache

Robert Haas writes: > Interestingly, Peter Geoghegan's blog post on the pg_stat_statements > patch you just committed[1] claims that the overhead of fingerprinting > queries was only 1-2.5%, which is less than I would have thought, so > if we ever get to the point where we're fairly sure we've got

Re: [HACKERS] Command Triggers patch v18

Robert Haas writes: > Well, preceding and before are synonyms, so I don't see any advantage > in that change. But I really did mean AT permissions_checking time, > not before or after it. That is, we'd have a hook where instead of > doing something like this: > > aclresult = pg_class_aclcheck(re

Re: [HACKERS] query cache

On Fri, Mar 23, 2012 at 2:54 PM, Tom Lane wrote: > Robert Haas writes: >> What I think is more common is the repeated submission of queries that >> are *nearly* identical, but with either different parameter bindings >> or different constants.  It would be nice to have some kind of cache >> that

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On Thu, Mar 29, 2012 at 4:05 PM, Tom Lane wrote: > I wrote: >> ... PREPARE/EXECUTE work a bit funny though: if you have >> track = all then you get EXECUTE cycles reported against both the >> EXECUTE statement and the underlying PREPARE.  This is because when >> PREPARE calls parse_analyze_varpara

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

I wrote: > ... PREPARE/EXECUTE work a bit funny though: if you have > track = all then you get EXECUTE cycles reported against both the > EXECUTE statement and the underlying PREPARE. This is because when > PREPARE calls parse_analyze_varparams the post-analyze hook doesn't know > that this isn't

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina wrote: D'oh, I munged the order. More technical concerns: > * Protocol compression -- but a bit of sand in the gears is *which* > compression -- for database workloads, the performance of zlib can be > a meaningful bottleneck. > * Something similar

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan wrote: 1. I've been in discussion with some people about adding simple JSON extract > functions. We already have some (i.e. xpath()) for XML. > > 2. You might find htsql interesting. My colleagues and myself have thought about t

Re: [HACKERS] ECPG FETCH readahead

2012-03-29 20:34 keltezéssel, Michael Meskes írta: On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote: Still, we're looking at dedicated ECPG syntax, quite visible even to folks with no interest in Informix. We have eschewed littering our syntax with compatibility aids, and I like it th

Re: [HACKERS] Finer Extension dependencies

Dimitri Fontaine writes: > Tom Lane writes: >> Peter Eisentraut writes: >>> At the very least, I would suggest that feature names are per-extension. >> Yeah, I had about come to that conclusion too. A global namespace for >> them would be a mistake given lack of central coordination. > That's

Re: [HACKERS] Finer Extension dependencies

Tom Lane writes: > Peter Eisentraut writes: >> At the very least, I would suggest that feature names are per-extension. > > Yeah, I had about come to that conclusion too. A global namespace for > them would be a mistake given lack of central coordination. That's how I did it first, but Alvaro o

Re: [HACKERS] Finer Extension dependencies

On Mar 29, 2012, at 11:48 AM, Robert Haas wrote: > Frankly, I'm not sure we bet on the right horse in not mandating a > version numbering scheme from the beginning. But given that we > didn't, we probably don't want to get too forceful about it too > quickly. However, we could ease into it by do

Re: [HACKERS] Finer Extension dependencies

On tor, 2012-03-29 at 14:39 -0400, Robert Haas wrote: > > but it breaks down when you, say, want to > > wrap your egg into a Debian package. > > *blink* Huh? Well, you can't represent that mechanism in a Debian (or RPM) package dependency. So the alternatives are make it a Recommends and add a f

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 2:25 PM, Tom Lane wrote: > Yeah.  AFAIK, nobody actually does that.  In my experience with Red Hat > packages, so-called "virtual Provides" (which are exactly equivalent to > this proposed feature) are used only for cases where there is or is > planned to be more than one p

Re: [HACKERS] Finer Extension dependencies

Peter Eisentraut writes: > At the very least, I would suggest that feature names are per-extension. Yeah, I had about come to that conclusion too. A global namespace for them would be a mistake given lack of central coordination. regards, tom lane -- Sent via pgsql-hac

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 2:28 PM, Peter Eisentraut wrote: > On ons, 2012-03-28 at 23:00 -0700, Hitoshi Harada wrote: >> I totally agree with Robert's point that one feature is not >> standardized and nobody can tell how you can depend on the feature in >> the end.  Mind you, I've never heard about

Re: [HACKERS] ECPG FETCH readahead

On Thu, Mar 29, 2012 at 01:03:41PM -0400, Noah Misch wrote: > Still, we're looking at dedicated ECPG syntax, quite visible even to folks > with no interest in Informix. We have eschewed littering our syntax with > compatibility aids, and I like it that way. IMO, an option to the "ecpg" > preproce

Re: [HACKERS] Finer Extension dependencies

On tor, 2012-03-29 at 09:51 +0200, Dimitri Fontaine wrote: > I don't want to introduce version dependency, because I don't think we > need it. If you want to compare what we're doing here with say debian > packaging, then look at how they package libraries. The major version > number is now part of

Re: [HACKERS] Finer Extension dependencies

On ons, 2012-03-28 at 23:00 -0700, Hitoshi Harada wrote: > I totally agree with Robert's point that one feature is not > standardized and nobody can tell how you can depend on the feature in > the end. Mind you, I've never heard about building dependency by its > name as a string in other packagin

Re: [HACKERS] Finer Extension dependencies

Robert Haas writes: > So the idea is that you're actually supposed to separately catalog > each feature you added (e.g. each new function), so that people can > depend specifically on those features. > I don't really have the foggiest idea how people using other packaging > systems handle this.

Re: [HACKERS] Finer Extension dependencies

Robert Haas writes: >>> provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5, >>> foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-2.3, >>> foobar-3.0, foobar-3.1 >> >> This is what I have expected to do. In new releases of pgTAP, I’d probably >> just add version lines. I mi

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 1:48 PM, David E. Wheeler wrote: > On Mar 29, 2012, at 4:42 AM, Robert Haas wrote: > >> 2. Add a new feature to the provides line with every release that does >> anything other than fix bugs, leading to: >> >> provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, fooba

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

I wrote: > Hm ... I just had a different idea. I need to go look at the code > again, but I believe that in the problematic cases, the post-analyze > hook does not compute a queryId for the optimizable statement. This > means that it will arrive at the executor with queryId zero. What if > we si

Re: [HACKERS] Finer Extension dependencies

On Mar 29, 2012, at 4:42 AM, Robert Haas wrote: > 2. Add a new feature to the provides line with every release that does > anything other than fix bugs, leading to: > > provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5, > foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-

Re: [HACKERS] Command Triggers patch v18

Apropos of nothing and since I haven't found a particularly good time to say this in amidst all the technical discussion, I appreciate very much all the work you've been putting into this. On Thu, Mar 29, 2012 at 12:42 PM, Dimitri Fontaine wrote: >> serious issues in the discussion we've had so f

Re: [HACKERS] Potential reference miscounts and segfaults in plpython.c

On Thu, Feb 23, 2012 at 8:35 PM, Daniele Varrazzo wrote: > On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański wrote: > >> BTW, that tool is quite handy, I'll have to try running it over psycopg2. > > Indeed. I'm having a play with it. It is reporting several issues to > clean up (mostly on failure at

Re: [HACKERS] ECPG FETCH readahead

On Thu, Mar 29, 2012 at 12:59:40PM +0200, Boszormenyi Zoltan wrote: > 2012-03-29 02:43 keltez?ssel, Noah Misch ?rta: >> On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote: >>> +toREADAHEAD number. ExplicitREADAHEAD >>> number or >>> +NO READAHEAD turns cursor readahead on >

Re: [HACKERS] Command Triggers patch v18

On Thu, Mar 29, 2012 at 12:17 PM, Dimitri Fontaine wrote: > Robert Haas writes: >>>     create command trigger before COMMAND_STEP of alter table >>>          execute procedure snitch(); >> >> One thought is that it might be better to say AT or ON or WHEN rather >> than BEFORE, since BEFORE END i

Re: [HACKERS] pgxs and bison, flex

Peter Eisentraut writes: > On ons, 2012-03-28 at 22:12 -0400, Tom Lane wrote: >> Won't this break usages such as in contrib/cube? > No, the code in my patch is conditional on 'ifdef PGXS'. (Not visible > in the patch, unfortunately.) Oh, okay. > I don't think we want to support external use of

Re: [HACKERS] pgxs and bison, flex

On ons, 2012-03-28 at 22:12 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > I propose that we apply the attached patch to make sure those variables > > are set to a usable default value in any case. > > Won't this break usages such as in contrib/cube? > > cubeparse.c: cubeparse.y > ifdef B

Re: [HACKERS] poll: CHECK TRIGGER?

2012/3/29 Heikki Linnakangas : > On 28.03.2012 23:54, Pavel Stehule wrote: >> >> 2012/3/28 Heikki Linnakangas: >> >>> In prepare_expr(), you use a subtransaction to catch any ERRORs that >>> happen >>> during parsing the expression. That's a good idea, and I think many of >>> the >>> check_* functi

Re: [HACKERS] Command Triggers patch v18

Robert Haas writes: > I've said repeatedly and over a long period of time that development > of this feature wasn't started early enough in the cycle to get it > finished in time for 9.2. I think that I've identified some pretty That could well be, yeah. > serious issues in the discussion we've

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

[ forgot to respond to this bit ] Robert Haas writes: > Another thought is: if we simply treated these as nested queries for > all purposes, would that really be so bad? That was actually what I suggested first, and now that I look at the code, that's exactly what's happening right now. However

Re: [HACKERS] Command Triggers patch v18

On Thu, Mar 29, 2012 at 11:49 AM, Thom Brown wrote: > On 29 March 2012 16:30, Dimitri Fontaine wrote: >> Robert Haas writes: >>> On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown wrote: On 29 March 2012 13:30, Dimitri Fontaine wrote: > I'll go make that happen, and still need input here. We

Re: [HACKERS] Command Triggers patch v18

Robert Haas writes: >>     create command trigger before COMMAND_STEP of alter table >>          execute procedure snitch(); > > One thought is that it might be better to say AT or ON or WHEN rather > than BEFORE, since BEFORE END is just a little strange; and also > because a future hook point mi

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

Robert Haas writes: > What I'm imagining is that instead of just having a global for > nested_level, you'd have a global variable pointing to a linked list. This is more or less what I have in mind, too, except I do not believe that a mere boolean flag is sufficient to tell the difference between

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On Thu, Mar 29, 2012 at 11:42 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane wrote: >>> However, I think there is a solution for that, though it may sound a bit >>> ugly.  Rather than just stacking a flag, let's stack the query source >>> text pointer for

Re: [HACKERS] poll: CHECK TRIGGER?

On 28.03.2012 23:54, Pavel Stehule wrote: 2012/3/28 Heikki Linnakangas: In prepare_expr(), you use a subtransaction to catch any ERRORs that happen during parsing the expression. That's a good idea, and I think many of the check_* functions could be greatly simplified by adopting a similar appro

Re: [HACKERS] Command Triggers patch v18

On 29 March 2012 16:30, Dimitri Fontaine wrote: > Robert Haas writes: >> On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown wrote: >>> On 29 March 2012 13:30, Dimitri Fontaine wrote: I'll go make that happen, and still need input here. We first want to have command triggers on specific comma

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

Robert Haas writes: > On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane wrote: >> However, I think there is a solution for that, though it may sound a bit >> ugly. Rather than just stacking a flag, let's stack the query source >> text pointer for the utility statement. Then in the executor hooks, >> i

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane wrote: > It would make more sense to me to go the other way, that is suppress > creation of a separate entry for the contained optimizable statement. > The stats will still be correctly accumulated into the surrounding > statement (or at least, if they ar

Re: [HACKERS] Command Triggers patch v18

Robert Haas writes: > On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown wrote: >> On 29 March 2012 13:30, Dimitri Fontaine wrote: >>> I'll go make that happen, and still need input here. We first want to >>> have command triggers on specific commands or ANY command, and we want >>> to implement 3 plac

Re: [HACKERS] Command Triggers patch v18

On Thu, Mar 29, 2012 at 8:30 AM, Dimitri Fontaine wrote: > I'll go make that happen, and still need input here. We first want to > have command triggers on specific commands or ANY command, and we want > to implement 3 places from where to fire them. > > Here's a new syntax proposal to cope with t

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

Robert Haas writes: > On Wed, Mar 28, 2012 at 10:39 PM, Tom Lane wrote: >> The SELECT INTO tests all fail, but we know the reason why (the testbed >> isn't expecting them to result in creating separate entries for the >> utility statement and the underlying plannable SELECT). > This might be a d

Re: [HACKERS] HTTP Frontend? (and a brief thought on materialized views)

On 03/29/2012 10:37 AM, Dobes Vandermeer wrote: Hi guys, Something from Josh's recent blog post about summer of code clicked with me - the HTTP / SQL concept. It was something I'd been thinking about earlier, how people really like HTTP APIs and this is one of the drivers behind adoption o

[HACKERS] HTTP Frontend? (and a brief thought on materialized views)

Hi guys, Something from Josh's recent blog post about summer of code clicked with me - the HTTP / SQL concept. It was something I'd been thinking about earlier, how people really like HTTP APIs and this is one of the drivers behind adoption of some "NoSQL" databases out there. Some things that

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Thu, Mar 29, 2012 at 03:23:01PM +0100, Simon Riggs wrote: > On Thu, Mar 29, 2012 at 3:04 PM, Marko Kreen wrote: > > Next question: how can flipping archive_mode on and off, > > with restarts, near wraparound point, break epoch on master? > > > >  http://lists.pgfoundry.org/pipermail/skytools-us

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Thu, Mar 29, 2012 at 3:04 PM, Marko Kreen wrote: > On Thu, Mar 29, 2012 at 02:46:23PM +0100, Simon Riggs wrote: >> On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs wrote: >> > Patch coming in a few hours. >> >> This is more straightforward than I was thinking. We just need to >> initialise XLogCt

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Thu, Mar 29, 2012 at 02:46:23PM +0100, Simon Riggs wrote: > On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs wrote: > > Patch coming in a few hours. > > This is more straightforward than I was thinking. We just need to > initialise XLogCtl at the right place. Looks good to me. That should fix t

Re: [HACKERS] Command Triggers patch v18

On Thu, Mar 29, 2012 at 9:01 AM, Thom Brown wrote: > On 29 March 2012 13:30, Dimitri Fontaine wrote: >> I'll go make that happen, and still need input here. We first want to >> have command triggers on specific commands or ANY command, and we want >> to implement 3 places from where to fire them.

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Thu, Mar 29, 2012 at 12:06 PM, Simon Riggs wrote: > Patch coming in a few hours. This is more straightforward than I was thinking. We just need to initialise XLogCtl at the right place. --  Simon Riggs   http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Tra

Re: [HACKERS] Command Triggers patch v18

On 29 March 2012 13:30, Dimitri Fontaine wrote: > I'll go make that happen, and still need input here. We first want to > have command triggers on specific commands or ANY command, and we want > to implement 3 places from where to fire them. > > Here's a new syntax proposal to cope with that: > >

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 8:01 AM, Kevin Grittner wrote: > Robert Haas  wrote: > >> I think that technically this patch can be polished well enough to >> commit in the time we have available, but the question of whether >> it's the right design is harder, and I don't want that to be my >> call alone

Re: [HACKERS] Finer Extension dependencies

"Kevin Grittner" writes: > I gather from previous posts that the intent isn't to allow different > packages from different authors to provide a common and compatible > feature; but what happens in the current design if someone > accidentally or maliciously produces an extension which provides the

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 1:01 PM, Kevin Grittner wrote: > I gather from previous posts that the intent isn't to allow different > packages from different authors to provide a common and compatible > feature; but what happens in the current design if someone > accidentally or maliciously produces an

Re: [HACKERS] Command Triggers patch v18

Robert Haas writes: > I am sure that we could find a way to beat this with a stick until it > behaves, but I don't really like that idea. It seems to me to be a [...] > we should learn from that lesson: when you may want to have a bunch of I first wanted to ensure that reusing existing parser ke

Re: [HACKERS] ECPG FETCH readahead

2012-03-29 12:59 keltezéssel, Boszormenyi Zoltan írta: 2012-03-29 02:43 keltezéssel, Noah Misch írta: On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote: +the window size may be modified by setting theECPGFETCHSZ +environment variable to a different value. I had in min

Re: [HACKERS] Finer Extension dependencies

Robert Haas wrote: > I think that technically this patch can be polished well enough to > commit in the time we have available, but the question of whether > it's the right design is harder, and I don't want that to be my > call alone. I gather from previous posts that the intent isn't to allo

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 4:37 AM, Dimitri Fontaine wrote: > Hitoshi Harada writes: >> So my question is why you cannot depend on ip4r in that case.  If some >> version of the module introduces ipv6, then let's depend on that >> version.  It doesn't explain why a string feature name is needed. > >

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On 29 March 2012 02:09, Tom Lane wrote: > Thanks.  I've committed the patch along with the docs, after rather > heavy editorialization. Thank you. > 1. What to do with EXPLAIN, SELECT INTO, etc.  We had talked about > tweaking the behavior of statement nesting and some other possibilities. > I t

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Thu, Mar 29, 2012 at 11:12 AM, Marko Kreen wrote: > On Thu, Mar 29, 2012 at 10:37:54AM +0100, Simon Riggs wrote: >> When the standby receives the checkpoint record, it stores the >> information in 2 places: >> i) directly into ControlFile->checkPointCopy >> ii) and then into XLogCtl when a safe

Re: [HACKERS] Command Triggers patch v18

On Wed, Mar 28, 2012 at 3:41 PM, Dimitri Fontaine wrote: > What about : > >  create command trigger foo before prepare alter table … >  create command trigger foo before start of alter table … >  create command trigger foo before execute alter table … >  create command trigger foo before end of al

Re: [HACKERS] Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On Wed, Mar 28, 2012 at 10:39 PM, Tom Lane wrote: > The SELECT INTO tests all fail, but we know the reason why (the testbed > isn't expecting them to result in creating separate entries for the > utility statement and the underlying plannable SELECT). This might be a dumb idea, but for a quick ha

Re: [HACKERS] patch for parallel pg_dump

On Wed, Mar 28, 2012 at 9:54 PM, Joachim Wieland wrote: > On Wed, Mar 28, 2012 at 1:46 PM, Robert Haas wrote: >> I'm wondering if we really need this much complexity around shutting >> down workers.  I'm not sure I understand why we need both a "hard" and >> a "soft" method of shutting them down.

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Thu, Mar 29, 2012 at 10:37:54AM +0100, Simon Riggs wrote: > When the standby receives the checkpoint record, it stores the > information in 2 places: > i) directly into ControlFile->checkPointCopy > ii) and then into XLogCtl when a safe restartpoint occurs In RecoveryRestartPoint() I see: - me

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Wed, Mar 28, 2012 at 10:54 PM, Simon Riggs wrote: > On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs wrote: >> On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote: >>> On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote: Master pg_controldata - OK txid_current_snapshot() - OK St

Re: [HACKERS] Finer Extension dependencies

Hi, Thanks for your review! Robert Haas writes: > I think the lack of pg_upgrade support is a must-fix before commit. I though that would only be a TODO for 9.2 to 9.3 upgrades. When upgrading from 9.1 to 9.2, pg_upgrade will directly stuff extensions using InsertExtensionTuple() with an empty

Re: [HACKERS] Finer Extension dependencies

Hitoshi Harada writes: > So my question is why you cannot depend on ip4r in that case. If some > version of the module introduces ipv6, then let's depend on that > version. It doesn't explain why a string feature name is needed. The only operator we have to compare version strings in PostgreSQL

Re: [HACKERS] Standbys, txid_current_snapshot, wraparound

On Wed, Mar 28, 2012 at 10:54:58PM +0100, Simon Riggs wrote: > On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs wrote: > > On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote: > >> On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote: > >>> Master pg_controldata - OK txid_current_snapshot() -

Re: [HACKERS] Finer Extension dependencies

On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine wrote: > Hitoshi Harada writes: >> Frankly I'm still against this patch.  Since I started to review it >> I've never been convinced with the use case.  Yeah, someone said it'd >> be useful to him, but as a developer of some of PGXN modules I don'

Re: [HACKERS] Finer Extension dependencies

Hitoshi Harada writes: > Frankly I'm still against this patch. Since I started to review it > I've never been convinced with the use case. Yeah, someone said it'd > be useful to him, but as a developer of some of PGXN modules I don't > see it. I totally agree with Robert's point that one featur

Re: [HACKERS] pg_terminate_backend for same-role

On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote: > On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote: >> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote: >> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote: >> >> Parallel to pg_cancel_backend, it'd be nice to allow the user to j