Re: [HACKERS] tuplestore API problem

2009/3/28 Tom Lane : > Hitoshi Harada writes: >> 2009/3/27 Hitoshi Harada : >>> 2009/3/27 Tom Lane : A brute-force solution is to change tuplestore_gettupleslot() so that it always copies the tuple, but this would be wasted cycles for most uses of tuplestores.  I'm thinking of chang

Re: [HACKERS] 8.4 release notes proof reading 1/2

On Mar 27, 2009, at 6:40 PM, Bruce Momjian wrote: Thanks, text updated: While semi-joins merely replace existing IN joins, anti-joins are a new capability for NOT EXISTS clauses (Tom) This improves optimization possibilities. I'm not enough of a relational algebra geek to re

[HACKERS] TODO item

In the TODO list there is an item "[D] Completed itemAdd array_agg() and UNNEST functions for arrays " marked as done but 5 items below there is: "Add SQL-standard array_agg() and unnest() array functions " it's the same item so this one should be removed... or there is a difference between the arr

[HACKERS] psql \d* and system objects

The psql system object display issue has not been completely resolved for 8.4; see 8.4 open items: http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes So what is the proposal? Have U/S/A flags for all commands and have different system display default for each command? I

Re: [HACKERS] PQinitSSL broken in some use casesf

Andrew Chernow wrote: > Bruce Momjian wrote: > > > I think there is a good argument that PQinitSSL(X) where X > 1 would > > work fine for more fine-grained control. The new libpq init function > > idea was interesting, but having a documented solution for > > WSAStartup()/WSACleanup() usage, we n

Re: [HACKERS] Should SET ROLE inherit config params?

Josh Berkus wrote: > > > Josh, this isn't a rejection. Both Tom and I asked for more exploration > > of the implications of doing as you suggest. Tom has been more helpful > > than I was in providing some scenarios that would cause problems. It is > > up to you to solve the problems, which is ofte

Re: [HACKERS] PQinitSSL broken in some use casesf

Bruce Momjian wrote: I think there is a good argument that PQinitSSL(X) where X > 1 would work fine for more fine-grained control. The new libpq init function idea was interesting, but having a documented solution for WSAStartup()/WSACleanup() usage, we now don't have another libpq init use-cas

Re: [HACKERS] parallel restore

Andrew Dunstan wrote: > > > Tom Lane wrote: > > Andrew Dunstan writes: > > > >> Tom Lane wrote: > >> > >>> There is an unfinished TODO item here: we really ought to make it work > >>> for tar-format archives. That's probably not hugely difficult, but > >>> I didn't look into it, and don

Re: [HACKERS] pg_migrator progress

Tom Lane wrote: > Gregory Stark writes: > > Tom Lane writes: > >> No, but this would just be the same situation that prevails after > >> OID-counter wraparound, so I don't see a compelling need for us to > >> change the OID counter in the new DB. If the user has done the Proper > >> Things (ie,

Re: [HACKERS] PQinitSSL broken in some use casesf

Merlin Moncure wrote: > On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian wrote: > > Merlin Moncure wrote: > >> > PQinitSSL(0) was specifically designed to allow applications to set up > >> > SSL on their own. How does this not work properly? > >> > >> this has nothing to do with who initializes ssl

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Robert Lor writes: > Tom Lane wrote: >> [ complaining about disabled probes not being no-ops ] > 1) Only use if (foo_ENABLED()) test for probes with expensive function > call/computation in arguments. This will keep the code clean, and we can > document this in the "Definine New Probes" sectio

Re: [HACKERS] typedefs for indent

Bruce Momjian wrote: > Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > Alvaro Herrera wrote: > > > > Huh? What false positive problem? > > > > > > typedefs listed on platforms that match identifiers in our code that are > > > _not_ typedefs. > > > > Does this actually happen anywhere? > >

Re: [HACKERS] typedefs for indent

Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > Anyway, I think a diff of using my list and Andrew's list will show us > > which one gets things clearest; the diff is going to highlight only > > cases where the typedef lists change formatting. > > > > Andrew, where exactly is the list I sho

Re: [HACKERS] typedefs for indent

Bruce Momjian wrote: Anyway, I think a diff of using my list and Andrew's list will show us which one gets things clearest; the diff is going to highlight only cases where the typedef lists change formatting. Andrew, where exactly is the list I should try? fetch it from

Re: [HACKERS] typedefs for indent

Alvaro Herrera wrote: > Bruce Momjian wrote: > > Alvaro Herrera wrote: > > > Bruce Momjian wrote: > > > > > > > Well, as you, I was hoping for a clear solution, and it seems we don't > > > > have one. I think the false-positives problem is real and might make > > > > the greater code coverage of

Re: [HACKERS] SSL over Unix-domain sockets

Peter Eisentraut wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > >> Bruce Momjian wrote: > >>> I thought the logical solution to this was to place the socket in a > >>> secure directory and not bother with SSL at all. > >> How would a client algorithmically determine whether the server

Re: [HACKERS] 8.4 release notes proof reading 1/2

Andrew Gierth wrote: > > "Guillaume" == Guillaume Smet writes: > > Guillaume> - "While semi-joins merely replace existing IN joins, > Guillaume> anti-joins are a new capability for NOT IN and NOT EXIST > Guillaume> clauses (Tom) This improves optimization possibilities." > Guillaume> -> r

Re: [HACKERS] typedefs for indent

Bruce Momjian wrote: > Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > > > Well, as you, I was hoping for a clear solution, and it seems we don't > > > have one. I think the false-positives problem is real and might make > > > the greater code coverage of the buildfarm worse than what we did

Re: [HACKERS] 8.4 open items list

Robert Haas wrote: > > Wow, that is a large list. ?Getting this all on a wiki is really what > > needed to happen. ?I can't keep an open list current enough to be > > useful. > > Ah, glad you like. I thought you'd been arguing the other side of > that point with me for several days, but no matte

Re: [HACKERS] typedefs for indent

Alvaro Herrera wrote: > Bruce Momjian wrote: > > > Well, as you, I was hoping for a clear solution, and it seems we don't > > have one. I think the false-positives problem is real and might make > > the greater code coverage of the buildfarm worse than what we did for > > 8.3. > > Huh? What fal

Re: [HACKERS] typedefs for indent

Tom Lane wrote: > Bruce Momjian writes: > > Frankly, I don't remember anyone complaining we didn't find any typedefs > > in pgindent, > > There are lots and lots of places where it's obvious that pgindent > was misinformed on the subject, because it puts in a space where there > should not be one

Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?

On Fri, Mar 27, 2009 at 08:59:29PM +, Andrew Gierth wrote: > > "Tom" == Tom Lane writes: > > > Andrew Gierth writes: > >> GET DIAGNOSTICS ROW_COUNT is documented as working for all commands; > >> if it doesn't work for MOVE (and FETCH), that's a bug. > > Tom> Or a documentation prob

Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?

> "Tom" == Tom Lane writes: > Andrew Gierth writes: >> GET DIAGNOSTICS ROW_COUNT is documented as working for all commands; >> if it doesn't work for MOVE (and FETCH), that's a bug. Tom> Or a documentation problem. I don't see any claim that it works for Tom> "all commands" anyway. "

Re: [HACKERS] small but useful patches for text search

Oleg Bartunov writes: > I and Teodor have several small, but useful patches for text search: > ... > We would like to have your opinion what to do with these patches - leave them > for 8.5 or provide them to hackers to review for 8.4. I think the general consensus is that these were submitted to

Re: [HACKERS] improving concurrent transactin commit rate

On Wed, Mar 25, 2009 at 01:48:03PM -0500, Kenneth Marshall wrote: > On Wed, Mar 25, 2009 at 05:56:02PM +, Sam Mason wrote: > > On Wed, Mar 25, 2009 at 12:01:57PM -0500, Kenneth Marshall wrote: > > > Are you sure that you are able to actually drive the load at the > > > high end of the test regi

Re: [HACKERS] 8.4 open items list

It seems that we have full consensus about the following Open Items not being material for 8.4, so I'm going to move them to the TODO list or Commitfest 2009-First as appropriate: * Change behavior of statement-level triggers for inheritance cases? No patch, no interest in making it happen for 8.

[HACKERS] Documentation Update: Document pg_start_backup checkpoint behavior

Hi, small patch for the documentation describing the current pg_start_backup checkpoint behavior as per http://archives.postgresql.org//pgsql-general/2008-09/msg01124.php . Should we note down a TODO to revisit the current checkpoint handling? best regards, Michael diff --git a/doc/src/sgml/

Re: [HACKERS] Solaris getopt_long and PostgreSQL

Zdenek Kotala writes: > Dne 17.03.09 19:48, Chuck McDevitt napsal(a): >> Any obviously, we don't just use ours for platforms with no or broken >> getopt_long, >> since we are talking Solaris (which has a bug in getopt, but >> getopt_long works fine) > Just for clarification: > It is not bug i

Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?

Andrew Gierth writes: > GET DIAGNOSTICS ROW_COUNT is documented as working for all commands; > if it doesn't work for MOVE (and FETCH), that's a bug. Or a documentation problem. I don't see any claim that it works for "all commands" anyway. regards, tom lane -- Sent vi

Re: [HACKERS] Error message and infinite date and timestamp conversion in XML

Bernd Helmle writes: > map_sql_value_to_xml_value() currently errors out with a more or less vague > error message, when a date or timestamp datatype with an infinite value is > converted to XML. This is likely to create some confusion, especially when > you have to debug some complex procedure

Re: [HACKERS] 8.4 open items list

Josh Berkus writes: > And Magnus fixed this one: > * Path separator consistency on Windows Uh, no, that's still an open issue. Magnus put up a proposed patch that I didn't like. I think it's arguable that we should be going the other way: convert backslashes to slashes. Magnus's patch is

Re: [HACKERS] 8.4 open items list

On Fri, Mar 27, 2009 at 1:46 PM, Josh Berkus wrote: > All, > >> On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas >>  wrote: >>> >>> I think we should also boot everything in the "pre-existing bugs" >>> category, > > I don't agree.  I think we should fix as many of those as we can without > holding up

Re: [HACKERS] 8.4 open items list

All, On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote: I think we should also boot everything in the "pre-existing bugs" category, I don't agree. I think we should fix as many of those as we can without holding up the release. Having been (briefly) in charge of Another Open Source Data

Re: [HACKERS] Should SET ROLE inherit config params?

On Fri, Mar 27, 2009 at 12:33 PM, Tom Lane wrote: > Robert Haas writes: >> I think this is way over-engineered.  All we really need here is a >> command along the lines of RESET ALL AS CURRENT USER that gives every >> GUC the value it would have had if you logged in under the current >> user's ac

Re: [HACKERS] Should SET ROLE inherit config params?

Josh Berkus writes: >> Simon's idea of "profiles" sounds worth pursuing to me, but clearly >> it's not happening for 8.4. > I don't see why having a *separate* concept of profiles in addition to > the ROLES is helpful. It seems like building a whole new house when all > we really need is to ex

Re: [HACKERS] 8.4 open items list

On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane wrote: >> PQinitSSL broken in some use cases > > This is a hard case.  It's arguably a bug fix, but not one that we could > back-patch.  I think we would have applied it by now if there were > consensus on which solution to pick. I think the consensus we

Re: [HACKERS] Should SET ROLE inherit config params?

Tom, BTW, does pg_dumpall know to dump ALTER USER SET settings attached to built-in roles (such as the proposed "autovacuum" role)? I'd bet it doesn't do that. Even if it does, that seems like a more awkward way to push settings over to a new installation than copying your postgresql.conf file

Re: [HACKERS] SSL over Unix-domain sockets

Robert Haas writes: > On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut wrote: >> But there is `hostname` and `hostname --fqdn`, both of which are well-defined >> independent of a connection. > But they aren't guaranteed to return anything useful, and IME often don't. I think "well defined" is

Re: [HACKERS] Should SET ROLE inherit config params?

Robert Haas writes: > I think this is way over-engineered. All we really need here is a > command along the lines of RESET ALL AS CURRENT USER that gives every > GUC the value it would have had if you logged in under the current > user's account. Simple, clean, no new keywords. Doesn't do anyth

Re: [HACKERS] SSL over Unix-domain sockets

On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut wrote: > On Friday 27 March 2009 14:46:32 Greg Stark wrote: >> Regarding using the hostname of the system... There's no such thing. >> Interfaces have names, hosts can have multiple interfaces so the can >> have multiple names... > > But there is `

Re: [HACKERS] Should SET ROLE inherit config params?

On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs wrote: > On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote: > >> I was just noticing that doing SET ROLE changes the current session's >> priviledges, but not any runtime configuration parameters (like work_mem >> or statement_timeout) associated wit

Re: [HACKERS] Potential problem with HOT and indexes?

I wrote: > We could reorganize the function slightly so that the IndexInfo is > still available after the PG_TRY block, and then do something like > "if (!indexInfo->ii_BrokenHotChain) reset indcheckxmin". This would > ensure that we didn't wipe the flag if index_build had just set it. > If I'm wr

Re: [HACKERS] 8.4 open items list

Robert Haas writes: > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items > That includes a whole slough of patches that weren't submitted until > after November 1st and which I think should probably be bumped en > masse to 8.5: > Change behavior of statement-level triggers for inheritance

Re: [HACKERS] tuplestore API problem

Hitoshi Harada writes: > 2009/3/27 Hitoshi Harada : >> 2009/3/27 Tom Lane : >>> A brute-force solution is to change tuplestore_gettupleslot() so that it >>> always copies the tuple, but this would be wasted cycles for most uses >>> of tuplestores.  I'm thinking of changing tuplestore_gettupleslot'

Re: [HACKERS] psql: Make tab completion work for ANALYZE VERBOSE ...

Greg Sabino Mullane wrote: I find that that particular rule is formatted differently than the others. It took me a while to figure out how it works. Yeah, me too, but I was trying to keep my change inline with the local logic, so to speak. +1 to making it more consistent. Ok, committed with t

Re: [HACKERS] typedefs for indent

Bruce Momjian wrote: > Well, as you, I was hoping for a clear solution, and it seems we don't > have one. I think the false-positives problem is real and might make > the greater code coverage of the buildfarm worse than what we did for > 8.3. Huh? What false positive problem? -- Alvaro Herre

Re: [HACKERS] delete quite skip updated rows

Pavel Stehule writes: > explain analyze signalise one deleted row, but this is not true This is not a bug. The explain output tells you that one row was found by the seqscan, which is true. It doesn't tell you whether the delete machinery did anything with that row. The row could be suppressed

Re: [HACKERS] New trigger option of pg_standby

On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Simon Riggs wrote: > >> If we go with this, I would suggest we make *neither* the default by > >> removing -t, and adopting two new options: something like -f == fast > >> failover, -p == patient failover. > > > -m

[HACKERS] delete quite skip updated rows

Hello one my customer reported following problem (checked on 8.4 and 8.3.6) test case: create table test(a integer); create or replace function getid(_a integer) returns integer as $$ begin update test set a = _a where a = _a; return _a; end; $$ language plpgsql; insert into test values(20

Re: [HACKERS] New trigger option of pg_standby

Peter Eisentraut writes: > Simon Riggs wrote: >> If we go with this, I would suggest we make *neither* the default by >> removing -t, and adopting two new options: something like -f == fast >> failover, -p == patient failover. > -m smart|fast|immediate :-) +1 for using a "-m something" type of s

Re: [HACKERS] postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail

Selena Deckelmann writes: > ParseConfigFile currently exits on the first parsing error. Changed > guc_file.l to report all parsing errors before exiting: This seems like basically a good idea, but consider what happens if you make a really major-league screwup in your postgresql.conf (say, you a

Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships

Ciao Josh, Josh Berkus ha scritto: What this all hinges on is getting some really solid mentors who have projects they'd like students to work on, and can commit unconditionally to having 5 hours a week or more, over a 3-month period, to work with the student. Thanks for letting us know. Howev

Re: [HACKERS] 8.4 open items list

On Thu, Mar 26, 2009 at 11:06 PM, Guillaume Smet wrote: > On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote: >> That includes a whole slough of patches that weren't submitted until >> after November 1st and which I think should probably be bumped en >> masse to 8.5: >> >> postgresql.conf: patch

Re: [HACKERS] SSL over Unix-domain sockets

On Friday 27 March 2009 14:46:32 Greg Stark wrote: > Regarding using the hostname of the system... There's no such thing. > Interfaces have names, hosts can have multiple interfaces so the can > have multiple names... But there is `hostname` and `hostname --fqdn`, both of which are well-defined i

Re: [HACKERS] psql: Make tab completion work for ANALYZE VERBOSE ...

> I find that that particular rule is formatted differently than the > others. It took me a while to figure out how it works. Yeah, me too, but I was trying to keep my change inline with the local logic, so to speak. +1 to making it more consistent. > While we're at it, any idea what the logic be

Re: [HACKERS] 8.4 open items list

On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander wrote: > That can be argued to just be completing the pg_hba rewrite stuff that > happened long before november with the final logical step. > > I guess if you stretch that definition as well, this could also be an > extension to that :) Yes, that

Re: [HACKERS] New trigger option of pg_standby

On Fri, 2009-03-27 at 13:19 +0100, Guillaume Smet wrote: > On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut wrote: > > Simon Riggs wrote: > >> > >> If we go with this, I would suggest we make *neither* the default by > >> removing -t, and adopting two new options: something like -f == fast > >>

Re: [HACKERS] Crash in gist insertion on pathological box data

On Thu, Mar 26, 2009 at 5:39 PM, Andrew Gierth wrote: > A user on IRC reported a crash (backend segfault) in GiST insertion > (in 8.3.5 but I can reproduce this in today's HEAD) that turns out > to be due to misbehaviour of gist_box_picksplit. > > The nature of the problem is this: if gist_box_pic

Re: [HACKERS] New trigger option of pg_standby

Fujii Masao wrote: On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet wrote: On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs wrote: I like the idea of removing -t and adding 2 new options so that people are warned about the intended behavior. OK, I'll change the patch as Simon suggested; removing

Re: [HACKERS] SSL over Unix-domain sockets

Regarding using the hostname of the system... There's no such thing. Interfaces have names, hosts can have multiple interfaces so the can have multiple names... I haven't follwes the discussion so I'm not sure if you have an existing connection. If so you can get the local interface address

Re: [HACKERS] display previous query string of idle-in-transaction

On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet wrote: > 2009/3/27 Tatsuhito Kasahara : >> But if I can also check last query string, I guess which apllication >> do that and point out the problem point. > > Oh, I just understand why you want this patch. I usually have one > database per server so

Re: [HACKERS] New trigger option of pg_standby

On Fri, Mar 27, 2009 at 3:38 AM, Fujii Masao wrote: > OK, I'll change the patch as Simon suggested; removing -t and adding > two new options: -f = fast failover (existing behavior), -p patient failover. > Also I'll default the patient failover, so it's performed when the signal > (SIGINT or SIGUSR

Re: [HACKERS] New trigger option of pg_standby

On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut wrote: > Simon Riggs wrote: >> >> If we go with this, I would suggest we make *neither* the default by >> removing -t, and adopting two new options: something like -f == fast >> failover, -p == patient failover. > > -m smart|fast|immediate :-) Th

Re: [HACKERS] 8.4 open items list

On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas wrote: > Perhaps so, but again, it's not a new regression, so why should it be > considered a blocker for 8.4beta? I agree they shouldn't. You were talking about bumping them to 8.5 which is a totally different thing. -- Guillaume -- Sent via pgsql

Re: [HACKERS] tuplestore API problem

he current row from tuplestore > instead of pointing directly to inside tuplestore memory, not changing > tuplestore API. Here's the patch. Hope there are no more on the same reason. It seems that we'd need to implement something like garbage collector in tuplestore, marking and tra

Re: [HACKERS] New trigger option of pg_standby

On Fri, 2009-03-27 at 13:56 +0200, Peter Eisentraut wrote: > Simon Riggs wrote: > > If we go with this, I would suggest we make *neither* the default by > > removing -t, and adopting two new options: something like -f == fast > > failover, -p == patient failover. > > -m smart|fast|immediate :-)

Re: [HACKERS] New trigger option of pg_standby

Simon Riggs wrote: If we go with this, I would suggest we make *neither* the default by removing -t, and adopting two new options: something like -f == fast failover, -p == patient failover. -m smart|fast|immediate :-) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

Re: [HACKERS] display previous query string of idle-in-transaction

On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs wrote: > Or take it further back still and think about why "idle in transaction" > occurs at all and fix *that*. Maybe not in Postgres at all, possibly in > the driver or even higher up client stack. >From my experience, the main reasons for this probl

Re: [HACKERS] SSL over Unix-domain sockets

Peter Eisentraut wrote: > Magnus Hagander wrote: Perhaps it's enough to add a "localssl" row to pg_hba.conf? >>> That defeats the point, I think. You don't want the server to determine >>> whether the client should verify the server. >> >> Good point. OTOH, client behavior can be controlled n

Re: [HACKERS] SSL over Unix-domain sockets

Magnus Hagander wrote: Perhaps it's enough to add a "localssl" row to pg_hba.conf? That defeats the point, I think. You don't want the server to determine whether the client should verify the server. Good point. OTOH, client behavior can be controlled now fine by setting it to "require" or "p

Re: [HACKERS] SSL over Unix-domain sockets

Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: I thought the logical solution to this was to place the socket in a secure directory and not bother with SSL at all. How would a client algorithmically determine whether the server socket was in a "secure" directory? You have

Re: [HACKERS] 8.4 open items list

On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote: > I think we should also boot everything in the "pre-existing bugs" > category, and the first two items from the "questions" category, which > don't seem important enough to worry about at this stage of the game. > That would leave us with 14 ite

Re: [HACKERS] 8.4 open items list

Guillaume Smet wrote: > On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote: >> That includes a whole slough of patches that weren't submitted until >> after November 1st and which I think should probably be bumped en >> masse to 8.5: >> >> postgresql.conf: patch to have ParseConfigFile report all

Re: [HACKERS] psql: Make tab completion work for ANALYZE VERBOSE ...

Greg Sabino Mullane wrote: Quick patch to fix the fact that the EXPLAIN ANALYZE VERBOSE is clobbering tab-completion for ANALYZE VERBOSE. Thanks. *** tab-complete.c 24 Feb 2009 10:06:34 - 1.180 --- tab-complete.c 27 Mar 2009 01:29:06 - *** *** 1627,1633

Re: [HACKERS] Any reason not to return row_count in cursor of plpgsql?

> "Bruce" == Bruce Momjian writes: >> hi all, >> >> I read the code that it seems easy for the cursor in plpgsql to >> return ROW_COUNT after MOVE LAST etc. The SPI_processed variable >> already there, but didn't put it into estate structure, any reason >> for that? >> >> thanks and

Re: [HACKERS] 8.4 release notes proof reading 1/2

> "Guillaume" == Guillaume Smet writes: Guillaume> - "While semi-joins merely replace existing IN joins, Guillaume> anti-joins are a new capability for NOT IN and NOT EXIST Guillaume> clauses (Tom) This improves optimization possibilities." Guillaume> -> remove the "(Tom)", s/EXIST/EXISTS

Re: [HACKERS] 8.4 open items list

On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian wrote: >> Hmm, well, Tom dropped a filtered version of your list into the open >> items wiki page. >> >> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items >> >> That includes a whole slough of patches that weren't submitted until >> after Nov

Re: [HACKERS] display previous query string of idle-in-transaction

Simon Riggs wrote: >> Does that answer your question ? > > Not really. I want to understand the actual problem with > idle-in-transaction so we can consider all ways to solve it, rather than > just focus on one method. "idle in transaction timeout" feature may be one of the ways. But I have no spe

Re: [HACKERS] display previous query string of idle-in-transaction

On Fri, 2009-03-27 at 16:49 +0900, Tatsuhito Kasahara wrote: > Simon Riggs wrote: > >> Does that answer your question ? > > > > Not really. I want to understand the actual problem with > > idle-in-transaction so we can consider all ways to solve it, rather than > > just focus on one method. > "id

Re: [HACKERS] Should SET ROLE inherit config params?

On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote: > I was just noticing that doing SET ROLE changes the current session's > priviledges, but not any runtime configuration parameters (like work_mem > or statement_timeout) associated with the new role. > > This is as documented (although I w

Re: [HACKERS] display previous query string of idle-in-transaction

2009/3/27 Tatsuhito Kasahara : > But if I can also check last query string, I guess which apllication > do that and point out the problem point. Oh, I just understand why you want this patch. I usually have one database per server so I didn't see your point. Considering this usage, +1 for me. --

Re: [HACKERS] display previous query string of idle-in-transaction

On Fri, 2009-03-27 at 15:44 +0900, Tatsuhito Kasahara wrote: > Simon Riggs wrote: > >> If we can also check previous query_string of idle-in-transaction, > >> it is useful for analysis of long transaction problem. > > > > I'm more interested in the problem itself. Why do you think there is a > >

Re: [HACKERS] display previous query string of idle-in-transaction

Simon Riggs wrote: >> If we can also check previous query_string of idle-in-transaction, >> it is useful for analysis of long transaction problem. > > I'm more interested in the problem itself. Why do you think there is a > problem and why does knowing this help you? I had similar problems > recen