Now that I recognize the memory issue Andrew noted in his previous
review, I think we need to make a decision on this.
http://archives.postgresql.org/message-id/876397c68t@news-spur.riddles.org.uk
The problem is that for current eval_windowaggregate the node holds
wincontext to save the trans
Joshua Tolley writes:
> Makes sense on both counts. Thanks for the help. How does the attached look?
Applied with minor corrections, mainly around the state save/restore
logic. I also put in some code to fix the memory leak noted by Tim Bunce,
but am waiting for some confirmation that it's right
Robert Haas Wrote:
> Hmm. I'm not able to reliably detect a performance difference between
> unpatched CVS HEAD (er... git master branch) and same with spcoptions-
> v2.patch applied. I figured that if there were going to be an impact,
> it would be most likely to manifest itself in a query that
Alexey Klyukin writes:
> On Nov 20, 2009, at 3:50 PM, Tim Bunce wrote:
>> When does the reference held by desc.reference get freed?
>> At the moment it looks like this would leak memory for each DO.
> Isn't it also the case with the existing plperl code ? I've noticed that
> free(prodesc) is cal
On Fri, Nov 27, 2009 at 8:23 PM, Tom Lane wrote:
>> I don't think there's any easy fix for this.
>
> Nope :-(. I was able to get rid of the specific O(N^2) behavior that
> you were running into, but that just pushes the problem out a bit.
Yeah. Testing a couple of the cases I was looking at las
shakahsha...@gmail.com wrote:
> -- PostgreSQL database dump
> --
> -- pg_dump version: 8.5devel
> --
> -- remote database version: 8.5devel (80500)
> --
>
FWIW, and I havent read the entire thread, but pg_dump already *stores*
this information in a custom format. Try:
pg_dump -Fc blah
pg_rest
hernan gonzalez wrote:
> > hernan> The support of timezones is really crippled
> > ?hernan> now.
> >
> > Crippled how?
>
> Well, among other things, no builtin date-timetype allows me to save
> the timezone (or even the offset).
> No type allows to treat this three datetimes as different values.
On Sat, Nov 28, 2009 at 7:27 PM, Joshua Tolley wrote:
> On Sat, Nov 28, 2009 at 06:47:49PM -0500, Tom Lane wrote:
>> Dave Page writes:
>> > Updated application name patch, including a GUC assign hook to clean
>> > the application name of any unsafe characters, per discussion.
>>
>> Applied with a
On Sunday 29 November 2009 00:47:49 Tom Lane wrote:
> Dave Page writes:
> > Updated application name patch, including a GUC assign hook to clean
> > the application name of any unsafe characters, per discussion.
>
> Applied with assorted editorialization. There were a couple of
> definitional is
On Sat, Nov 28, 2009 at 06:47:49PM -0500, Tom Lane wrote:
> Dave Page writes:
> > Updated application name patch, including a GUC assign hook to clean
> > the application name of any unsafe characters, per discussion.
>
> Applied with assorted editorialization. There were a couple of
> definitio
Dave Page writes:
> Updated application name patch, including a GUC assign hook to clean
> the application name of any unsafe characters, per discussion.
Applied with assorted editorialization. There were a couple of
definitional issues that I don't recall if we had consensus on:
1. The patch p
Marko Tiikkaja writes:
> Attached is the latest version of the patch.
I looked through this patch and concluded that it still needs a fair
amount of work, so I'm bouncing it back for further work.
1. I thought we'd agreed at
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php
that
Tim Bunce wrote:
- Changed MULTIPLICITY check from runtime to compiletime.
No loads the large Config module.
ISTM the trouble with this is that it assumes that the library that we
compile with is the same as the library loaded at runtime. But there is
no guarantee of that at all.
P
13 matches
Mail list logo
