On Thu, 2009-11-26 at 08:30 +0200, Heikki Linnakangas wrote:
I suspect you missed the context of this change. It's about the code
in tablespc.c, to kill all backends that might have a temporary file
in a tablespace that's being dropped. It's not about tuple visibility
but temporary files.
Got
On Thu, Nov 26, 2009 at 11:14:54AM -0500, Tom Lane wrote:
Michael Meskes mes...@postgresql.org writes:
I wrote a hackish little script that checks if all rules in ecpg.addons are
indeed used to create the precompiler's parser to catch renamed symbol and
similar changes. Now I wonder whether
On Tue, 2009-11-24 at 22:13 -0800, Jeff Davis wrote:
My disagreement with the row-by-row approach is more semantics than
performance. COPY translates records to bytes and vice-versa, and your
original patch maintains those semantics.
The bytes - records conversion is a costly one. Anything we
Peter Eisentraut pete...@gmx.net writes:
+ printfPQExpBuffer(errorMessage,
+ libpq_gettext(ERROR: service
\%s\ not found\n), service);
Please make the message consistent with the rest of libpq. AFAICS none
of the other messages in
Planner (find_usable_indexes function, actually) could push pathkey
expression into restriction clauses of index. I'm not fully satisfied
with this piece of code, but, may be, someone has a better idea. I
though about adding separate indexorderquals in IndexPath structure...
Done, IndexScan
Teodor Sigaev teo...@sigaev.ru writes:
Planner (find_usable_indexes function, actually) could push pathkey
expression into restriction clauses of index. I'm not fully satisfied
with this piece of code, but, may be, someone has a better idea. I
though about adding separate indexorderquals in
On Wed, 2009-11-25 at 13:00 +0200, Heikki Linnakangas wrote:
I've put up a wiki page with the issues I see with the patch as it
stands. They're roughly categorized by seriousness.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO
New issues can and probably will still pop up, let's add them
Done, IndexScan and IndexPath have separate field to store order clauses.
Why? Isn't that redundant with the pathkey structures? We generate
enough paths during a complex planning problem that I'm not in favor
of adding unnecessary structures to them.
I found two ways to add support of
Teodor Sigaev teo...@sigaev.ru writes:
Do you suggest to construct that clauses from pathkey representation? And
append
constructed clauses to indexquals in create_indexscan_plan?
I'd probably have to read the patch to make any intelligent suggestions
... and right now I'm busy with
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Tom Lane wrote:
since OIDs in user tables have been deprecated for several versions
now, I'm thinking that maybe the case doesn't arise often enough to
justify keeping such a wart in the executor.
Under the circumstances I'd lean towards
I wrote:
I think this is worth doing since it cleans up one of the grottier
parts of executor initialization. The whole thing around
ExecContextForcesOids was never pretty, and it's been the source of
more than one bug if memory serves.
On further review there's a really serious stumbling
On Fri, 2009-11-27 at 13:39 +, Simon Riggs wrote:
On Tue, 2009-11-24 at 22:13 -0800, Jeff Davis wrote:
My disagreement with the row-by-row approach is more semantics than
performance. COPY translates records to bytes and vice-versa, and your
original patch maintains those semantics.
Recently openssl has been patched to not renegotiate keys.
http://www.links.org/?p=780
After a certain amount of data has gone through a postgresql connection
the server will attempt to switch session keys.
What is the workaround (if any ) to avoid this in postgresql ?
Dave
--
Sent via
Dave Cramer p...@fastcrypt.com writes:
Recently openssl has been patched to not renegotiate keys.
http://www.links.org/?p=780
After a certain amount of data has gone through a postgresql connection
the server will attempt to switch session keys.
What is the workaround (if any ) to avoid this
Tom Lane wrote:
Dave Cramer p...@fastcrypt.com writes:
Recently openssl has been patched to not renegotiate keys.
http://www.links.org/?p=780
After a certain amount of data has gone through a postgresql connection
the server will attempt to switch session keys.
What is the workaround (if
Dave Cramer davecra...@gmail.com writes:
Tom Lane wrote:
Install the updated openssl library. Why are you bugging us about
an openssl patch?
After applying the updated openssl library slony dies, presumably
because the server requests a new session key
The discussion I saw suggested that
Tom Lane wrote:
Dave Cramer davecra...@gmail.com writes:
Tom Lane wrote:
Install the updated openssl library. Why are you bugging us about
an openssl patch?
After applying the updated openssl library slony dies, presumably
because the server requests a new session key
The discussion I
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
Tom Lane wrote:
The discussion I saw suggested that you need such a patch at both ends.
and likely requires a restart of both postgresql and slony afterwards...
Actually, after looking through the available info about this:
On fre, 2009-11-27 at 10:22 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
+ printfPQExpBuffer(errorMessage,
+ libpq_gettext(ERROR: service
\%s\ not found\n), service);
Please make the message consistent with the
Robert Haas robertmh...@gmail.com writes:
I guess it's somewhat unsurprising that you can make the planner get
into trouble with the above settings - we've been over that ground
before. But it might be possibly interesting that such a simple
schema is capable of generating so many paths.
Review comments:
* I attached some documentation suggestions.
* The patch should be merged with CVS HEAD. The changes required are
minor; but notice that there is a minor style difference in the assert
in vacuum().
* vacuumdb should reject -i without -f
* The replace or inplace option is a
On Fri, Nov 27, 2009 at 3:05 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 9, 2009 at 1:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 9, 2009 at 1:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 9, 2009 at 10:57 AM, Tom
On Sat, Nov 28, 2009 at 12:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's not so much so-many-paths as so-many-join-relations that's killing
it. I put some instrumentation into join_search_one_level to count the
number of joinrels it was creating, and got this before getting bored:
This is
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 9, 2009 at 1:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yowza. 18000 distinct paths for one relation? Could we see the test
case?
Hey, wait a minute. Unless I'm missing something, the items being
accumulated here are not paths (as Tom
Jeff Davis wrote:
All I mean is that the second argument to
COPY should produce/consume bytes and not records. I'm not discussing
the internal implementation at all, only semantics.
In other words, STDIN is not a source of records, it's a source of
bytes; and likewise for STDOUT.
In the
marcin mank marcin.m...@gmail.com writes:
This is pretty off-topic, but if we had some upper bound on the cost
of the complete plan, we could discard pieces of the plan that already
cost more.
One way to get the upper bound is to generate the plan in depth-first
fashion, instead of the
26 matches
Mail list logo
