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 (pgsql-hac
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
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 10:3
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 g
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 o
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 631
"Albe Laurenz" writes:
> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
> in this case, which makes #include 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 changes for this in CVS, plea
Alvaro Herrera 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 conclusion I had co
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.co
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.
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 max_standby_de
2009/11/10 Alvaro Herrera :
> 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 Herrera
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 Herrerahttp://www.CommandProm
2009/11/10 Alvaro Herrera :
> Tom Lane wrote:
>> Alvaro Herrera 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 trans
Stephen Tyler writes:
> On Tue, Nov 10, 2009 at 8:57 PM, Jan Otto 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 writ
Tom Lane wrote:
> Alvaro Herrera 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 I'm thinkin
> 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
FYI, Heikki has fixed this bug and the fix will appear in Postgres 8.5.
---
Andrew Gierth wrote:
> > "Heikki" == Heikki Linnakangas
> > writes:
>
> Heikki> Oops, you're right. The check is indeed confusing julian
"Albe Laurenz" 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 makes #include
Marko Tiikkaja 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 allow DML withou
Tom Lane wrote:
Marko Tiikkaja 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 planner, it look
Marko Tiikkaja 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 planner, it looked to me like th
Tom Lane wrote:
Marko Tiikkaja 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 to point B.
On Tue, Nov 10, 2009 at 2:56 PM, Marko Tiikkaja
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. AFAICS this is jus
Bruce Momjian 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 mentioned earlier
Marko Tiikkaja 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 to point B.
> Right
On Tue, Nov 10, 2009 at 8:57 PM, Jan Otto 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
> septemb
On Tue, Nov 10, 2009 at 2:19 PM, Bruce Momjian 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 postgresql.conf
(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, but
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 be
Marko Tiikkaja 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 the output of that Query.
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
> > =
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
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.
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
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:
>
>
>
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 differen
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,
R
>> 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
39 matches
Mail list logo
