Neil Conway <[EMAIL PROTECTED]> writes:
> Thoughts?
One comment is that there are worse things than small memory leaks in
seldom-followed code paths, especially if those paths are only taken in
error cases. I'm interested in fixing this if it can be done without
unreasonable code complication, bu
While thinking about how to do memory management for the TupleDesc
refcounting changes, it occurred to me that this coding pattern is
dangerous:
local_var = MemoryContextAlloc(TopMemoryContext, ...);
func_call();
/* ... */
/* update global state */
if (global != NULL)
pfree(global);
global = l
[EMAIL PROTECTED] writes:
> Just for curiosity: suppose there is an excellent index frequently picked by
> the optimizer. Suppose now that this index became extremelly fragmented with
> thousands of updates. Without a REINDEX, will Optimizer still pick it? Or the
> optimizer is smart enough to dete
That's not really the point. The ISO 8601 standard allows midnight to be
expressed as 00:00:00 or 24:00:00 to enable you to tell which midnight is
being referred to (ie. The beginning or the end of the day).
PostgreSQL allows you to make use of that part of the standard, and as admin
tool authors
On Tue, 10 Jan 2006, Michael Fuhr wrote:
On Tue, Jan 10, 2006 at 07:44:23PM -0700, Michael Fuhr wrote:
I just ran "cvs update" in my 8.1 source tree and it took nearly
25 minutes to complete; it usually takes about 30-60 seconds. Is
anybody else seeing problems?
I forgot to mention that this
On Tue, Jan 10, 2006 at 07:44:23PM -0700, Michael Fuhr wrote:
> I just ran "cvs update" in my 8.1 source tree and it took nearly
> 25 minutes to complete; it usually takes about 30-60 seconds. Is
> anybody else seeing problems?
I forgot to mention that this is anonymous cvs (anoncvs.postgresql.or
I just ran "cvs update" in my 8.1 source tree and it took nearly
25 minutes to complete; it usually takes about 30-60 seconds. Is
anybody else seeing problems?
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will
Hi,
Just for curiosity: suppose there is an excellent index frequently picked by
the optimizer. Suppose now that this index became extremelly fragmented with
thousands of updates. Without a REINDEX, will Optimizer still pick it? Or the
optimizer is smart enough to detect index fragmentation and di
FWIW, results from a FBSD6.0 box. Between every run I ran code to zero
800MB (out of 1G) of memory, which should have effectively flushed the
OS cache (it would just put the OS into swapping).
Reading 1% (1280/128000 blocks 1048576000 bytes) total time 6870595us
MB/s 1.53 effective MB/s 152.62
Rea
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've been working with SQL Server for a long time and many times I had to
> change how an index page is filled with fillfactor clause. I've noticed that
> PostgreSQL doesn't have anything like that, am I right?
>
> I'd like to imple
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-01-09 at 22:08 -0500, Greg Stark wrote:
>
> > So it's not the 8k block reading that's fooling Linux into reading ahead
> > 32k.
> > It seems 32k readahead is the default for Linux, or perhaps it's the
> > sequential access pattern that's tr
Dave Page writes:
> That's not really the point. The ISO 8601 standard allows midnight to be
> expressed as 00:00:00 or 24:00:00 to enable you to tell which midnight is
> being referred to (ie. The beginning or the end of the day).
There are other reasons for allowing it that have nothing to do w
Tony, Dave,
> That's not really the point. The ISO 8601 standard allows midnight to be
> expressed as 00:00:00 or 24:00:00 to enable you to tell which midnight
> is being referred to (ie. The beginning or the end of the day).
IIRC, the reason for supporting 24:00:00 is that some popular client
l
On 10/1/06 18:00, "Tony Caduto" <[EMAIL PROTECTED]> wrote:
> Dave Page wrote:
>
>>
>> On looking further it appears to me that 24:00:00 is not a leap second
>> (which definitely can be 23:50:60), but just another way of expressing
>> midnight.
>>
>> From: http://www.cl.cam.ac.uk/~mgk25/iso-t
On Mon, 2006-01-09 at 22:08 -0500, Greg Stark wrote:
> So it's not the 8k block reading that's fooling Linux into reading ahead 32k.
> It seems 32k readahead is the default for Linux, or perhaps it's the
> sequential access pattern that's triggering it.
Nah, Linux 2.6 uses flexible readahead logi
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> Harald Fuchs <[EMAIL PROTECTED]> writes:
>> Bruce Momjian writes:
>>> A leap second will show as 24:00:00. It is a valid time.
>> Shouldn't such a leap second be represented as '... 23:59:60'?
> People who didn't like 24:00
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Harald Fuchs
> Sent: 10 January 2006 16:53
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Question about Postgresql time
> fields(possible bug)
>
> In article <[EMAIL PROTECTED]>,
> Br
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> A leap second will show as 24:00:00. It is a valid time.
> Shouldn't such a leap second be represented as '... 23:59:60'?
People who didn't like 24:00:00 would complain about that, too ;-)
Actually, my recollection is that we
In article <[EMAIL PROTECTED]>,
Bruce Momjian writes:
> Tony Caduto wrote:
>> Hi,
>> I just noticed today that Postgresql accepts a value of 24:00:00, this
>> is for sure not correct as there is no such thing as 24:00:00
>>
>> PG Admin III will display this value just fine which is also incorre
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Moreover, the unset state shouldn't exist at all. No parameter can behave
> reasonably if unset behaved differently from an empty string. Explicitly
> assigning an unset state doesn't work. So it seems that for all external
> communication, an un
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Caduto
> Sent: 10 January 2006 15:38
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Question about Postgresql time fields(possible bug)
>
> Hi,
> I just noticed today that Postgresql a
Tony Caduto wrote:
> Hi,
> I just noticed today that Postgresql accepts a value of 24:00:00, this
> is for sure not correct as there is no such thing as 24:00:00
>
> PG Admin III will display this value just fine which is also incorrect,
> PG Lightning Admin catches it as a invalid time, but sh
Hi,
I just noticed today that Postgresql accepts a value of 24:00:00, this
is for sure not correct as there is no such thing as 24:00:00
PG Admin III will display this value just fine which is also incorrect,
PG Lightning Admin catches it as a invalid time, but shouldn't there be
some valida
Peter Eisentraut wrote:
The function current_setting returns 'unset' if a parameter is not
set.
This is not documented,
It is documented to produce equivalent output as the sql SHOW command.
Although the reference page for SHOW does not specifically address
parameters that are not set, it
On Tue, 2006-01-10 at 09:47 -0500, Tom Lane wrote:
> I had a further thought about this. What we're really talking about
> here is a reference-counted TupleDesc structure: it's got no necessary
> connection to TypeCacheEntry at all.
Yeah, I came to basically the same conclusion when implementing
Am Dienstag, 10. Januar 2006 16:01 schrieb Tom Lane:
> That's because SHOW does the same thing. SHOW has a little problem in
> that it can't readily show the difference between "null" and an empty
> string, so while I find the behavior pretty ugly, I don't have a better
> idea.
Since SHOW is prim
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The function current_setting returns 'unset' if a parameter is not set.
> Should it not return null? This is not documented, so I guess this just
> arose out of the implementation, or is this intentional?
That's because SHOW does the same thing.
I had a further thought about this. What we're really talking about
here is a reference-counted TupleDesc structure: it's got no necessary
connection to TypeCacheEntry at all. And in fact there are other places
in the system that could use such a facility. For instance,
TupleTableSlot has a "sho
The function current_setting returns 'unset' if a parameter is not set.
Should it not return null? This is not documented, so I guess this just
arose out of the implementation, or is this intentional?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(en
29 matches
Mail list logo
