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
recently, so
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
problem and
2009/3/27 Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp:
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.
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 want
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.
idle in
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 specific
On Thu, Mar 26, 2009 at 10:11 PM, Bruce Momjian br...@momjian.us 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
Bruce == Bruce Momjian br...@momjian.us 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 best
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
Guillaume == Guillaume Smet guillaume.s...@gmail.com 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),
Guillaume Smet wrote:
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
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
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
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 now fine by
On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs si...@2ndquadrant.com 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
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
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 :-)
Yes, a
, marking and tracing each row references, if the complete
solution is required.
Regards,
--
Hitoshi Harada
windowagg_tempslot.20090327.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut pete...@gmx.net 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
On Fri, Mar 27, 2009 at 3:38 AM, Fujii Masao masao.fu...@gmail.com 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
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
2009/3/27 Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp:
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
Fujii Masao wrote:
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com 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
On Thu, Mar 26, 2009 at 5:39 PM, Andrew Gierth
and...@tao11.riddles.org.uk 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
On Fri, 2009-03-27 at 13:19 +0100, Guillaume Smet wrote:
On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut pete...@gmx.net 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
On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas robertmh...@gmail.com 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
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
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
On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander mag...@hagander.net 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
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
On Thu, Mar 26, 2009 at 11:06 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
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.
Selena Deckelmann sel...@endpoint.com 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
Peter Eisentraut pete...@gmx.net 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
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
On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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.
Pavel Stehule pavel.steh...@gmail.com 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
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 Herrera
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
Hitoshi Harada umi.tan...@gmail.com writes:
2009/3/27 Hitoshi Harada umi.tan...@gmail.com:
2009/3/27 Tom Lane t...@sss.pgh.pa.us:
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.
Robert Haas robertmh...@gmail.com 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
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 wrong and
On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs si...@2ndquadrant.com 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)
On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com 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.
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut pete...@gmx.net 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
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.
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us 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
Josh Berkus j...@agliodbs.com 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
On Fri, Mar 27, 2009 at 12:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
All,
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haasrobertmh...@gmail.com 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
On Fri, Mar 27, 2009 at 1:46 PM, Josh Berkus j...@agliodbs.com wrote:
All,
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haasrobertmh...@gmail.com
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
Josh Berkus j...@agliodbs.com 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.
Bernd Helmle maili...@oopsware.de 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
Andrew Gierth and...@tao11.riddles.org.uk 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.
Zdenek Kotala zdenek.kot...@sun.com 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
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
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
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 regime? You
Oleg Bartunov o...@sai.msu.su 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
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Andrew Gierth and...@tao11.riddles.org.uk 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
On Fri, Mar 27, 2009 at 08:59:29PM +, Andrew Gierth wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Andrew Gierth and...@tao11.riddles.org.uk 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 Lane wrote:
Bruce Momjian br...@momjian.us 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
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 false positive
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 matter - it
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 for
8.3.
Andrew Gierth wrote:
Guillaume == Guillaume Smet guillaume.s...@gmail.com 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.
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 socket
was in
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 the buildfarm worse
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
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 should try?
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?
No idea; it was more a
Robert Lor robert@sun.com 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
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us 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
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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't
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
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 often
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 now don't
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
80 matches
Mail list logo
