[HACKERS] Missing TODO? EXPLAIN vs functions
Could have sworn this was already listed as a TODO, but can't see it on the developer website. IMHO it's something that's needed, especially with differing behaviour due to compiled plans. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] update i386 spinlock for hyperthreading
"Simon Riggs" <[EMAIL PROTECTED]> writes: >>Kenneth Marshall would like me to post this: >> I agree that in order to manage today's large memory machines, we >> need to have less contention in our buffer management strategies. >> The two main main choke points are in the buffer hash table routines >> and in the buffer management linked lists. Unfortunately most of the >> code depends on holding the bufmgr lock on entry which eliminates >> many chances for parallelism. Are you familiar with the work I've been doing recently to try to reduce the contention for the BufMgrLock? For example: http://www.mail-archive.com/pgsql-hackers%40postgresql.org/msg40289.html The approach I've taken is to remove the usage of the BufMgrLock for operations that do not affect the global state of the buffer pool. That means that operations like incrementing a buffer's refcount requires only holding the per-buffer meta data lock. That's only one part of the puzzle, however: other ways to reduce BufMgrLock contention will probably be necessary. Unfortunately this code is not in CVS yet: I've been too busy with school to wrap up the remaining issues it has. However, I hope to get it into the tree reasonably soon, and certainly in time for 7.5. >> The number of buffer pools should at the very minimum be equal to >> the number of processors in the system. [...] Not sure I understand exactly what you're suggesting here. Can you elaborate? >> The next item to address is the buf_table concurrency. It appears >> that the same code that was used in the hash index update by Tom >> Lane could be used to split the buf_table accesses into a >> per-bucket access using a per-bucket lock and not a global >> lock. Modifying the current dyn_hash search and update code would >> make it look effectively like Mr. Lane's new hash index code. Interesting. This would be complementary, of course, to my work on changing the buffer locking scheme: perhaps once that is done, we can reassess the remaining lock contention issues in the bufmgr, and implement this if necessary? Another related idea that Jan Wieck and I had discussed was avoiding acquiring the BufMgrLock at all in BufferAlloc() where possible. For instance, we could enhance the existing PrivateRefCount mechanism, or invent some new mechanism, which would essentially keep a LRU list of buffer tag -> buffer id mappings in each backend's local memory. Then, we would walk this list in BufferAlloc(): if the buffer tag we're looking for is already there, we can immediately acquire the buffer's per-buffer meta data lock (without ever acquiring the BufMgrLock). We'd need to then check that the buffer hasn't changed under our feet (compare the locked buffer's tag with what we think its tag should be, and start over if its different). -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Missing TODO? EXPLAIN vs functions
Richard Huxton <[EMAIL PROTECTED]> writes: > Could have sworn this was already listed as a TODO, but can't see it on the > developer website. IMHO it's something that's needed, especially with > differing behaviour due to compiled plans. See PREPARE and EXPLAIN EXECUTE. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Missing TODO? EXPLAIN vs functions
On Friday 20 February 2004 14:21, Tom Lane wrote: > Richard Huxton <[EMAIL PROTECTED]> writes: > > Could have sworn this was already listed as a TODO, but can't see it on > > the developer website. IMHO it's something that's needed, especially with > > differing behaviour due to compiled plans. > > See PREPARE and EXPLAIN EXECUTE. Yes indeed - knew I'd seen someone mention it months ago. Thanks, Tom -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 3: 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] Renaming tables to other schemas
On Sunday 15 February 2004 07:53, Rod Taylor wrote:
> On Sun, 2004-02-15 at 01:34, Neil Conway wrote:
> > [EMAIL PROTECTED] writes:
> > > The capability to move objects to other schemas would be quite
> > > useful.
> >
> > I agree. It's not utterly-trivial to implement (for one thing, you
> > need to move any dependant objects like indexes to the new schema),
> > but some form of this functionality would be a useful thing to add,
> > IMHO.
>
> It's not that hard to do either (I've done about 100 tables by hand at
> this point).
>
> Anyway, this should be supported by all RENAME commands, not just ALTER
> TABLE.
Rod, can you lay out some psdueo code / logic involved in the process? I'm
guessing you lock the entry in pg_class, you up dependent objects, lock them,
update them all... is there more to it?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Advice regarding configuration parameters
How about, "Allow outside agents to extend the GUC variable set" - thomas - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Thomas Hallgren" <[EMAIL PROTECTED]> Cc: "Joe Conway" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>; "Peter Eisentraut" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 20, 2004 04:39 Subject: Re: [HACKERS] Advice regarding configuration parameters > Thomas Hallgren wrote: > > No, this was not related to triggers at all. The original discussion > > concerned GUC functionality to handle configuration settings for pl > > extensions. > > OK. If you guys agree on TODO wording, I will add it. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Renaming tables to other schemas
> Rod, can you lay out some psdueo code / logic involved in the process? I'm > guessing you lock the entry in pg_class, you up dependent objects, lock them, > update them all... is there more to it? It was one an offline database at the time with only a single user -- so locking wasn't a concern at the time. To change the namespace of a table, update the namespace ID for: pg_class -> of table pg_type -> of table pg_class -> index(es) on table pg_type -> of indexes on table pg_constraint -> all constraints on table pg_depend -> dependencies of above objects on the namespace We didn't have inheritance or the more exotic items, but I seem to recall the views continued to work as expected with no changes. Dump and restore gave us what we expected, and the database functions as expected but that doesn't necessarily mean the above covers all items. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Resend: Domains and function]
plpgsql should be trying to coerce the return value to the functions return
type:
rms=# create or replace function retval(integer) returns text as ' begin
return $1::integer; end; ' language 'plpgsql';
CREATE FUNCTION
rms=# select retval(1) || ' is text';
?column?
---
1 is text
(1 row)
rms=# select retval(1) + 1 ;
ERROR: Unable to identify an operator '+' for types 'text' and 'integer'
You will have to retype this query using an explicit cast
and it should error accordingly if it can not do so:
rms=# create or replace function retval2(text) returns integer as ' begin
return $1; end; ' language 'plpgsql';
CREATE FUNCTION
rms=# select retval2('one');
WARNING: Error occurred while executing PL/pgSQL function retval2
WARNING: while casting return value to function's return type
ERROR: pg_atoi: error in "one": can't parse "one"
so ISTM that your example is certainly a deficiency if not a bug.
hmm..examples above on 7.3, which didnt support check constraints, so this is
potentially different on 7.4.
Robert Treat
On Thursday 05 February 2004 15:46, elein wrote:
> I sent this a while ago to general and then
> hackers and got no response.
>
> The question is whether to qualify the return value
> of a function when it returns a domain with
> a check clause.
>
> I believe it should--otherwise the domain is
> only useful on insert and is not acting
> like a full fledged type. However, I suspect
> that there is no underlying support for
> type checks in the general system.
>
> Elein
>
> - Forwarded message from elein <[EMAIL PROTECTED]> -
>
> I can create a function with a domain and
> define it to return a domain.
>
> The parameter is checked to see if it qualifies
> in the constraint of the domain, however, the
> return value is not.
>
> Is this a bug? Is the author of the function
> responsible for re-inforcing the constraint
> at runtime?
>
> This is the test case in 7.4:
>
> =# create domain one2hundred AS integer
> -#DEFAULT '1' CONSTRAINT email_domain check( VALUE > 0 AND VALUE <=100
> ); CREATE DOMAIN
> =#
> =# create function gb52_add( one2hundred )
> -# returns one2hundred as
> -# '
> '# BEGIN
> '#RETURN $1 + 10;
> '# END;
> '# ' language 'plpgsql';
> CREATE FUNCTION
> =#
> =# select gb52_add( 80);
> gb52_add
> --
>90
> (1 row)
>
> =# select gb52_add( 100);
> gb52_add
> --
> 110
> (1 row)
>
> =# select gb52_add( 90);
> gb52_add
> --
> 100
> (1 row)
>
> =# select gb52_add( 91);
> gb52_add
> --
> 101
> (1 row)
>
> =# select gb52_add( 191);
> ERROR: value for domain one2hundred violates check constraint
> "email_domain"
>
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [HACKERS] [Resend: Domains and function]
Robert Treat <[EMAIL PROTECTED]> writes: > so ISTM that your example is certainly a deficiency if not a bug. I believe it is a bug or at least an unimplemented feature in plpgsql: plpgsql has its own implementation of casting, and is not aware that casting to a domain should involve running check constraints. The same might be true of the other PL languages, not sure. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] [HACKERS] [Resend: Domains and function]
elein <[EMAIL PROTECTED]> writes: > Shouldn't all function calls go (through fast path or fmgr > or the language manager?) to a centralized parameter marshalling? We're talking about what happens inside the function, not how you pass parameters to it. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Advice regarding configuration parameters
Thomas Hallgren wrote: > How about, > > "Allow outside agents to extend the GUC variable set" Added: * Allow external interfaces to extend the GUC variable set --- > > - thomas > > - Original Message - > From: "Bruce Momjian" <[EMAIL PROTECTED]> > To: "Thomas Hallgren" <[EMAIL PROTECTED]> > Cc: "Joe Conway" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>; > "Peter Eisentraut" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, February 20, 2004 04:39 > Subject: Re: [HACKERS] Advice regarding configuration parameters > > > > Thomas Hallgren wrote: > > > No, this was not related to triggers at all. The original discussion > > > concerned GUC functionality to handle configuration settings for > pl > > > extensions. > > > > OK. If you guys agree on TODO wording, I will add it. > > > > -- > > Bruce Momjian| http://candle.pha.pa.us > > [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ExecReScan function
Hello, I am trying to test some of my techniques, and for that i need the nested loop join plan node (NestLoop) not to restart the scan of the inner relation for a change of outer relation correlation value, instead start from the current position where the search ended for the previous scan. Can somebody tell me how i can stop the re scaning of the inner relation for every change in the outer tuple ?? Thanks in adv, -Ramu _ Contact brides & grooms FREE! http://www.shaadi.com/ptnr.php?ptnr=hmltag Only on www.shaadi.com. Register now! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] NO WAIT ...
On Thu, 2004-02-19 at 11:01, Bruce Momjian wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > > The question is whether we should have a GUC variable to control no
> > > > waiting on locks or add NO WAIT to specific SQL commands.
> > > >
> > > > Does anyone want to vote _against_ the GUC idea for nowait locking. (We
> > > > already have two voting for such a variable.)
> > >
> > > I vote against. We got bit by both the regex and the autocommit GUC vars
> > > and this is setting up to cause a similar headache with old code on new
> > > platforms.
> >
> > I vote for the GUC. Imho it is not comparable to the "autocommit" case,
> > since it does not change the way your appl needs to react (appl needs to
> > react to deadlock already).
> >
> > I personally think a wait period in seconds would be more useful.
> > Milli second timeouts tend to be misused with way too low values
> > in this case, imho.
>
> I understand, but GUC lost the vote. I have updated the TODO list to
> indicate this. Tatsuo posted a patch to add NO WAIT to the LOCK
> command, so we will see if we can get that into CVS.
>
Is it premature to add "allow vacuum command to use no wait semantics on
locks" to the TODO list?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[HACKERS] Progress Report on Materialized Views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've implemented a pretty simple Materialized Views scheme. It's not terribly complicated, and it works quite well. This is what I do. 0) Initialize the materialized view environment. This will allow the system to track which tables and views are part of a materialized view, as well as when the last time it was refreshed was. CREATE TABLE matviews ( mv_name NAME NOT NULL , mv_view NAME NOT NULL , last_refresh TIMESTAMP ); 1) Create a view. This will be what the materialized view should keep in sync with. One column must be unique and non-null. This will be the primary key of the materialized view. 2) Create a table -- the materialized view -- from the view. I've wrapped this up into a pl/PgSQL function. Pseudo-code is basically: - Create a table, the materialized view. - Select everything from the corresponding view into the materialized view. - Insert a row into matviews, last_refresh = now(). 3) Create a function called "_refresh_row()". This will: - Delete the row from the materialized view with that primary key - Select the row with that primary key from the view and insert it into the materialized view. 4) If there is any sort of time-dependence, create a function called "_refresh()". This will find all the rows that have changed due to the time-dependence. It uses "last_refresh" from the matviews table, and "now()" to determine the timespan. This function needs to be called periodically. 5) Create triggers on all tables that contribute to the view. - An insert trigger, that will discover the primary key(s) that the inserted row will affect, and refreshes those rows (using the *_refresh_row function) - An update trigger, that will discover all the primary key(s) that the updated row will affect, and refreshes those rows. Note that the primary keys may be different if the column that determines the primary key is changing. - A delete trigger, that will dicover all the primary key(s) that the updated row will affect, and refreshes those rows. The system has been running in a production environment for over a week, with only one problem: deadlock when we were inserting vast amounts of new data. Adding appropriate indexes to the materialized views has reduced the query times for some of our most important queries to 1/300 of the original time. There were some issues with the time-sensitivity of the queries. For instance, our list of members will decrease as time goes along due to the expiration date of accounts. Because we were running the refresh once a day, there were a few hours of the day where the materialized view would say that the person is a member, but the actual data says he is not. We rewrote our code to pull everything from the materialized view, greatly simplifying the code, and also increasing performance. My next step is to write a generic algorithm for handling the tasks mentioned in step s 4 and 5. I've written these by hand so far, because I can tell which columns of the updated/inserted/deleted row determine which rows in the materialized view will be affected. Any help in this area would be greatly appreciated. After that, I would like to investigate whether or not it is possible to register a function to be called when the transaction is committed. That way, the materialized view update can be deferred until the transaction is complete. This would enhance performance. - -- Jonathan Gardner [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFANnqdqp6r/MVGlwwRAveMAJ0TsLyG2w3wlOv+LvtbePvzmkueFwCeJxlX arJKaqFBxGOuXS0L4DJeIwQ= =FGig -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.1 release status - Turkish Locale
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > > I've committed the attached fix, which I believe will solve this > problem. Could you test it? Thank you very much for your effort and attention! I am not sure I am testing the right version. I am testing the one with REL7_4_STABLE, the one with downcase_truncate_identifier() function added. Under locale-ignorant FreeBSD it works fine. But under Fedora Core 1 initdb it crashes under all locales I tested -C, en_US, tr_TR with message given below. I remember seeing this message before, when I messed up with downcasting Functions. See, it is downcasting "ISO" and gets "ıso" in return. Could Someone confirm the results I got? Regards, Nicolai fixing permissions on existing directory /pgdata... ok creating directory /pgdata/base... ok creating directory /pgdata/global... ok creating directory /pgdata/pg_xlog... ok creating directory /pgdata/pg_clog... ok selecting default max_connections... 10 selecting default shared_buffers... 50 creating configuration files... ok creating template1 database in /pgdata/base/1... FATAL: XX000: failed to initialize DateStyle to "ISO, MDY" LOCATION: InitializeGUCOptions, guc.c:1866 initdb: failed ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [HACKERS] [Resend: Domains and function]
Right. Sorry. My brain was over on parameter issues and I did not reread my original bug... On Fri, Feb 20, 2004 at 01:03:08PM -0500, Tom Lane wrote: > elein <[EMAIL PROTECTED]> writes: > > Shouldn't all function calls go (through fast path or fmgr > > or the language manager?) to a centralized parameter marshalling? > > We're talking about what happens inside the function, not how you pass > parameters to it. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [HACKERS] [Resend: Domains and function]
The reason it is a bug rather than an unimplemented feature is that it pokes a hole in the effectiveness of domains. What good is a domain if it cannot be enforced everywhere you use it? That is like having a hole in referential integrity. (Though I admit not many people will run into this until more people use domains.) Shouldn't all function calls go (through fast path or fmgr or the language manager?) to a centralized parameter marshalling? They should. The informix reimplementation of postgres was very firm about this. It ensured parameter coersion consistency across all languages. Centralizing the parameter marshalling will make it so much easier to implement things like domains and arrays in various languages consistently and across the board. Once the coersion it properly done in SQL, then each language can decide the natural form for the standard data types or punt to text. elein On Fri, Feb 20, 2004 at 11:33:39AM -0500, Tom Lane wrote: > Robert Treat <[EMAIL PROTECTED]> writes: > > so ISTM that your example is certainly a deficiency if not a bug. > > I believe it is a bug or at least an unimplemented feature in plpgsql: > plpgsql has its own implementation of casting, and is not aware that > casting to a domain should involve running check constraints. > > The same might be true of the other PL languages, not sure. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Mac OS X, PostgreSQL, PL/Tcl
Hoping someone can help me figure out why I can't get PL/Tcl to load without crashing the backend on Mac OS 10.3.2. I compile Tcl, PostgreSQL, create the database and then run the following: create function plpgsql_call_handler() RETURNS LANGUAGE_HANDLER as 'plpgsql.so' language 'c'; create trusted procedural language 'plpgsql' HANDLER plpgsql_call_handler LANCOMPILER 'PL/pgSQL'; create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER as 'pltcl.so' language 'c'; create trusted procedural language 'pltcl' HANDLER pltcl_call_handler LANCOMPILER 'PL/Tcl'; The PL/pgSQL part loads fine. The PL/Tcl part crashes the server, and psql reports this: psql:/Users/scott/pgtest/add_languages.sql:12: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:/Users/scott/pgtest/add_languages.sql:12: connection to server was lost I have tried the exact same procedure on Linux without any problems using the exact same scripts, setup etc. I've tried both PG 7.4.1 and a CVS copy from 11 Feb. I've used gcc 3.3, 3.1 and 2.85. I've tried loading PL/Tcl without loading PL/pgSQL at all, same problem. I tried Tcl 8.4.3, 8.4.4 and 8.4.5. pgtclsh runs fine. I used ktrace to attach to the PG process and it's generating a SIGSEGV. I get several "file name too long" errors before the SEGV. Problem is probably not with PG, but could be with Tcl and/or Mac OS X loadable libs. Here's the significant portion of it (you can find the whole output trace at http://scottg.net/pgktrace.txt): ... stuff prior ... 27296 postgres 0.21 NAMI "/usr/lib/libicucore.A.dylib" 27296 postgres 0.19 RET open 114/0x72 27296 postgres 0.09 CALL fstat(0x72,0xbfffdf50) 27296 postgres 0.09 RET fstat 0 27296 postgres 0.47 CALL load_shared_file(0x9019060c,0x605000,0x13b680,0xbfffdd60,0x4,0xbfffdcf0, 0xbfffdd64) 27296 postgres 0.53 NAMI "/usr/lib/libicucore.A.dylib" 27296 postgres 0.000135 RET load_shared_file 0 27296 postgres 0.34 CALL close(0x72) 27296 postgres 0.15 RET close 0 27296 postgres 0.000113 CALL stat(0x800200,0xbfffde20) 27296 postgres 0.16 NAMI " /libSystem.B.dylib" 27296 postgres 0.23 RET stat -1 errno 2 No such file or directory 27296 postgres 0.21 CALL stat(0x800200,0xbfffde20) 27296 postgres 0.09 NAMI " /libSystem.B.dylib" 27296 postgres 0.17 RET stat -1 errno 2 No such file or directory 27296 postgres 0.004552 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.44 RET stat -1 errno 63 File name too long 27296 postgres 0.19 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.08 RET stat -1 errno 63 File name too long 27296 postgres 0.12 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.08 RET stat -1 errno 63 File name too long 27296 postgres 0.13 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.08 RET stat -1 errno 63 File name too long 27296 postgres 0.13 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.08 RET stat -1 errno 63 File name too long 27296 postgres 0.13 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.08 RET stat -1 errno 63 File name too long 27296 postgres 0.13 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.08 RET stat -1 errno 63 File name too long 27296 postgres 0.13 CALL stat(0x182ea00,0xbfffd430) 27296 postgres 0.09 RET stat -1 errno 63 File name too long 27296 postgres 0.13 CALL stat(0x90104e34,0xbfffd3b0) 27296 postgres 0.000118 NAMI "/" 27296 postgres 0.19 RET stat 0 27296 postgres 0.12 CALL lstat(0x182f600,0xbfffd3b0) 27296 postgres 0.07 NAMI "." 27296 postgres 0.16 RET lstat 0 27296 postgres 0.09 CALL stat(0x182f600,0xbfffd1a0) 27296 postgres 0.06 NAMI ".." 27296 postgres 0.
Re: [HACKERS] 7.4.1 release status - Turkish Locale
"Nicolai Tufar" <[EMAIL PROTECTED]> writes:
> Under locale-ignorant FreeBSD it works fine.
> But under Fedora Core 1 initdb it crashes under all
> locales I tested -C, en_US, tr_TR with message given below.
Hmm. It seems that tr_TR has problems much more extensive than you've
indicated previously. I was able to get through initdb with the attached
additional patch, but the regression tests fail in several places.
It looks to me like every use of strcasecmp in the backend has to be
questioned if we're going to make this work. I'm starting to lean in
the direction of "tr_TR is hopelessly broken" again...
regards, tom lane
*** src/backend/commands/variable.c~Mon Jan 19 14:04:40 2004
--- src/backend/commands/variable.c Fri Feb 20 23:16:16 2004
***
*** 82,103
/* Ugh. Somebody ought to write a table driven version -- mjl */
! if (strcasecmp(tok, "ISO") == 0)
{
newDateStyle = USE_ISO_DATES;
scnt++;
}
! else if (strcasecmp(tok, "SQL") == 0)
{
newDateStyle = USE_SQL_DATES;
scnt++;
}
! else if (strncasecmp(tok, "POSTGRES", 8) == 0)
{
newDateStyle = USE_POSTGRES_DATES;
scnt++;
}
! else if (strcasecmp(tok, "GERMAN") == 0)
{
newDateStyle = USE_GERMAN_DATES;
scnt++;
--- 82,108
/* Ugh. Somebody ought to write a table driven version -- mjl */
! /*
!* Note: SplitIdentifierString already downcased the input, so
!* we needn't use strcasecmp here.
!*/
!
! if (strcmp(tok, "iso") == 0)
{
newDateStyle = USE_ISO_DATES;
scnt++;
}
! else if (strcmp(tok, "sql") == 0)
{
newDateStyle = USE_SQL_DATES;
scnt++;
}
! else if (strncmp(tok, "postgres", 8) == 0)
{
newDateStyle = USE_POSTGRES_DATES;
scnt++;
}
! else if (strcmp(tok, "german") == 0)
{
newDateStyle = USE_GERMAN_DATES;
scnt++;
***
*** 105,129
if (ocnt == 0)
newDateOrder = DATEORDER_DMY;
}
! else if (strcasecmp(tok, "YMD") == 0)
{
newDateOrder = DATEORDER_YMD;
ocnt++;
}
! else if (strcasecmp(tok, "DMY") == 0 ||
!strncasecmp(tok, "EURO", 4) == 0)
{
newDateOrder = DATEORDER_DMY;
ocnt++;
}
! else if (strcasecmp(tok, "MDY") == 0 ||
!strcasecmp(tok, "US") == 0 ||
!strncasecmp(tok, "NONEURO", 7) == 0)
{
newDateOrder = DATEORDER_MDY;
ocnt++;
}
! else if (strcasecmp(tok, "DEFAULT") == 0)
{
/*
* Easiest way to get the current DEFAULT state is to fetch
--- 110,134
if (ocnt == 0)
newDateOrder = DATEORDER_DMY;
}
! else if (strcmp(tok, "ymd") == 0)
{
newDateOrder = DATEORDER_YMD;
ocnt++;
}
! else if (strcmp(tok, "dmy") == 0 ||
!strncmp(tok, "euro", 4) == 0)
{
newDateOrder = DATEORDER_DMY;
ocnt++;
}
! else if (strcmp(tok, "mdy") == 0 ||
!strcmp(tok, "us") == 0 ||
!strncmp(tok, "noneuro", 7) == 0)
{
newDateOrder = DATEORDER_MDY;
ocnt++;
}
! else if (strcmp(tok, "default") == 0)
{
/*
* Easiest way to get the current DEFAULT state is to fetch
***
*** 474,480
HasCTZSet = true;
}
}
! else if (strcasecmp(value, "UNKNOWN") == 0)
{
/*
* UNKNOWN is the value shown as the "default" for TimeZone in
--- 479,485 -
[HACKERS] Too-many-files errors on OS X
I've looked into Olivier Hubaut's recent reports of 'Too many open files' errors on OS X. What I find is that on Darwin, where we are using Posix semaphores rather than SysV semaphores, each Posix semaphore is treated as an open file --- it shows up in "lsof" output, and more to the point it appears to count against a process's ulimit -n limit. This means that if you are running with, say, max-connections = 100, that's 100+ open files in the postmaster and every active backend. And it's 100+ open files that aren't accounted for in fd.c's estimate of how many files it can open. Since the ulimit -n setting is by default only 256 on this platform, it doesn't take much at all for us to be bumping up against the ulimit -n limit. fd.c copes fine, since it automatically closes other open files any time it gets an EMFILE error. But code outside fd.c is likely to fail hard ... which is exactly the symptom we saw in Olivier's report. I plan to apply some band-aid fixes to make that code more robust; for instance we can push all calls to opendir() into fd.c so that EMFILE can be handled by closing other open files. (And why does MoveOfflineLogs PANIC on this anyway? It's not critical code...) However, it seems that the real problem here is that we are so far off base about how many files we can open. I wonder whether we should stop relying on sysconf() and instead try to make some direct probe of the number of files we can open. I'm imagining repeatedly open() until failure at some point during postmaster startup, and then save that result as the number-of-openable-files limit. I also notice that OS X 10.3 seems to have working SysV semaphore support. I am tempted to change template/darwin to use SysV where available, instead of Posix semaphores. I wonder whether inheriting 100-or-so open file descriptors every time we launch a backend isn't in itself a nasty performance hit, quite aside from its effect on how many normal files we can open. Comments anyone? There are a lot of unknowns here... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Mac OS X, PostgreSQL, PL/Tcl
Scott Goodwin <[EMAIL PROTECTED]> writes: > Hoping someone can help me figure out why I can't get PL/Tcl to load > without crashing the backend on Mac OS 10.3.2. FWIW, pltcl seems to work for me. Using up-to-date Darwin 10.3.2 and PG CVS tip, I did configure --with-tcl --without-tk then make, make install, etc. pltcl installs and passes its regression test. > psql:/Users/scott/pgtest/add_languages.sql:12: server closed the > connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. Can you provide a stack trace for this? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
