Hello Markus,
Thanks for the reply.
For the past one week postgreSQL service has been running absolutely fine
-:)
Also there is no OOM killer application on the windows 2003 server. I
haven't made any changes on the machine since first the service failed.
Nothing in the event logs also.
Can
Hi,
Bhaskar Sirohi wrote:
Also there is no OOM killer application on the windows 2003 server.
I also didn't think so, but who commanded the server to shutdown, then?
Can there be any another reason why the service failed ?
Well, yes, sure. But if you don't answer the important questions,
Tom Lane [EMAIL PROTECTED] writes:
We could probably fix this by complicating the logic in ExecUnique,
but I wonder whether it wouldn't be better to just stop treating
Unique nodes as backwards-scannable. The only reason for that
node type to exist (as opposed to using Group nodes) is that
Gregory Stark [EMAIL PROTECTED] writes:
Hm, that has the nasty side effect that someone who uses SCROLL but doesn't
fetch backwards much or at all suddenly gets a much more expensive plan than
if they didn't.
Well, what are they using SCROLL for if they don't need it?
A more plausible
The following bug has been logged online:
Bug reference: 4341
Logged by: Lampa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Debian 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC
2008 x86_64 GNU/Linux
Description:planner doesn't using
The following bug has been logged online:
Bug reference: 4342
Logged by: paull
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2? not sure
Operating system: ubuntu
Description:upper, lower, initcap do not work with umlaute?
Details:
Hello
I suspect this is
Hello
2008/8/6 paull [EMAIL PROTECTED]:
The following bug has been logged online:
Bug reference: 4342
Logged by: paull
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2? not sure
Operating system: ubuntu
Description:upper, lower, initcap do not work
Lampa [EMAIL PROTECTED] writes:
With varchar_pattern_ops planner is not using index(first explain) but when
use LIKE index is used.
I must create another index without varchar_pattern_ops flag to get equal
speed results.
Yup, this is expected behavior because '=' is not part of the
I was hoping that the a newer version of postgres ( 8.1.11 ) would solve
the problem we see when we use order by to get a listing of names. Let
me explain the problem.
Suppose we have the following 3 names in a table:
Ta, A
Ta, Z
Tab, A
I would expect them to show up in the oder shown above
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Hm, that has the nasty side effect that someone who uses SCROLL but doesn't
fetch backwards much or at all suddenly gets a much more expensive plan than
if they didn't.
Well, what are they using SCROLL for if they
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
... I'm not even sure how to fix it (the nasty case is
changing directions partway through the scan); let alone how to fix it in a
way that's obviously enough right to make me feel comfortable in
back-patching.
It
Blanco, Jose [EMAIL PROTECTED] writes:
Suppose we have the following 3 names in a table:
Ta, A
Ta, Z
Tab, A
I would expect them to show up in the oder shown above when odering by
by name, but instead I get:
Ta, A
Tab, A
Ta, Z
This is not a bug. Or at least you have not offered
12 matches
Mail list logo
