My inclination is to continue assuming that the EINVAL is a new bug
introduced in Snow Leopard. I sure hope they fix it in 10.6.2 though.
If they don't, we may have to think about a workaround, messy as that
will apparently be.
10.6.2 is out, and it appears to fix the bug --- if I remove
Hello, I would suggest the inclusion an option to create the database
accent-insensitive,
without need to use functions that in some cases it's slow to return the
result.
Example:
select name from table where name ilike 'joão'
Return:
joão
joao
JOAO
JOÃO
Text by: Google translator
Regards,
Hi,
While working on writeable CTEs, I noticed I have to special-case the
output of a Query node frequently because in INSERT/UPDATE/DELETE query
targetList is the target list which is used for modifying the result
relation and returningList is the output of that Query. However, this
is
I CC: this to the hackers list as it seems to be an old problem that
was never fixed. See at the bottom.
Alexandra Roy wrote:
This is a summary of what I have noticed concerning
PostgreSQL 8.3.8 compilation on AIX 5.3 TL9.
1. To do a successful 64-bit build, specify and execute:
rgc.tech wrote:
Hello, I would suggest the inclusion an option to create the
database accent-insensitive,
without need to use functions that in some cases it's slow to return
the result.
Example:
select name from table where name ilike 'joão'
Yes, this is in the current development branch
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to search_path, though that's even more complex because the order of
the entries is significant.
Josh Berkus wrote:
Kevin,
I'm talking about how the decision should be made as to which takes
precedence. It's fine to document which one *was* chosen, but that
doesn't eliminate the problem of conflicting settings making a mess.
Someone else (Robert maybe?) gave an explicit example
David Fetter wrote:
On Mon, Nov 09, 2009 at 09:01:14PM -0500, Bruce Momjian wrote:
I have applied the attached patch to document that FOUND is not affected
by EXECUTE, while GET DIAGNOSTICS is.
One minor nit here:
Index: doc/src/sgml/plpgsql.sgml
On Tue, 2009-11-10 at 08:59 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to search_path, though that's even more complex because
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
While working on writeable CTEs, I noticed I have to special-case the
output of a Query node frequently because in INSERT/UPDATE/DELETE query
targetList is the target list which is used for modifying the result
relation and returningList is
(Sorry, forgot to CC the list)
Tom Lane wrote:
This doesn't really seem like a good idea from here. You're changing
a decision that has something like twenty years' standing in the code,
for no real gain. AFAICS this is just going to move the special cases
from point A to point B.
Right,
On Tue, Nov 10, 2009 at 2:19 PM, Bruce Momjian br...@momjian.us wrote:
There was discussion of whether the directory files or postgresql.conf
file has precedence. If postgresql.conf has precedence, tools changing
values might not work, and if the directory has precendence, someone
changing
On Tue, Nov 10, 2009 at 8:57 PM, Jan Otto as...@me.com wrote:
Someone else please confirm? If so I'll revert that patch.
Yes i can confirm that this bug is fixed in Mac OS X 10.6.2. I have checked
it twice.
With removed workaround in tablespace.c and with my self written testcase
from
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Tom Lane wrote:
This doesn't really seem like a good idea from here. You're changing
a decision that has something like twenty years' standing in the code,
for no real gain. AFAICS this is just going to move the special cases
from point A
Bruce Momjian br...@momjian.us wrote:
A more radical approach would be for the server to refuse to start
if a setting is set in more than one file, and for the server to
report both locations. That would reduce the guesswork about
problems.
-1
I see that as a big step backward. As
On Tue, Nov 10, 2009 at 2:56 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
(Sorry, forgot to CC the list)
Tom Lane wrote:
This doesn't really seem like a good idea from here. You're changing
a decision that has something like twenty years' standing in the code,
for no real gain.
Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Tom Lane wrote:
This doesn't really seem like a good idea from here. You're changing
a decision that has something like twenty years' standing in the code,
for no real gain. AFAICS this is just going to move the special
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
I wouldn't care for this at all, but with things the way they are right
now, the writeable CTE patch has to do quite a few of these:
[ shrug... ] How many is quite a few? In a quick search for existing
references to targetList in the
Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
I wouldn't care for this at all, but with things the way they are right
now, the writeable CTE patch has to do quite a few of these:
[ shrug... ] How many is quite a few? In a quick search for existing
references to
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Tom Lane wrote:
if (query-returningList)
cteList = query-returningList;
else
cteList = query-targetList;
My initial thought is that this won't work because there might not be a
RETURNING clause, but I'm not sure.
Hm, would we
Albe Laurenz laurenz.a...@wien.gv.at writes:
Why the OBJECT_MODE exported to 32 is not sufficient ?
I dug around a little, and the problem is in psqlscan.c which is generated
from psqlscan.l by flex.
The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
in this case, which
FYI, Heikki has fixed this bug and the fix will appear in Postgres 8.5.
---
Andrew Gierth wrote:
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
Heikki Oops, you're right. The check is
I would not complain if the server logged duplicates. (That would
actually be a minor blessing, as the startup would log all our
deviations from standard -- at least if our standard had an explicit
entry.)
I agree with Kevin here: duplicate logging +1. Not starting on
duplicates: -10^32
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Looks OK, but please update the comment right before the
RecordTransactionCommit, along the lines of We prevent cancel
interrupts after this point to mitigate the problem that you
can't abort the transaction now.
BTW
Stephen Tyler step...@stephen-tyler.com writes:
On Tue, Nov 10, 2009 at 8:57 PM, Jan Otto as...@me.com wrote:
Someone else please confirm? If so I'll revert that patch.
Yes i can confirm that this bug is fixed in Mac OS X 10.6.2. I have checked
it twice.
With removed workaround in
2009/11/10 Alvaro Herrera alvhe...@commandprompt.com:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Looks OK, but please update the comment right before the
RecordTransactionCommit, along the lines of We prevent cancel
interrupts after this point to mitigate the problem
Pavel Stehule escribió:
Hello
do you have a idea abou lazy vacuum lockinkg problem?
any plans?
Well, I understand the issue and we have an idea on how to attack it,
but I have no concrete plans to fix it ATM ...
--
Alvaro Herrera
2009/11/10 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
Hello
do you have a idea abou lazy vacuum lockinkg problem?
any plans?
Well, I understand the issue and we have an idea on how to attack it,
but I have no concrete plans to fix it ATM ...
ok
Pavel
--
Alvaro
On Tue, 2009-11-10 at 20:36 +0200, Heikki Linnakangas wrote:
Attached is the latest and greatest patch against CVS head, taken from
the hs-riggs branch in my git repository.
Is there a reason why recovery.conf.sample does not include (sample)
entries for recovery_connections and
On Nov 10, 2009, at 13:36 , Heikki Linnakangas wrote:
Attached is the latest and greatest patch against CVS head, taken from
the hs-riggs branch in my git repository.
Awesome. Thank you, Simon and Heikki!
I skimmed through the documentation to get a better handle on what
this will mean.
Tom Lane wrote:
In most of the other cases the #include is done in an associated .y
file, but there is none in psql. Anyone have a thought which of
psql's .c files would be the most appropriate host?
mainloop.c?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
In most of the other cases the #include is done in an associated .y
file, but there is none in psql. Anyone have a thought which of
psql's .c files would be the most appropriate host?
mainloop.c?
Yeah, that's about the same
Albe Laurenz laurenz.a...@wien.gv.at writes:
The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
in this case, which makes #include unistd.h fail.
Does anyone have an idea how to best fix this problem in the
source tree? I'm willing to implement and test.
I've committed
I encountered the following log in 8.4.1 and HEAD. The deadlock occured
on the same object (relation 17498 of database 17497). Is it reasonable?
ERROR: deadlock detected
DETAIL: Process 6313 waits for ExclusiveLock on relation 17498 of database
17497; blocked by process 6312.
Process
On 11/10/09 5:59 AM, Bruce Momjian wrote:
Simon Riggs wrote:
All of this *also* applies to shared_preload_libraries. We also need to
be able to specify new load libraries without editing the same darn
parameter.
And to search_path, though that's even more complex because the order of
the
Robert Haas wrote:
The next CommitFest is scheduled to start in a week. So far, it
doesn't look too bad, though a lot could change between now and then.
I would personally prefer not to be involved in the management of the
next CommitFest. Having done all of the July CommitFest and a good
Hi,
I was using auto_explain to log plans (with analyze option on) from
queries that take more than 500ms, something i found i little odd is
that the duration says 779ms but actual time says 269ms (almost 3
times lower), maybe some kind of instrumentation cleanup can explain
this?
2009-11-10
On Sun, 8 Nov 2009, Robert Haas wrote:
I would personally prefer not to be involved in the management of the
next CommitFest. Having done all of the July CommitFest and a good
chunk of the September CommitFest, I am feeling a bit burned out.
I was just poking around on the Wiki, and it looks
Michael Glaesemann wrote:
Other commands are in all-caps. Any reason INSERT, UPDATE, DELETE,
TRUNCATE, CREATE, DROP, ALTER, and COMMENT are not?
No. Thanks, I'll fix that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
39 matches
Mail list logo
