Re: [HACKERS] leaks in TopMemoryContext?
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, but there are limits to how far we should go to do it. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] leaks in TopMemoryContext?
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 = local_var; the idea being that we're allocating some memory that should live longer than the current transaction. For example, see circa line 141 in mb/mbutils.c:SetClientEncoding(). This works fine if no error occurs: presumably, the code takes care of releasing the allocation in TopMemoryContext when appropriate (as mbutils.c does). The problem arises if there is an error: suppose that func_call() in the example above elogs. The elog handler will abort the current transaction and reset per-transaction memory contexts, but TopMemoryContext will not be reset. Therefore the memory allocated for "local_var" will be leaked. To see the leak in practice, insert an elog(ERROR) in mbutils.c here: line 141: oldcontext = MemoryContextSwitchTo(TopMemoryContext); to_server = palloc(sizeof(FmgrInfo)); to_client = palloc(sizeof(FmgrInfo)); fmgr_info(to_server_proc, to_server); fmgr_info(to_client_proc, to_client); > elog(ERROR, "..."); MemoryContextSwitchTo(oldcontext); Running a stream of "SET client_encoding = 'koi8';" on my machine yields a steady growth in the size of the TopMemoryContext.[1] The elog(ERROR) above is inserted by hand to make the problem easier to reproduce, but it is certainly possible for the calls to palloc() or fmgr_info() to fail for legitimate reasons during normal usage (e.g. OOM in the case of palloc(), or a multitude of reasons for fmgr_info()). I'm not sure if there's a clean way to fix the problem. One solution would be to enclose code that does allocations in TopMemoryContext in a PG_TRY block. We could then pfree() the local variable in a PG_CATCH block (provided that the "global = local_var" assignment hasn't occurred yet). Unfortunately, that's pretty ugly, and requires adding hackery to every site where this coding pattern occurs. Thoughts? -Neil P.S. It occurs to me that the mbutils code is actually busted anyway, as it assumes that a pfree'ing the FmgrInfo is sufficient to release all the resources allocated by fmgr_info(). However, this is not the case: the CurrentMemoryContext when fmgr_info() is called is used to allocate additional things. mbutils ought to invoke fmgr_info() in its own long-lived memory context -- but that is unrelated to the problem described above... [1] This codepath is only followed if the server_encoding is not compatiable with the chosen client_encoding -- in my case server_encoding = 'en_CA.utf8' reproduces the problem.) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Is Optimizer smart enough?
[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 detect index fragmentation and discard it? IIRC, btcostestimate is sensitive to the physical size of the index, so it would catch the first-order effect of index bloat. It wouldn't notice index fragmentation in the sense of increasingly random location of logically-sequential leaf pages. But I'm not sure how much that matters for typical situations. If you have a huge fraction of dead tuples, I'd say that index fragmentation is not your worst problem... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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 I think we should honour what it allows, provided it's not blatantly non-standard. It's up to the user to decide whether or not they actually make use of the facility. For most database applications there is no practical reason to be using a time of 24:00:00(at least none I can think of) and Delphi does not allow a timestamp to contain 24 in the hours position. I have reported it to my database component vendor, maybe they will address it, maybe not. Doing a little research I found that some DBs support it (DB2 for example) and others do not. Since I am targeting mostly windows users with my product, I guess for now I will just allow it to be flagged as invalid. Later, -- Tony Caduto AM Software Design Home of PG Lightning Admin for Postgresql http://www.amsoftwaredesign.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs update taking a long time
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 is anonymous cvs (anoncvs.postgresql.org). Should be fixed ... there were a whack of stale/old processes running, restarted the vServer and machien is feeling more responsive now ... let me know if you see it again... (or are still!) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] cvs update taking a long time
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.org). -- Michael Fuhr ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] cvs update taking a long time
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 ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Is Optimizer smart enough?
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 discard it? Is there something that I could do in btcostesimate function to detect increasing index fragmentation? best regards, Eduardo Morelli ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Improving N-Distinct estimation by ANALYZE
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 Reading 2% (2560/128000 blocks 1048576000 bytes) total time 13397833us MB/s 1.57 effective MB/s 78.26 Reading 3% (3840/128000 blocks 1048576000 bytes) total time 16288218us MB/s 1.93 effective MB/s 64.38 Reading 4% (5120/128000 blocks 1048576000 bytes) total time 17998334us MB/s 2.33 effective MB/s 58.26 Reading 5% (6400/128000 blocks 1048576000 bytes) total time 22958791us MB/s 2.28 effective MB/s 45.67 Reading 6% (7680/128000 blocks 1048576000 bytes) total time 21272511us MB/s 2.96 effective MB/s 49.29 Reading 7% (8960/128000 blocks 1048576000 bytes) total time 21708130us MB/s 3.38 effective MB/s 48.30 Reading 8% (10240/128000 blocks 1048576000 bytes) total time 23213377us MB/s 3.61 effective MB/s 45.17 Reading 9% (11520/128000 blocks 1048576000 bytes) total time 33641027us MB/s 2.81 effective MB/s 31.17 Reading 10% (12800/128000 blocks 1048576000 bytes) total time 22484234us MB/s 4.66 effective MB/s 46.64 Reading 15% (19200/128000 blocks 1048576000 bytes) total time 23985072us MB/s 6.56 effective MB/s 43.72 Reading 20% (25600/128000 blocks 1048576000 bytes) total time 26332888us MB/s 7.96 effective MB/s 39.82 -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] A question about index internals
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 implement something that could change the index page filling. I've > found a struct called IndexOptInfo. Do I have to change it? Also, I followed > the creation index path and I reached a fuction called "heap_create". Am I in > a > right way, or completely lost? > > Best regards > > Eduardo Morelli > lost... at least in the list you select to post ;) redirecting to pgsql-hackers@postgresql.org -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Improving N-Distinct estimation by ANALYZE
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 triggering it. > > Nah, Linux 2.6 uses flexible readahead logic. It increases slowly when > you read sequentially, but halves the readahead if you do another access > type. Can't see that would give an average readahead size of 32k. I've actually read this code at one point in the past. IIRC the readahead is capped at 32k, which I find interesting given the results. Since this is testing sequential access patterns perhaps what's happening is the test for readahead is too liberal. All the numbers I'm getting are consistent with a 32k readahead. Even I run my program with a 4k block size I get performance equivalent to a full table scan very quickly. If I use a 32k block size then the breakeven point is just over 20%. I suppose what I really ought to do is make some pretty graphs. -- greg ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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 with that, either. IIRC the argument that carried the day involved roundoff behavior. In 8.0 and before you can do this: regression=# select '23:59:59.99'::time(0); time -- 24:00:00 (1 row) If you disallow 24:00:00 then there are legal values of time(n) that will fail to round off to time(0). What's worse, data that was accepted and rounded off by prior releases will fail to reload after a dump. It was a complaint from a user who got burnt by that behavior that got us thinking about it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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 languages (including PHP, I think) use this number to express "midnight". I personally also find it a useful way to distinguish between "blank time" (00:00) an "specifically intentionally midnight" (24:00). -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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-time.html >> >> >> > Hi Dave, > That may be true, but I don't think 24:00:00 is the standard way of > doing it, have you ever seen your PC clock roll over to 24:00:00 > > For a PC/server based bios clock 24:00:00 is not a valid time, a lot of > programming languages datetime routines will not accept a time of 24:00:00. Hi Tony, 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 I think we should honour what it allows, provided it's not blatantly non-standard. It's up to the user to decide whether or not they actually make use of the facility. Just my tuppence worth :-) Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Improving N-Distinct estimation by ANALYZE
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 logic. It increases slowly when you read sequentially, but halves the readahead if you do another access type. Can't see that would give an average readahead size of 32k. Anyway this is one just reason for change... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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:00 would complain about that, too ;-) Well, Richard T. Snodgrass says in "Developing Time-Oriented Database Applications in SQL" (pg. 81) the following: > Most days have 24 hours. The day in April that daylight saving time > kicks in has only 23 hours; the day in October that daylight saving > time ends contains 25 hours. Similarly, minutes can have 62 seconds > (though up to 1999 only one leap second has ever been added to any > particular minute), as mentioned in this standard [44, p. 25]. where ref [44] is > ISO, Database Language SQL. ISO/IEC 9075: 1992. ANSI X3.135-1992 To me this sounds like 23:59:60, doesn't it? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Question about Postgresql time fields(possible bug)
> -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]>,
> 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 incorrect,
> >> PG Lightning Admin catches it as a invalid time, but
> shouldn't there be
> >> some validation of times and dates at the server level?
> >>
> >> There are people who are using PG Admin III and they don't
> even know
> >> they have bogus dates and times in their databases.
>
> > 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'?
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-time.html
--
As every day both starts and ends with midnight, the two notations 00:00
and 24:00 are available to distinguish the two midnights that can be
associated with one date. This means that the following two notations
refer to exactly the same point in time:
1995-02-04 24:00 = 1995-02-05 00:00
--
So:
postgres=# select ('1995-02-04 24:00'::timestamp = '1995-02-05
00:00'::timestamp);
?column?
--
t
(1 row)
Regards, Dave.
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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 decided to allow 24:00:00 for reasons unrelated to leap seconds. See the archives --- this was debated and agreed to not all that long ago. PG 8.0 and before don't allow it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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 incorrect, >> PG Lightning Admin catches it as a invalid time, but shouldn't there be >> some validation of times and dates at the server level? >> >> There are people who are using PG Admin III and they don't even know >> they have bogus dates and times in their databases. > 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'? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] current_setting returns 'unset'
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 unset string parameter should simply display the empty > string. I wouldn't object to that, but my recollection is that that was once the behavior, and somebody insisted it was bad. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Question about Postgresql time fields(possible bug)
> -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 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 validation of times and dates at the server level? > > There are people who are using PG Admin III and they don't even know > they have bogus dates and times in their databases. pgAdmin III leaves all data checks in the hands of the database and doesn't try to second guess what may or may not be valid - constraints and regional settings might easily affect what is or isn't valid or how client data is interpreted by the server. Besides, 24:00:00 is an accepted way of indicating a leap second. http://en.wikipedia.org/wiki/24-hour_notation Regards, Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Question about Postgresql time fields(possible bug)
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 shouldn't there be > some validation of times and dates at the server level? > > There are people who are using PG Admin III and they don't even know > they have bogus dates and times in their databases. A leap second will show as 24:00:00. It is a valid time. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Question about Postgresql time fields(possible bug)
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 validation of times and dates at the server level? There are people who are using PG Admin III and they don't even know they have bogus dates and times in their databases. Thanks, Tony ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] current_setting returns 'unset'
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 does have one in the example at the bottom. so I guess this just arose out of the implementation, or is this intentional? The implementation was based on infrastructure already existing for SHOW, so this is an artifact of that implementation. In the case of a string variable, _ShowOption() returns "unset" when a parameter is not set, and that gets passed all the way back. Joe ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] lookup_rowtype_tupdesc considered harmful
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 the
patch ("RefCountedTupleDesc" vs. a normal "TupleDesc"). I assumed that
there was a need to have two variants of the structure (one refcounted,
one not), but you're right that just adding refcounting to TupleDesc
directly doesn't have a lot of overhead, and avoids the confusion of two
similar-but-not-identical structs. I'll post a patch when it's finished
(hopefully tonight).
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] current_setting returns 'unset'
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 primarily for "showing", I'd expect that that user can apply the visualization tweaks that the frontend provides, for instance \pset in psql, to tell apart null values and empty strings. Not that "unset" is a typical value for string parameters, but you can see where I might go here. 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 unset string parameter should simply display the empty string. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] current_setting returns 'unset'
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. 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. The question thus is do you want the function behaving differently from SHOW. Returning NULL is probably better from a programming point of view, but it'd be inconsistent with the command. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] lookup_rowtype_tupdesc considered harmful
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 "shouldFreeDesc" flag that sort of allows partial, one-way sharing of descs between slots, but it would work a lot better if the descriptors contained reference counts instead. And it might be worth insisting that users of a relation tupledesc from the relcache increment its refcount while they use it --- that would get rid of some rather shaky assumptions about when it's OK to free the tupledesc during relcache updates. I'm thinking it might be worth the cost to just add a refcount field to the standard tupleDesc struct. (We don't need an isdead flag: more elegantly, just include the TypeCacheEntry's own reference to the tupdesc in the refcount.) Add macros IncrTupleDescRefCount and DecrTupleDescRefCount, the latter freeing the struct if the count goes to zero, and voila. I'm not quite sure whether the tupledesc creation routines should initialize the count to zero or to one, but otherwise it all seems pretty clear. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] current_setting returns 'unset'
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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
