On Tue, Apr 26, 2011 at 11:51:35PM -0400, Noah Misch wrote:
> On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
> [input functions aren't the only problematic source of uninitialized datum
> bytes]
>
> > We've run into other manifestations of this issue before. Awhile ago
> > I made a pu
--- On Mon, 5/23/11, nil nil wrote:
Sir
i have read all that material from that link it gives me overall detail
but i am still not clear how to develop it. what softwares i need to use, how
to integrate with postgresql, i want to know the basic steps for patch
development.
if
sorry, actually becuase of one printf statement(i have added) because of
that, these has been occured. My mistake
On Mon, May 23, 2011 at 9:06 AM, Robert Haas wrote:
> On Sun, May 22, 2011 at 6:42 AM, Nick Raj wrote:
> > I am using contrib/cube code. I am building GIST index on cube data type
>
Robert Haas writes:
> I believe, however, that applying this will invalidate the contents of
> any hash indexes on array types that anyone has built using 9.1beta1.
> Do we need to do something about that?
Like bumping catversion?
I would probably complain about that, except you already did it p
On Sun, May 22, 2011 at 6:42 AM, Nick Raj wrote:
> I am using contrib/cube code. I am building GIST index on cube data type
> then it leads to a very large size of log file (nearly 220 MB for only 12k
> records).
> While creating index on geometry field with gist gives 1KB size of log file
> for 1
On Thu, May 19, 2011 at 10:36 PM, Josh Kupershmidt wrote:
> Precisely, and I think there's a solid argument for putting
> constraints into bucket 1 above, as this patch does, since there's no
> good room to display constraint comments inside \d+, and there's no
> backslash command specifically for
On Fri, May 20, 2011 at 1:43 AM, Dean Rasheed wrote:
> Doh! I forgot one important piece of this algorithm - it is necessary
> to initialise the result to something non-zero at the start so that
> adding leading nulls to an array changes the final result.
Looks reasonable.
I believe, however, th
On Sun, May 22, 2011 at 10:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
>>> But also, 99.999% of the time
>>> it would be completely wasted effort because the DBA wouldn't remove the
>>> postgresql.conf setting at all, ever.
>
>> Well, by that
Robert Haas wrote:
> I think the implementation is what matters here. I understand that
> there are certain situations in which the user might choose to
> UPDATE a row and other situations in which they might choose to
> DELETE and then INSERT: but the user's intent is basically
> irrelevant.
Robert Haas writes:
> On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
>> But also, 99.999% of the time
>> it would be completely wasted effort because the DBA wouldn't remove the
>> postgresql.conf setting at all, ever.
> Well, by that argument, we ought not to worry about masterminding what
>
On Sun, May 22, 2011 at 9:39 PM, Bruce Momjian wrote:
> Tim Uckun wrote:
>> pg_upgrade from 8.4 to 9.0 fails with the following error message.
>>
>> old and new cluster lc_collate values do not match
>>
>>
>> on 8.4 show lc_collate outputs
>>
>> en_NZ.utf8
>> (1 row)
>>
>>
>> on 9.0
On Sun, May 22, 2011 at 9:54 PM, Tom Lane wrote:
>> If not, then how about jiggering things somehow so that only one
>> server process needs to run the hack? Perhaps it can drop the result
>> in a file or shared memory or something from which the remaining
>> backends can read it out without havi
Robert Haas writes:
> On Thu, May 19, 2011 at 12:19 PM, Tom Lane wrote:
>> What would make everybody happy is to find a way of identifying the
>> system timezone that isn't such a massive, expensive kluge. Any ideas?
> ...reads the code...
> Good grief. What an incredibly ugly hack. Is there s
Tim Uckun wrote:
> pg_upgrade from 8.4 to 9.0 fails with the following error message.
>
> old and new cluster lc_collate values do not match
>
>
> on 8.4 show lc_collate outputs
>
> en_NZ.utf8
> (1 row)
>
>
> on 9.0 it outputs
>
> en_NZ.UTF8
> (1 row)
>
>
> So the
On Thu, May 19, 2011 at 12:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 19, 2011 at 12:12 PM, Tom Lane wrote:
>>> We could do that, but the issue that this code is trying to avoid is
>>> that identify_system_timezone can easily add several seconds to the
>>> postmaster startup tim
On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus wrote:
>> Another point is that parsing overhead is quite obviously not the
>> reason for the massive performance gap between one core running simple
>> selects on PostgreSQL and one core running simple selects on MySQL.
>> Even if I had (further) evi
On Sun, May 22, 2011 at 3:23 PM, Jim Nasby wrote:
> These all stemmed from beers Friday night...
>
> David Wheeler: "I'm trying to picture Tom Lane as a kid... Was he constantly
> rewriting the other kid's homework?"
>
> Greg Smith: "When bullies said they were going to take Tom's lunch money,
>
Josh,
From: "Joshua Berkus"
Could you give me your frank opinions about which of 8.4 or 9.0 you
recommend to ISVs who embed PostgreSQL?
So, first of all, you posted this question to the wrong list.
pgsql-general or pgsql-admin would have been more appropriate for this
question.
However, a
On Fri, May 20, 2011 at 17:45, Peter Eisentraut wrote:
> On fre, 2011-05-20 at 14:19 -0400, Magnus Hagander wrote:
>> > I suggest we add an argument-less option -z that means "compress",
>> and
>> > then -Z can be relegated to choosing the compression level.
>>
>> We can't just use -Z without a pa
These all stemmed from beers Friday night...
David Wheeler: "I'm trying to picture Tom Lane as a kid... Was he constantly
rewriting the other kid's homework?"
Greg Smith: "When bullies said they were going to take Tom's lunch money, he'd
ask if they had proof."
Jeremy Lawler remarked that th
2011/5/22 Tom Lane :
> Alvaro Herrera writes:
>> Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011:
>>> A implementation of ERROR_CONTEXT is not without impact on
>>> performance, because context should be collected when exception is
>>> caught. One solution is removing a ERR
Alvaro Herrera writes:
> Excerpts from Pavel Stehule's message of sáb may 21 16:05:01 -0400 2011:
>> A implementation of ERROR_CONTEXT is not without impact on
>> performance, because context should be collected when exception is
>> caught. One solution is removing a ERROR_CONTEXT from proposal.
Robert,
> Another point is that parsing overhead is quite obviously not the
> reason for the massive performance gap between one core running simple
> selects on PostgreSQL and one core running simple selects on MySQL.
> Even if I had (further) eviscerated the parser to cover only the
> syntax tho
MauMau,
> Could you give me your frank opinions about which of 8.4 or 9.0 you
> recommend to ISVs who embed PostgreSQL?
So, first of all, you posted this question to the wrong list. pgsql-general or
pgsql-admin would have been more appropriate for this question.
That being said, I find your st
Hi,
I am using contrib/cube code. I am building GIST index on cube data type
then it leads to a very large size of log file (nearly 220 MB for only 12k
records).
While creating index on geometry field with gist gives 1KB size of log file
for 17 lakh records.
Can someone please tell me how to stop
The attached patch fixes up case handling in foreign tables.
Now it didn't assign security label on foreign table on its creation
time, and didn't check access rights on the dml hook.
This patch fixes these problems; It allows foreign tables default
labeling and access checks as db_table object cl
I am trying to build plPython for Python 3.2 64bit under Windows 7 with
Microsoft Windows SDK v7.0 (all tools are 64bit). I downloaded Python from
python.org
I get this error:
"C:\Users\user\Desktop\postgresql-9.0.4\pgsql.sln" (default target) (1) ->
(PLs\plpython target) ->
.\src\pl\plpython\pl
27 matches
Mail list logo
