[HACKERS] [GENERAL] Off-topic: usenet sources?
Reliable rumor has it that Deja.com (formerly Dejanews) is going out of business, possibly as early as this week, and pulling the plug completely (I worked there '97-'99). They've already laid off all but a small handful of the peak of ~125 employees. That was the premier source for technical archives, IMO. What a loss. Question: What's the next best site/tool for searching technical usenet archives?? Regards, Ed Loehr
Re: [HACKERS] Auto-indexing
> Probably both, but if it's done there should be options to: > > .) disable it completely or by table/database or even threshold or >disk free parameters (indicies can be large) > .) log any auto-created databases to inform the DBA. > .) if disabled optionally log when it would have created an index on >the fly. (suggest an index) > .) expire old and unused auto-created indecies. > > Generally Postgresql assumes the user knows what he's doing, but > it couldn't hurt too much to provide an option to have it assist > the user. I want to implement a SET PERFORMANCE_TIPS, hopefully for 7.2: * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER I think suggesting items to the adminstrator is the way to go. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Auto-indexing
* Christopher Kings-Lynne <[EMAIL PROTECTED]> [010206 18:29] wrote: > Is it a feasible idea that PostgreSQL could detect when an index would be > handy, and create it itself, or at least log that a table is being queried > but the indices are not appropriate? > > I suggest this as it's a feature of most windows databases, and MySQL does > it. I think it would be a great timesaver as we have hundreds of different > queries, and it's a real pain to have to EXPLAIN them all, etc. Is that > possible? Feasible? Probably both, but if it's done there should be options to: .) disable it completely or by table/database or even threshold or disk free parameters (indicies can be large) .) log any auto-created databases to inform the DBA. .) if disabled optionally log when it would have created an index on the fly. (suggest an index) .) expire old and unused auto-created indecies. Generally Postgresql assumes the user knows what he's doing, but it couldn't hurt too much to provide an option to have it assist the user. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
[HACKERS] Auto-indexing
Is it a feasible idea that PostgreSQL could detect when an index would be handy, and create it itself, or at least log that a table is being queried but the indices are not appropriate? I suggest this as it's a feature of most windows databases, and MySQL does it. I think it would be a great timesaver as we have hundreds of different queries, and it's a real pain to have to EXPLAIN them all, etc. Is that possible? Feasible? Chris -- Christopher Kings-Lynne Family Health Network (ACN 089 639 243)
Re: [HACKERS] Re: [BUGS] syslog logging setup broken?
> The man page suggests that nohup is required to init postmaster, I > know this isn't true but to implement an example init file and not > match up with the man page seemed foolish. > > I guess nohup would stop postmaster doing something awfull if it > doesn't handle HUP properly but I very much doubt that you guys fail > to handle HUP. Good point. postmaster in 7.1 uses HUP signal to re-read postgresql.conf. It seems we should not use nohup to start postmaster. -- Tatsuo Ishii
Re: [HACKERS] Include files for SPI are not installed
Lamar Owen <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> What would make more sense is for the standard install to install only >> those headers needed for *client side* programming, and then to have >> an optional install target that installs the whole darn src/include >> tree. > I can go for that. >> (Or in RPM terms, a client-devel RPM and a separate server-devel >> RPM that adds the rest of src/include.) Anything in between is >> guaranteed to be the wrong set of files. > Ok, RPM users who do SPI work, sound off. Which would you like? I'll > admit to liking the idea Tom has put forward, but I want more feedback. > I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to > throw out a tentative name. I am loath to split the existing -devel > subpackage into two packages with different names, throwing out the > original, but I can do that as well, if that is the consensus. client-devel and server-devel are the right division IMHO. SPI is a subset of server-side development, but not all server-side code needs SPI. Consider user-written functions and datatypes. These guys do not need SPI (usually), but they do need access to header files that aren't installed now. > The contents of -devel would be the headers installed by 'make install' > -- although I question why spi.h and some friends are installed in the > first place, given the 'client-side' focus (but this _is_ what Tom just > said -- I'm just being a little more specific). My thought was that we'd remove spi.h from the minimal install, along with anything else that's not useful for client-side programming. Thus the standard install footprint would get smaller. I haven't looked to see exactly what the list of client-side headers should be, but if people like this idea I will do the legwork to make the list. regards, tom lane
Re: [HACKERS] Duplicate OIDs in pg_attribute
> Good catch, Joe! This bug has probably been there since the beginning > of time. It's evidently got no serious consequences (since in reality, > OID uniqueness is not assumed for this table), but it ought to be fixed. > A quick-hack solution would be to zero out the tuple's OID before each > heap_insert, but really AppendAttributeTuples should be rewritten to > construct each tuple independently in the first place. > > A quick 'glimpse' shows no other uses of heap_modifytuple except to > update an existing tuple, so evidently no one was foolish enough to > copy this technique. > > I recommend putting this on the TODO for 7.2. We can't fix it now > unless we want to force an initdb. Added to TODO: * Prevent pg_attribute from having duplicate oids for indexes -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] OID from insert has extra letter
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes: > Seems it's a non-portable behavior: Not at all. The code is asking strncpy to copy n bytes, where n is known to be <= strlen of the source string. Every spec-conforming implementation of strncpy will copy n bytes, no more, no less, and will *not* add a trailing null after them. The only reason the code appeared to work is that it was dealing with a static buffer that starts out all zeroes, so the trailing null was already in place. Until the buffer had been used for a longer OID, that is. regards, tom lane
Re: [HACKERS] Include files for SPI are not installed
> I agree with Karel on this --- it's difficult to visualize doing useful > SPI work without a source tree at hand, and it also seems unlikely that > SPI authors would get along for long with *only* those header files > needed to pull in spi.h. So I think it's pretty pointless to add just > those header files. > > What would make more sense is for the standard install to install only > those headers needed for *client side* programming, and then to have > an optional install target that installs the whole darn src/include > tree. (Or in RPM terms, a client-devel RPM and a separate server-devel > RPM that adds the rest of src/include.) Anything in between is > guaranteed to be the wrong set of files. Agreed. I hesitate to copy all those *.h files when few people use them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Duplicate OIDs in pg_attribute
Joe Mitchell <[EMAIL PROTECTED]> writes: > I noticed that pg_attribute has rows with the same OID! Joe previously asked me about this off-list, and I replied thus: This appears to be due to the incredibly grotty coding used in AppendAttributeTuples in src/backend/catalog/index.c --- rather than building tuples in any of several sane fashions, it's using an unholy combination of memmove and heap_modifytuple to update a single tuple object into successive states that correspond to the rows it needs to add to the table. Unfortunately the OID assigned by the first heap_insert gets carried along to the subsequent states, so the later calls to heap_insert don't think they should assign new OIDs. Good catch, Joe! This bug has probably been there since the beginning of time. It's evidently got no serious consequences (since in reality, OID uniqueness is not assumed for this table), but it ought to be fixed. A quick-hack solution would be to zero out the tuple's OID before each heap_insert, but really AppendAttributeTuples should be rewritten to construct each tuple independently in the first place. A quick 'glimpse' shows no other uses of heap_modifytuple except to update an existing tuple, so evidently no one was foolish enough to copy this technique. I recommend putting this on the TODO for 7.2. We can't fix it now unless we want to force an initdb. regards, tom lane
Re: [HACKERS] Re: [SQL] PL/PGSQL function with parameters
Florent Guillaume <[EMAIL PROTECTED]> writes:
> On this same subject, the plpgsql doc says to use
> SELECT expression INTO var FROM ...
> but Bruce's book, in several examples ("PL/PGSQL Functions" for instance,
> node203.html) uses
> SELECT INTO var expression FROM ...
> Both should work, but there may be there's something to straighten up here.
IIRC, the plpgsql code is actually *very* lax about where you put the
INTO; it'll suck it out from almost anyplace in the query string ...
regards, tom lane
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 06:17:46PM -0600, Ross J. Reedstrom wrote: > > Seems it's a non-portable behavior: > > The strncpy() function is similar, except that not more >than n bytes of src are copied. Thus, if there is no null >byte among the first n bytes of src, the result wil not be >null-terminated. > >In the case where the length of src is less than that of >n, the remainder of dest will be padded with nulls. > > I've already forgotten what platform the original bug report came from. Just checked, D'Arcy never told us. But it doesn't matter, the manpage lies. I just tested it with a tiny little program that copies two different constant strings into a buffer. Nothing get's padded with nulls, as Tom knew. Once again, experience trumps book knowledge. (Checking a couple random examples from my own code, I seem to have lucked out: I've a habit of zeroing my buffers myself) Ross
Re: [HACKERS] Include files for SPI are not installed
Tom Lane wrote: > I agree with Karel on this --- it's difficult to visualize doing useful > SPI work without a source tree at hand, and it also seems unlikely that > SPI authors would get along for long with *only* those header files > needed to pull in spi.h. So I think it's pretty pointless to add just > those header files. I'm waiting to see what Mike Mascari says about the issue, as he is doing SPI work from an RPM install (no source) and was the gadfly (in the best sense of the word) that got me putting the SPI headers in in the first place. Besides headers, what files are required? Makefile.global? Makefile.shlib? ??? > What would make more sense is for the standard install to install only > those headers needed for *client side* programming, and then to have > an optional install target that installs the whole darn src/include > tree. I can go for that. > (Or in RPM terms, a client-devel RPM and a separate server-devel > RPM that adds the rest of src/include.) Anything in between is > guaranteed to be the wrong set of files. Ok, RPM users who do SPI work, sound off. Which would you like? I'll admit to liking the idea Tom has put forward, but I want more feedback. I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to throw out a tentative name. I am loath to split the existing -devel subpackage into two packages with different names, throwing out the original, but I can do that as well, if that is the consensus. The contents of -devel would be the headers installed by 'make install' -- although I question why spi.h and some friends are installed in the first place, given the 'client-side' focus (but this _is_ what Tom just said -- I'm just being a little more specific). The contents of -devel-spi (or maybe just -spi) would be all the other headers (no duplicates) (again, expounding upon what Tom said already). Comments? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
Lamar Owen <[EMAIL PROTECTED]> writes: > Karel Zak wrote: >> I expect header files on /usr/include/pgsql for client programming not >> for SPI. > Why? I know of several people doing SPI work with no source tree > installed. I agree with Karel on this --- it's difficult to visualize doing useful SPI work without a source tree at hand, and it also seems unlikely that SPI authors would get along for long with *only* those header files needed to pull in spi.h. So I think it's pretty pointless to add just those header files. What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. regards, tom lane
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 07:08:20PM -0500, Tom Lane wrote: > [EMAIL PROTECTED] (Nathan Myers) writes: > > Thus, the original code is OK, except probably the literal "23" > > in place of what should be a meaningful symbolic constant, or > > (at least!) sizeof(buf) - 1. > > No, the original code is NOT ok. Read the man page again. As the > code stood, the only null that ever got written to the buffer was the > one installed in buf[23]. The only reason it appeared to work at all > was that buf would start out all zeroes --- but after one or more uses > it's not all zeroes anymore. See the bug report that started the > thread ... Seems it's a non-portable behavior: The strncpy() function is similar, except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. In the case where the length of src is less than that of n, the remainder of dest will be padded with nulls. I've already forgotten what platform the original bug report came from. Ross
Re: [HACKERS] OID from insert has extra letter
[EMAIL PROTECTED] (Nathan Myers) writes: > Thus, the original code is OK, except probably the literal "23" > in place of what should be a meaningful symbolic constant, or > (at least!) sizeof(buf) - 1. No, the original code is NOT ok. Read the man page again. As the code stood, the only null that ever got written to the buffer was the one installed in buf[23]. The only reason it appeared to work at all was that buf would start out all zeroes --- but after one or more uses it's not all zeroes anymore. See the bug report that started the thread ... > BTW, that static buffer in PGoidStatus is likely to upset threaded > client code... Yeah, we know. The routine is deprecated now because of that. regards, tom lane
[HACKERS] a contrib function to query current locale values
Hi,
I've written a small function that should go into contrib for 7.1
As locale issues are quite tricky, being able to find out what locale
backend thinks it is in is a good thing ;)
from my README.getlocale:
getlocale('category')
-
return the locale setting of the backend
(see '> man setlocale for definitions)
If category is one of LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY,
LC_NUMERIC, LC_TIME the corresponding setting is returned.
[hannu@taru contrib]$ psql -c "select getlocale('LC_COLLATE')"
getlocale
---
en_US
(1 row)
for LC_ALL (and anything else) a string like the following is returned
[hannu@taru getlocale]$ psql -c "select getlocale('*')"
getlocale
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=C
(1 row)
IMHO some form of it should end up in the main distribution, probably by
7.2.
-
Hannu Krosing <[EMAIL PROTECTED]>
getlocale.tar.gz
Re: [HACKERS] psql: why not pset PROMPT[0-2] ?
Because pset sets parameters of the table output. Prompts have nothing to do with table output. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] psql: why not pset PROMPT[0-2] ?
(In psql:)
I need to modify the 2nd prompt. So i looked at the sources:
I leave the validity test (of the name of the option/param) to SetVariable !!
Here is the patch:
diff -c /internet/cvs/pgsql/src/bin/psql/command.c.~1~
/internet/cvs/pgsql/src/bin/psql/command.c
*** /internet/cvs/pgsql/src/bin/psql/command.c.~1~ Tue Feb 6 22:26:00 2001
--- /internet/cvs/pgsql/src/bin/psql/command.c Tue Feb 6 22:26:00 2001
***
*** 1745,1750
--- 1745,1760
}
+
+ /* toggle use of pager */
+ else if (strncmp(param, "PROMPT",6) == 0)
+ {
+ SetVariable(pset.vars, param, value); /* SetVariable takes care of whether
+param is actually valid !! */
+ }
+
+
+
+
else
{
psql_error("\\pset: unknown option: %s\n", param);
diff -c /internet/cvs/pgsql/src/bin/psql/tab-complete.c.~2~
/internet/cvs/pgsql/src/bin/psql/tab-complete.c
*** /internet/cvs/pgsql/src/bin/psql/tab-complete.c.~2~ Tue Feb 6 22:24:06 2001
--- /internet/cvs/pgsql/src/bin/psql/tab-complete.c Tue Feb 6 22:24:06 2001
***
*** 706,713
else if (strcmp(prev_wd, "\\pset") == 0)
{
char *my_list[] = {"format", "border", "expanded", "null",
"fieldsep",
! "tuples_only", "title", "tableattr", "pager",
! "recordsep", NULL};
COMPLETE_WITH_LIST(my_list);
}
--- 706,713
else if (strcmp(prev_wd, "\\pset") == 0)
{
char *my_list[] = {"format", "border", "expanded", "null",
"fieldsep",
!"tuples_only", "title", "tableattr", "pager",
!"PROMPT1","PROMPT2","PROMPT3","recordsep",
NULL};
COMPLETE_WITH_LIST(my_list);
}
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....
> > > > su - postgres sh -c "$DAEMON stop >& /dev/null" > > > > > > Hmm... What is wrong here, besides the '>&'? The '>&' can be > > > replaced with '2>&1 >' if that is more standard. > > It won't do what you want. You want '>/dev/null 2>&1'. Yes, I knew he wanted >/dev/null 2>&1. I just fixed it. > > > Change made. > > Hmmm, I don't see this change in cvsweb. Thanks. Seems I overwrote it with his new version. Done now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: [SQL] PL/PGSQL function with parameters
> > SQL = ''SELECT * INTO temp1 FROM '' || $1;
>
> I tried this, and it seems that "SELECT ... INTO foo" is not executed
> correctly by EXECUTE --- the INTO is handled as an ordinary select-into-
> table construct rather than plpgsql's select-into-variable.
>
> While I have not looked closely, I seem to recall that plpgsql handles
> INTO by stripping that clause out of the statement before it's passed to
> the SQL engine. Evidently that's not happening in the EXECUTE case.
>From gram.y, yes it tries to strip the INTO by skipping over some stuff,
maybe the "*" trips it ?
Anyway the syntax SELECT INTO temp1 * FROM should work.
On this same subject, the plpgsql doc says to use
SELECT expression INTO var FROM ...
but Bruce's book, in several examples ("PL/PGSQL Functions" for instance,
node203.html) uses
SELECT INTO var expression FROM ...
Both should work, but there may be there's something to straighten up here.
Cheers,
Florent
--
[EMAIL PROTECTED]
[HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....
> > > su - postgres sh -c "$DAEMON stop >& /dev/null" > > > > Hmm... What is wrong here, besides the '>&'? The '>&' can be > > replaced with '2>&1 >' if that is more standard. It won't do what you want. You want '>/dev/null 2>&1'. > Change made. Hmmm, I don't see this change in cvsweb. Florent -- [EMAIL PROTECTED]
[HACKERS] Duplicate OIDs in pg_attribute
I noticed that pg_attribute has rows with the same OID! You can verify this by running. # select count(oid),oid from pg_attribute group by oid having count(oid) > 1; We see that these duplicate OIDs appear to happen when pg_attibute rows are inserted for indexes and primary keys. select relname, attname from pg_attribute , pg_class where attrelid = pg_class.oid and pg_attribute.oid in (select oid from pg_attribute group by oid having count(oid) > 1); I see: relname | attname -+-- pg_aggregate_name_type_index | aggname pg_aggregate_name_type_index | aggbasetype pg_amop_opid_index | amopclaid pg_amop_opid_index | amopopr pg_amop_opid_index | amopid pg_amop_strategy_index | amopid pg_amop_strategy_index | amopclaid pg_amop_strategy_index | amopstrategy pg_attribute_relid_attnam_index | attrelid pg_attribute_relid_attnam_index | attname pg_attribute_relid_attnum_index | attrelid pg_attribute_relid_attnum_index | attnum pg_inherits_relid_seqno_index | inhrelid pg_inherits_relid_seqno_index | inhseqno pg_largeobject_loid_pn_index | loid pg_largeobject_loid_pn_index | pageno pg_listener_pid_relname_index | listenerpid pg_listener_pid_relname_index | relname pg_operator_oprname_l_r_k_index | oprname pg_operator_oprname_l_r_k_index | oprleft pg_operator_oprname_l_r_k_index | oprright pg_operator_oprname_l_r_k_index | oprkind pg_proc_proname_narg_type_index | proname pg_proc_proname_narg_type_index | pronargs pg_proc_proname_narg_type_index | proargtypes pg_statistic_relid_att_index | starelid pg_statistic_relid_att_index | staattnum primarytest2_pkey | col1 primarytest2_pkey | col2 (29 rows) What do people think about this issue? It doesn't seem to have major consequences now, but it should probably be fixed? When system tables have referential integrity enforced, then it will be an issue. Can this be put on the TODO list? Regards, Joe Mitchell Great Bridge LLC
Re: [HACKERS] Include files for SPI are not installed
On Tue, 6 Feb 2001, Lamar Owen wrote: > Karel Zak wrote: > > On Tue, 6 Feb 2001, Oliver Elphick wrote: > > > Certain include files are installed by src/include/Makefile and by > > > interfaces/libpq++/Makefile. However, they in turn include others that > > > are not installed, thus obviating the usefulness of the ones that are. > > > In your module you can use arbitrary routines from PG not only SPI, > > for example you trigger needs work with some datetypes and for this > > needs include anything from include/utils/ ... It expect install *all* > > header files. Not is better download PG sources and use -I option for > > your gcc? > > No. Full tree takes at minimum 36MB -- even pulling the _entire_ > src/include tree over is only 2MB. Agree, *all* in src/include is good idea, but current /usr/include is away from this. Oliver's idea was include needful SPI stuff only. Before 1.5 years I wrote first trigger for PG and first thing I found that /usr/include is not usable for me. > > I expect header files on /usr/include/pgsql for client programming not > > for SPI. > > Why? I know of several people doing SPI work with no source tree > installed. Hmm, it must be very limited outlook without source tree:-) Karel
Re: [HACKERS] Include files for SPI are not installed
Karel Zak wrote: > On Tue, 6 Feb 2001, Oliver Elphick wrote: > > Certain include files are installed by src/include/Makefile and by > > interfaces/libpq++/Makefile. However, they in turn include others that > > are not installed, thus obviating the usefulness of the ones that are. > In your module you can use arbitrary routines from PG not only SPI, > for example you trigger needs work with some datetypes and for this > needs include anything from include/utils/ ... It expect install *all* > header files. Not is better download PG sources and use -I option for > your gcc? No. Full tree takes at minimum 36MB -- even pulling the _entire_ src/include tree over is only 2MB. > I expect header files on /usr/include/pgsql for client programming not > for SPI. Why? I know of several people doing SPI work with no source tree installed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
Oliver Elphick wrote: > Certain include files are installed by src/include/Makefile and by > interfaces/libpq++/Makefile. However, they in turn include others that > are not installed, thus obviating the usefulness of the ones that are. > The missing files are these: [snip] > The list can be regenerated with the attached script. Or use this one-liner (CWD=the include directory in the source dist): /lib/cpp -M -I. -I../backend executor/spi.h | \ xargs -n 1| \ grep \\W| \ grep -v ^/| \ grep -v spi.o | \ grep -v spi.h | \ sort (There are better ways of doing the regexps, I know). I use this in the RPM spec file to pull over the SPI headers, and have had to do so since 6.5.x days. Bruce, can we add a TODO item for make install to install _all_ necessary headers, including SPI ones? It is not at all necessary to have a source tree lying around to do SPI development (or at least it _shouldn't_ be necessary). A full source tree, configured and built, according to du, takes about 48MB of space (a pristine tree takes 36MB or so in comparison). The complete set of headers takes a little less than 1MB of space. (1MB of _headers_? Yow!) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] using the same connection?
Well actually this particular connection is just for selects... On Tue, 06 Feb 2001, you wrote: > On Tue, Feb 06, 2001 at 11:08:49AM -0500, Mathieu Dube wrote: > > Hi y'all, > > Is it a bad idea for an app to keep just a couple of connections to a > > database, put semaphore/mutex on them and reuse them all through the program? > > Of course I would check if their PQstatus isnt at CONNECTION_BAD and > > reconnect if they were... > > You would have to hold the lock from BEGIN until COMMIT. > Otherwise, connection re-use is normal. > > Nathan Myers > [EMAIL PROTECTED] -- Mathieu Dube Mondo-Live www.flipr.com
Re: [HACKERS] using the same connection?
On Tue, Feb 06, 2001 at 11:08:49AM -0500, Mathieu Dube wrote: > Hi y'all, > Is it a bad idea for an app to keep just a couple of connections to a > database, put semaphore/mutex on them and reuse them all through the program? > Of course I would check if their PQstatus isnt at CONNECTION_BAD and > reconnect if they were... You would have to hold the lock from BEGIN until COMMIT. Otherwise, connection re-use is normal. Nathan Myers [EMAIL PROTECTED]
[HACKERS] Re: 25 March 2001 bug
On Tue, 6 Feb 2001, Guest User wrote: > Apologies if this is the wrong place to send a question Please use, hackers (or other PG) list. More heads more know, more eyes more view :-) > Do you know if there is a patch for this bug and if so where I might be > able to find it? I think I'm using 7.0.3 too and I'm kind of stuck. I not sure, but it is probably fixed in 7.1 only without a backport patch... Comments? Karel
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 01:21:00PM -0500, Bruce Momjian wrote: > > > *** fe-exec.c 2001/01/24 19:43:30 1.98 > > > --- fe-exec.c 2001/02/06 02:02:27 1.100 > > > *** > > > *** 2035,2041 > > > if (len > 23) > > > len = 23; > > > strncpy(buf, res->cmdStatus + 7, len); > > > ! buf[23] = '\0'; > > > > > > return buf; > > > } > > > --- 2035,2041 > > > if (len > 23) > > > len = 23; > > > strncpy(buf, res->cmdStatus + 7, len); > > > ! buf[len] = '\0'; > > > > > > return buf; > > > } > > > > > > > Hmm, is there some undocumented feature of strncpy that I don't know > > about, where it modifies the passed length variable (which would be hard, > > since it's pass by value)? Otherwise, doesn't this patch just replace > > the constant '23' with the variable 'len', set to 23? > > What if len < 23? If len < 23, then strncpy will have terminated the destination already. Poking out buf[23] just compensates for a particular bit of brain damage in strncpy. Read the man page: The strncpy() function is similar [to strcpy], except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result wil not be null-terminated. Thus, the original code is OK, except probably the literal "23" in place of what should be a meaningful symbolic constant, or (at least!) sizeof(buf) - 1. BTW, that static buffer in PGoidStatus is likely to upset threaded client code... To null-terminate strings is an Abomination. Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] OID from insert has extra letter
On Tue, Feb 06, 2001 at 01:21:00PM -0500, Bruce Momjian wrote: > What if len < 23? mea culpa. Must go eat lunch. No sugar to brain. (and no, I didn't put the original error in :-) Ross
Re: [HACKERS] OID from insert has extra letter
> > *** fe-exec.c 2001/01/24 19:43:30 1.98 > > --- fe-exec.c 2001/02/06 02:02:27 1.100 > > *** > > *** 2035,2041 > > if (len > 23) > > len = 23; > > strncpy(buf, res->cmdStatus + 7, len); > > ! buf[23] = '\0'; > > > > return buf; > > } > > --- 2035,2041 > > if (len > 23) > > len = 23; > > strncpy(buf, res->cmdStatus + 7, len); > > ! buf[len] = '\0'; > > > > return buf; > > } > > > > Hmm, is there some undocumented feature of strncpy that I don't know > about, where it modifies the passed length variable (which would be hard, > since it's pass by value)? Otherwise, doesn't this patch just replace > the constant '23' with the variable 'len', set to 23? What if len < 23? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: [PATCHES] configure.in patch for readline and curses.
Rick Robino writes: > psql starts up with readline support turned on by default. If readline/curses > is broken, this may show up at runtime as a pq_recvbuf error and a core dump. > psql isn't obvious about the relationship to readline, creating a mystery for > first-timers. > > Since it is readline, and it is on by default, just maybe that first-timer > might reconfigure turning "luxuries" off and psql will work. That looks like a rather unusual way to proceed. > The alternative is them finding that obscure scrap of advice (not in > doc/*) associating recvbuf errors with readline support. The other alternative is fixing the underlying problem. > I had this problem on a very typically setup Solaris but did not look for a > way to build w/o readline. Yes, we have had several reports that termcap and ncurses don't like each other on Solaris. I'm going to alter configure to check for only one of the two. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Include files for SPI are not installed
On Tue, 6 Feb 2001, Oliver Elphick wrote: > Certain include files are installed by src/include/Makefile and by > interfaces/libpq++/Makefile. However, they in turn include others that > are not installed, thus obviating the usefulness of the ones that are. In your module you can use arbitrary routines from PG not only SPI, for example you trigger needs work with some datetypes and for this needs include anything from include/utils/ ... It expect install *all* header files. Not is better download PG sources and use -I option for your gcc? I expect header files on /usr/include/pgsql for client programming not for SPI. Karel
Re: [HACKERS] OID from insert has extra letter
On Mon, Feb 05, 2001 at 09:17:45PM -0500, Tom Lane wrote: > > Yes, on looking at it I see that someone broke PQoidStatus() in 7.0. > If you want to fix your copy, the patch (line numbers are for current > CVS) is > > Index: fe-exec.c > === > RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v > retrieving revision 1.98 > retrieving revision 1.100 > diff -c -r1.98 -r1.100 > *** fe-exec.c 2001/01/24 19:43:30 1.98 > --- fe-exec.c 2001/02/06 02:02:27 1.100 > *** > *** 2035,2041 > if (len > 23) > len = 23; > strncpy(buf, res->cmdStatus + 7, len); > ! buf[23] = '\0'; > > return buf; > } > --- 2035,2041 > if (len > 23) > len = 23; > strncpy(buf, res->cmdStatus + 7, len); > ! buf[len] = '\0'; > > return buf; > } > Hmm, is there some undocumented feature of strncpy that I don't know about, where it modifies the passed length variable (which would be hard, since it's pass by value)? Otherwise, doesn't this patch just replace the constant '23' with the variable 'len', set to 23? Ross
[HACKERS] Include files for SPI are not installed
Certain include files are installed by src/include/Makefile and by
interfaces/libpq++/Makefile. However, they in turn include others that
are not installed, thus obviating the usefulness of the ones that are.
The missing files are these:
access/heapam.h
access/htup.h
access/relscan.h
access/rmgr.h
access/sdir.h
access/skey.h
access/strat.h
access/transam.h
access/tupdesc.h
access/tupmacs.h
access/xact.h
access/xlogdefs.h
access/xlog.h
access/xlogutils.h
catalog/pg_am.h
catalog/pg_attribute.h
catalog/pg_class.h
catalog/pg_language.h
catalog/pg_proc.h
catalog/pg_type.h
executor/execdefs.h
executor/execdesc.h
executor/executor.h
executor/hashjoin.h
executor/tuptable.h
nodes/execnodes.h
nodes/memnodes.h
nodes/nodes.h
nodes/params.h
nodes/parsenodes.h
nodes/pg_list.h
nodes/plannodes.h
nodes/primnodes.h
nodes/relation.h
pgconnection.h
pgdatabase.h
pgtransdb.h
rewrite/prs2lock.h
storage/block.h
storage/buffile.h
storage/buf.h
storage/bufmgr.h
storage/bufpage.h
storage/fd.h
storage/ipc.h
storage/item.h
storage/itemid.h
storage/itemptr.h
storage/lmgr.h
storage/lock.h
storage/off.h
storage/page.h
storage/relfilenode.h
storage/shmem.h
storage/spin.h
tcop/dest.h
tcop/pquery.h
tcop/tcopprot.h
tcop/utility.h
utils/builtins.h
utils/datetime.h
utils/datum.h
utils/fcache.h
utils/hsearch.h
utils/memutils.h
utils/nabstime.h
utils/numeric.h
utils/portal.h
utils/rel.h
utils/syscache.h
utils/timestamp.h
utils/tqual.h
The list can be regenerated with the attached script.
Example:
$ pg_includes /usr/local/pgsql/include
#!/bin/sh
PGINCLUDEDIR=$1
[ -z "$PGINCLUDEDIR" ] && PGINCLUDEDIR=/usr/include/postgresql
find $PGINCLUDEDIR -name '*.h' |
sed "s|$PGINCLUDEDIR/||" >/tmp/$$
lastlc=-1
lc=0
while [ $lc -ne $lastlc ]
do
lastlc=$lc
(
(
cd ~/mypackages/pg7.1/postgresql-7.1beta4/src/include
cat /tmp/$$ | xargs grep '#include' 2>/dev/null
cd /usr/include/postgresql
cat /tmp/$$ | xargs grep '#include' 2>/dev/null
) |
grep -v '<' |
sed 's/^.*"\(.*\)".*$/\1/'
cat /tmp/$$
) |
sort -u >/tmp/$$-1
mv /tmp/$$-1 /tmp/$$
lc=`wc -l /tmp/$$ | awk '{print $1}'`
done
(
cat /tmp/$$
find $PGINCLUDEDIR -name '*.h' |
sed "s|$PGINCLUDEDIR/||"
) | sort | uniq -u
rm /tmp/$$
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
"He hath not dealt with us after our sins; nor rewarded
us according to our iniquities. For as the heaven is
high above the earth, so great is his mercy toward
them that fear him. As far as the east is from the
west, so far hath he removed our transgressions from
us." Psalms 103:10-12
Re: [HACKERS] Using Threads
On Tue, 6 Feb 2001, Karel Zak wrote: > > On Tue, 6 Feb 2001, Myron Scott wrote: > > > There are many many globals I had to work around including all the memory > > management stuff. I basically threw everything into and "environment" > > variable which I stored in a thread specific using thr_setspecific. > > Yes, it's good. I working on multi-thread application server > (http://mape.jcu.cz) and I use for this project some things from PG (like > mmgr), I planning use same solution. > > > Performance is acually very good for what I am doing. I was able to batch > > commit transactions which cuts down on fsync calls, use prepared > > statements from my client using CORBA, and the various locking calls for > > the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did > > some performance tests for inserts > > > > 20 clients, 900 inserts per client, 1 insert per transaction, 4 different > > tables. > > > > 7.0.2About10:52 average completion > > multi-threaded2:42 average completion > > 7.1beta3 1:13 average completion > > It is very very good for time for 7.1, already look forward to 7.2! :-) > > BTW, I not sure if you anytime in future will see threads in > official PostgreSQL and if you spending time on relevant things (IMHO). There have been discussions about this, where we still do one process per client, but the backend of that process would use threads in order to improve performance on SMP boxes for that one client ...
Re: [HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linuxrc.d/init.d script....
> On Sun, 4 Feb 2001, Peter Eisentraut wrote: > > > Ryan Kirkpatrick writes: > > > > > postgresql -> This is a Linux distribution independent (or so I > > > hope) init.d/rc.d script that makes use of pg_ctl. There is currently a > > > few in ./contrib/linux of the pgsql source tree, but they are RedHat > > > specific. This one is simple and self contained. Might be worth adding to > > > the other scripts. > > > > I don't see how this can be more independent if it uses > > > > DAEMON=/home/postgres/bin/pg_ctl > > Ooops That is my mistake... Should have been > /usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home > (where there is more, faster disk space). I can submit a patch, or can > some one just fix it? Change made. > > LOG="/usr/local/pgsql/server.log" > > What is wrong with that? There really is no standard on where to > put the log file, so it is either here or /var/log. > > > su - postgres sh -c "$DAEMON stop >& /dev/null" > > Hmm... What is wrong here, besides the '>&'? The '>&' can be > replaced with '2>&1 >' if that is more standard. > Change made. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Using Threads
On Tue, 6 Feb 2001, Myron Scott wrote: > There are many many globals I had to work around including all the memory > management stuff. I basically threw everything into and "environment" > variable which I stored in a thread specific using thr_setspecific. Yes, it's good. I working on multi-thread application server (http://mape.jcu.cz) and I use for this project some things from PG (like mmgr), I planning use same solution. > Performance is acually very good for what I am doing. I was able to batch > commit transactions which cuts down on fsync calls, use prepared > statements from my client using CORBA, and the various locking calls for > the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did > some performance tests for inserts > > 20 clients, 900 inserts per client, 1 insert per transaction, 4 different > tables. > > 7.0.2About10:52 average completion > multi-threaded2:42 average completion > 7.1beta3 1:13 average completion It is very very good for time for 7.1, already look forward to 7.2! :-) BTW, I not sure if you anytime in future will see threads in official PostgreSQL and if you spending time on relevant things (IMHO). Karel
Re: [HACKERS] little bug in current CVS
Oleg Bartunov writes: > after make clean, make failed with message: > > make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' > prereqdir=`cd parser/ && pwd` && \ > cd ../../src/include/parser/ && rm -f parse.h && \ > ln -s $prereqdir/parse.h . > ln: ./parser: File exists > make[2]: *** [../../src/include/parser/parse.h] Error 1 Try changing the second line to this prereqdir=`CDPATH=: ; cd parser/ && pwd` && \ -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] little bug in current CVS
On Tue, 6 Feb 2001, Tom Lane wrote: > Oleg Bartunov <[EMAIL PROTECTED]> writes: > > make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' > > prereqdir=`cd parser/ && pwd` && \ > > cd ../../src/include/parser/ && rm -f parse.h && \ > > ln -s $prereqdir/parse.h . > > ln: ./parser: File exists > > make[2]: *** [../../src/include/parser/parse.h] Error 1 > > Hm. I bet your shell is failing to strip whitespace from the output of > pwd, so that the ln command ends up looking like > > ln -s /home/postgres/cvs/pgsql/src/backend/parser /parse.h . > > Can you check that theory by inserting an 'echo'? you're right. shell is BASH_VERSION='2.04.0(1)-release' Makefile looks too complex: $(top_builddir)/src/include/parser/parse.h: $(srcdir)/parser/parse.h prereqdir=`cd $(dir $<) && pwd` && \ cd $(dir $@) && rm -f $(notdir $@) && \ $(LN_S) $$prereqdir/$(notdir $<) . We're already in src/backend directory, why not use ln -sf parser/parse.h . > > regards, tom lane > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] ADD CONSTRAINT ... FOREIGN KEY and custom data type.
I think you may be running into the now fixed (for 7.1) bug where ADD CONSTRAINT ... FOREIGN KEY got the column ordering wrong when checking existing data. I may be able to build a patch against 7.0.x since the fix is relatively minor if you don't plan to upgrade when 7.1 comes out. On Mon, 5 Feb 2001, Panon, Paul-Andre wrote: > > For a project we are working on, I have created a custom postgresql data > type which is similar to MS SQL Server's uniqueidentifier data type. It uses > dynamic link library extension that calls the FreeDCE library to generate > GUIDs. Support for the data type and support functions is added to a > PostgreSQL database using the attached SQL script. The functions all seems > to work fine, including use of merge sorts and hash joins during SQL JOIN > statements when using the data type as part of a primary key. However > adding foreign key constraints sometimes causes a problem. > > I never have a problem adding a foreign key to a parent table with a > multi-part key as long as the child table is empty. Adding data to the child > entity afterwards seems to properly enforce RI. However, if data exists in > the child entity, an RI check is performed on the existing data and this > check sometimes seems to break. As far as I can tell, the RI check in the > latter case seems to confuse the order the Key parts in either the Primary > Key or the Foreign Key. In the case of a multi-part key RI, it was > complaining that it couldn't perform a type conversion between the type of > two different key parts of the primary key. > > So in a database with the following table definitions (OK I know it isn't > exactly great DB design to have 4 uniqueidentifiers in a PK, but please bear > with me) :
Re: [HACKERS] Re: [BUGS] syslog logging setup broken?
Tatsuo Ishii writes: > Moreover if postmaster detaches itself to be a deamon, nohup is not > necessary at all. Right. Scrap that thought then. > BTW, for the startup script, I don't think we need to use pg_ctl. > Invoking postmaster directry seems enough for me. The only reason for > using pg_ctl to start postmaster is waiting for postmaster up and > running. Waiting for the postmaster to start up is really only useful when you start it interactively, either during development, or if you need to repair a problem. In either of these cases you might as well (and probably rather should) look at the log output yourself, i.e., just use 'postmaster'. > In most cases the time to recover DB would not be so > long. And if the recovery took too long time, we would not want to be > blocked in the middle of the boot sequence anyway. Exactly. No waiting on startup by default then? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] using the same connection?
Hi y'all, Is it a bad idea for an app to keep just a couple of connections to a database, put semaphore/mutex on them and reuse them all through the program? Of course I would check if their PQstatus isnt at CONNECTION_BAD and reconnect if they were... I need some opinions on that practice... Thanks -Mat -- Mathieu Dube Mondo-Live www.flipr.com
Re: [HACKERS] little bug in current CVS
Oleg Bartunov <[EMAIL PROTECTED]> writes: > make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' > prereqdir=`cd parser/ && pwd` && \ > cd ../../src/include/parser/ && rm -f parse.h && \ > ln -s $prereqdir/parse.h . > ln: ./parser: File exists > make[2]: *** [../../src/include/parser/parse.h] Error 1 Hm. I bet your shell is failing to strip whitespace from the output of pwd, so that the ln command ends up looking like ln -s /home/postgres/cvs/pgsql/src/backend/parser /parse.h . Can you check that theory by inserting an 'echo'? regards, tom lane
Re: [HACKERS] optimizer/planner ideas (repost)
Martin Devera <[EMAIL PROTECTED]> writes: > Inner semijoin scans its left input outputting all rows which > has its pair in right input but doesn't duplicate result when > there are duplicates at right. > The WHERE IN(select...), corelated EXISTS and ANY are > converted to it. This semijoin is simple to efectively implement > for all physical join types. > NOT IN, NOT EXISTS and ALL uses anti-semi-inner-join. The > join outputs lefts which can't be paired and don't duplicate > others. Again, simple implementation. > Have anyone thought about it ? Yes, this is exactly what I was thinking of doing in 7.2 or so ... regards, tom lane
Re: [HACKERS] Using Threads
> > Sorry I haven't time to see and test your experiment, > but I have a question. How you solve memory management? > The current mmgr is based on global variable > CurrentMemoryContext that is very often changed and used. > Use you for this locks? If yes it is probably problematic > point for perfomance. > > Karel > There are many many globals I had to work around including all the memory management stuff. I basically threw everything into and "environment" variable which I stored in a thread specific using thr_setspecific. Performance is acually very good for what I am doing. I was able to batch commit transactions which cuts down on fsync calls, use prepared statements from my client using CORBA, and the various locking calls for the threads (cond_wait,mutex_lock, and sema_wait) seem pretty fast. I did some performance tests for inserts 20 clients, 900 inserts per client, 1 insert per transaction, 4 different tables. 7.0.2About10:52 average completion multi-threaded2:42 average completion 7.1beta3 1:13 average completion If I increased the number of inserts per transaction, multi-threaded got closer to 7.1 for inserts. I haven't tested other other types of commands yet. Myron Scott [EMAIL PROTECTED]
[HACKERS] Re: Implementing an operator in C?
Mario Weilguni wrote:
>
> Am Sonntag, 4. Februar 2001 20:12 schrieben Sie:
> > Mario Weilguni <[EMAIL PROTECTED]> writes:
> > > float8 num3 = numeric_float8(num1);
> >
> > That won't work in the brave new world of 7.1 :-(. You need to do
> > something like
> >
> > float8 num3 = DatumGetFloat8(DirectFunctionCall1(numeric_float8,
> > NumericGetDatum(num1)));
> >
> > Ugly, I know ... but we have to be rigidly careful about converting
> > values to Datum and back in order to avoid portability problems.
> >
> > A decent C compiler should've warned about type mismatches in your call,
> > BTW.
> >
> > regards, tom lane
>
> Thanks alot for the info, but the problem is elsewhere. Even a simple
> function like
> Datum
> nef(PG_FUNCTION_ARGS)
> {
> Numeric num1 = PG_GETARG_NUMERIC(0);
> PG_RETURN_BOOL(true);
> }
>
> will crash. The macro PG_GETARG_NUMERIC evaluates to:
> ((Numeric)pg_detoast_datum((struct varlena *) ((Pointer) ( (fcinfo->arg[0])))
> and this pg_detoast_datum will lead to a crash (SIGSEGV). So I think I must
> be doing something wrong here, isn't it?
Could be. What data type *is* the input argument? It had better be of
type "NUMERIC", and not of type "FLOAT8", which of course uses a
different accessor function...
- Thomas
Re: AW: [HACKERS] timestamp in pg_dump
> But the current timestamp does not store a timezone. timestamp with time zone > is supposed to store and output the timezone that was inserted. > The current timestamp has it messed up (sorry), since it does not store a timezone. > It stores time in UTC and always converts output to the timezone derived from [PG]TZ. Good point, but I'll disagree with the implied conclusion. imho the SQL9x provisions for time zone handling are fundamentally and tragically broken, with absolutely no provisions for DST, time zone shifting, etc etc. Which helps lead most folks to code other databases without time zones at all. Date and Darwen (1997) have essentially the same opinion (though the last sentence is my own speculation). > IMHO timestamp is currently closest to the ANSI timestamp without time zone. > Especially if you always omit a timezone for input and ignore the timezone that is >output. Hmm. My thought was to implement a timestamp type without *any* time zone manipulation, leaving our current type as the "zone-full" one, but it should be discussed whether we need a high-fidelity implementation of the fundamentally useless SQL9x version. fwiw, I did implement "time with time zone", which was easy, mostly to "check the feature box" and I'll guess that no one bothers to use it. Comments? - Thomas
[HACKERS] optimizer/planner ideas
Hello,
probably you remember my crazy idea involving using indexes
directly in scans (and resulting speedup).
The idea was given to me by experiences with M$SQL (it is
yes another M$ soft but its planner is probably better
than pg's - no flames please).
Because I studied M$ again I've got another ideas.
Every SQL query can be probably translated into joins without
need for "nested subquery" executor node.
In M$SQL7 each join has at least two properties: logical
and physical type. Physical types can be: {nested loop,
hash,merge} join and logical: {left,full,inner,semi-inner,anti-semi}.
It is the same in pgsql except for semi joins.
Inner semijoin scans its left input outputting all rows which
has its pair in right input but doesn't duplicate result when
there are duplicates at right.
The WHERE IN(select...), corelated EXISTS and ANY are
converted to it. This semijoin is simple to efectively implement
for all physical join types.
NOT IN, NOT EXISTS and ALL uses anti-semi-inner-join. The
join outputs lefts which can't be paired and don't duplicate
others. Again, simple implementation.
As I studied outputs from M$ planner, it uses those joins and
later tries to find optimal plan by combining ALL joins.
In pg we can't cross subplan node in optimizing (AFAIK). So
we can't swap relations in outer and inner plan even if it
would lead into mode effective plan.
The result is that in M$SQL7 almost all plans with [NOT]{IN,EXISTS}
I tried was much faster both in clean time of run and in number
of logical reads/scans.
Have anyone thought about it ?
regards, devik
[HACKERS] Re: TODO list: Allow Java server-side programming
PHP can run java code. It would be easiest, because php doesn't parse php pages, the Zend engine is linked to php to actually parse. Which would make Zend easy to add into Postgresql, (which already runs under apache, which is non-threaded). The only issue is the Zend license.. Of course, this may sound crazy and expensive, but you could throw some apache code in there, and allow any language that works under apache work under postgresql. Call me crazy, but that would allow people to run any parsed language inside of postgresql.
Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX
> "Tom Lane" <[EMAIL PROTECTED]> writes: >> Well, my question still stands: why aren't the other four flex outputs >> also broken? They all use ECHO. I don't know why, but probably you are right. I only know that if ECHO was not redefined, when I compile with ecpg the output c file has all the original lines on the same row (without an LF). > In any case, I'd prefer to see this fixed by not including > rather than hacking up the .l files. Surely it doesn't need to be > included everywhere, as src/include/port/qnx4.h is now causing to > happen. In fact, it looks to me like qnx4.h probably includes and > defines a lot more than it needs to; would you experiment with stripping > it down? If You want I can experiment on qnx4.h. On Saturday I will post the risults. > That strikes me as *horribly* dangerous. There is too much code whose > behavior might change in unpleasant ways if Size becomes a signed type. > Please explain what problems you are seeing that make you think this is > a good idea. In 7.0.2 and 7.0.3 release I have errors about some parameters in TCP/IP functions. The compiler tells me that I have a long int where an int was expected. When I changed Size in int I compiled successfuly PGSQL. In 7.1 I changed immediatly the size type and all seems works. After your message I modified again Size type in size_t and recompiled 7.1 release. I compiled successfuly this version the only warnings are about elog lines in wich there are Size variables. The compiler tells me I have a long int where an unsigned was expected (only the format, there is a %u). e.g. readfuncs.c at 2089 and 2113. However PGSQL works right. > Andreas, the QNX port is largely your work IIRC. What do you think of > these issues? Have you tried 7.1beta on QNX? I also would like to know Andreas Kardos is still out there and what he think. When, some month ago, I starded looking for POSTGRESQL and I had a lot of problems compiling 7.0.1 version (the major problem was what I have to do for the Size type?) I send some e-mails to Dr. Kardos and he tells me that his version working fine. After the first replay he never didn't replay to me. Also other QNX users has the same problems I had and send me e-mails to know if I have compiled successfully PGSQL for QNX. Nobody has had a reply from Dr. Kardos. thanks regards Maurizio Cauci - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Maurizio" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Bruce Momjian" <[EMAIL PROTECTED]>; "Kardos, Dr. Andreas" < Sent: Tuesday, February 06, 2001 4:08 AM Subject: Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX > "Maurizio" <[EMAIL PROTECTED]> writes: > > ECHO is defined in the following QNX gcc include files : > > termio.h > > termios.h > > If ECHO was not redefined in pgc.l you can't compile in embedded SQL C. > > Well, my question still stands: why aren't the other four flex outputs > also broken? They all use ECHO. > > In any case, I'd prefer to see this fixed by not including > rather than hacking up the .l files. Surely it doesn't need to be > included everywhere, as src/include/port/qnx4.h is now causing to > happen. In fact, it looks to me like qnx4.h probably includes and > defines a lot more than it needs to; would you experiment with stripping > it down? > > > I am also checking for another problem. > > I have some errors if I compile pgsql without change the typedef Size in > > c.h. > > To succesfully compile pgsql I have changed typedef Size in int insteed > > size_t. > > That strikes me as *horribly* dangerous. There is too much code whose > behavior might change in unpleasant ways if Size becomes a signed type. > Please explain what problems you are seeing that make you think this is > a good idea. > > > Andreas, the QNX port is largely your work IIRC. What do you think of > these issues? Have you tried 7.1beta on QNX? > > regards, tom lane
Re: [GENERAL] Re: [HACKERS] Re: Re: grant privileges to a database [URGENT]
A step in the right direction for this to have the system catalog have pg_user_* views. So dor databases we have: create view pg_user_database as select * from pg_database where pg_get_userbyid(datdba) = CURRENT_USER Of course, this doesn't account for superusers, but I'm sure there is a way the gurus can accomplish that. -Dan - Original Message - From: "Mike Miller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 05, 2001 8:04 PM Subject: [GENERAL] Re: [HACKERS] Re: Re: grant privileges to a database [URGENT] > Hrm- I'd love to know where this patch is. I don't see how that quite > breaks PG_DUMPALL though. Really if your logged in as a superuser > (postgres) you should be able to use all the databases and dump all of the > data. Am I the only one that doesn't see where the problem is? How about a > patch that says 'if the user that created the database is not the current > user, then reject- otherwise accept'. I could go for that. Though access > control would be nice, I could log in as a superuser, make a user with the > ability to make databases, login as that user, make the databases I need, > then login as postgres and revoke the privilages of creating databases. > Suddenly you can only access databases you created and its as easy as that > (a few PHP lines if you ask me) to make new databases. Wouldn't it just be > a simple IF statement to see if the current user is the database owner [or > if they have the superuser ID set]? > > Am I not seeing the big picture? > > -- > Mike > > > >From: Kovacs Baldvin <[EMAIL PROTECTED]> > >To: Mike Miller <[EMAIL PROTECTED]> > >CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > >[EMAIL PROTECTED],[EMAIL PROTECTED] > >Subject: Re: [HACKERS] Re: Re: grant privileges to a database [URGENT] > >Date: Mon, 5 Feb 2001 20:13:38 +0100 (MET) > > > >Hello > > > >A few weeks ago I was interested in this question. My results were: > >- Yes, this is a sorrowful but true fact that if you enable access to > > someone to a database, she is automatically enabled to create > > objects in it. > >- Yes, the developers know it, and they said: there is a patch existing > > to workaround it. > >- No, they don't include it in 7.1. The reason: if you use that patch, > > pg_dumpall will not work. If somebody will have the strength in > > him to fix it, than it will be considered to include it in the base. > > > >After collecting these informations from more experienced people, > >I calmed down. Since I am in the beginning of creating my project, > >I think for the time when I will need it, it will be ready. > > > >Anyway, I do not know where this patch is. If you don't bother > >about pg_dumpall, ask a developer (a am only a wannabe developer) > >about it. > > > >If anyone detects that I wrote silly things, please do correct me. > > > >Bye, > >Baldvin > > > > > > > > > > _ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. >
[HACKERS] ADD CONSTRAINT ... FOREIGN KEY and custom data type.
For a project we are working on, I have created a custom postgresql data
type which is similar to MS SQL Server's uniqueidentifier data type. It uses
dynamic link library extension that calls the FreeDCE library to generate
GUIDs. Support for the data type and support functions is added to a
PostgreSQL database using the attached SQL script. The functions all seems
to work fine, including use of merge sorts and hash joins during SQL JOIN
statements when using the data type as part of a primary key. However
adding foreign key constraints sometimes causes a problem.
I never have a problem adding a foreign key to a parent table with a
multi-part key as long as the child table is empty. Adding data to the child
entity afterwards seems to properly enforce RI. However, if data exists in
the child entity, an RI check is performed on the existing data and this
check sometimes seems to break. As far as I can tell, the RI check in the
latter case seems to confuse the order the Key parts in either the Primary
Key or the Foreign Key. In the case of a multi-part key RI, it was
complaining that it couldn't perform a type conversion between the type of
two different key parts of the primary key.
So in a database with the following table definitions (OK I know it isn't
exactly great DB design to have 4 uniqueidentifiers in a PK, but please bear
with me) :
--
CREATE TABLE Mo_Cvg_Rptd (
Emp_Grp_ID uniqueidentifier NOT NULL,
Ben_Plan_ID uniqueidentifier NOT NULL,
Grp_Rate_ID uniqueidentifier NOT NULL,
Rate_Step_ID uniqueidentifier NOT NULL,
Cvg_Yr_Modate NOT NULL,
Rptg_Session_ID uniqueidentifier,
Mo_Cvg_Rptd_Sts_Cd int2,
Mo_Except_Sts_Cd int2,
Mo_Except_Desc varchar(150),
Mdfy_Dt DATETIME NOT NULL DEFAULT date('now'),
PRIMARY KEY (Emp_Grp_ID, Ben_Plan_ID, Grp_Rate_ID,
Rate_Step_ID, Cvg_Yr_Mo)
);
CREATE TABLE Prior_Mo_Prd_Adjmt (
Emp_Grp_ID uniqueidentifier NOT NULL,
Ben_Plan_ID uniqueidentifier NOT NULL,
Grp_Rate_ID uniqueidentifier NOT NULL,
Rate_Step_ID uniqueidentifier NOT NULL,
Cvg_Yr_Modate NOT NULL,
Prior_Prd_Adjmt_Amt int2,
Prior_Prd_Adjmt_Desc varchar(150),
Prior_Prd_Adjmt_Except_Sts_Cd int2,
Prior_Prd_Adjmt_Except_Desc varchar(150),
PRIMARY KEY (Emp_Grp_ID, Ben_Plan_ID, Grp_Rate_ID,
Rate_Step_ID, Cvg_Yr_Mo)
);
ALTER TABLE Prior_Mo_Prd_Adjmt
ADD CONSTRAINT FK_PriorMoPrdAdjmt_MoCvgRptd FOREIGN KEY(Emp_Grp_ID,
Ben_Plan_ID,
Grp_Rate_ID,
Rate_Step_ID,
Cvg_Yr_Mo)
REFERENCES Mo_Cvg_Rptd;
--
If I want to change a column in Prior_Mo_Prd_Adjmt (with the aid of Erwin),
I have to drop the table and recreate it with a script similar to the
following:
**
CREATE TABLE prior_mo_prd_adjmtL25D434 (emp_grp_id uniqueidentifier,
ben_plan_id uniqueidentifier, grp_rate_id
uniqueidentifier, rate_step_id uniqueidentifier,
cvg_yr_mo date, prior_prd_adjmt_amt int4, prior_prd_adjmt_desc
varchar(150), prior_prd_adjmt_except_sts_cd int2,
prior_prd_adjmt_except_desc varchar(150));
INSERT INTO prior_mo_prd_adjmtL25D434 (emp_grp_id, ben_plan_id,
grp_rate_id,
rate_step_id, cvg_yr_mo, prior_prd_adjmt_amt, prior_prd_adjmt_desc,
prior_prd_adjmt_except_sts_cd, prior_prd_adjmt_except_desc)
SELECT emp_grp_id, ben_plan_id, grp_rate_id,
rate_step_id, cvg_yr_mo, prior_prd_adjmt_amt, prior_prd_adjmt_desc,
prior_prd_adjmt_except_sts_cd, prior_prd_adjmt_except_desc
FROM prior_mo_prd_adjmt;
DROP TABLE prior_mo_prd_adjmt;
CREATE TABLE Prior_Mo_Prd_Adjmt (
Emp_Grp_ID uniqueidentifier NOT NULL,
Ben_Plan_ID uniqueidentifier NOT NULL,
Grp_Rate_ID uniqueidentifier NOT NULL,
Rate_Step_ID uniqueidentifier NOT NULL,
Cvg_Yr_Modate NOT NULL,
Prior_Prd_Adjmt_Amt numeric(9,2),
Prior_Prd_Adjmt_Desc varchar(150),
Prior_Prd_Adjmt_Except_Sts_Cd int2,
Prior_Prd_Adjmt_Except_Desc varchar(150),
PRIMARY KEY (Emp_Grp_ID, Ben_Plan_ID, Grp_Rate_ID,
Rate_Step_ID, Cvg_Yr_Mo)
);
CREATE UNIQUE INDEX IDX_Prior_Mo_Prd_Adjmt_PK ON Prior_Mo_Prd_Adjmt
(
Emp_Grp_ID,
Ben_Plan_ID,
Grp_Rate_ID,
Rate_Step_ID,
Cvg_Yr_Mo
);
ALTER TABLE Prior_Mo_Prd_Adjmt
ADD CONSTRAINT FK_PriorMoPrdAdjmt_MoCvgRptd FOREIGN KEY(Emp_Grp_ID,
Ben_Plan_ID,
Re: [HACKERS] ODBC Problem v7.1 beta4
Yes, I have the same problem... pgaccess also can't see any Views... "Steve Shaffer" <[EMAIL PROTECTED]> escreveu nas notícias de mensagem:[EMAIL PROTECTED] > > Developers, > > Pgsql v7.1 beta4 > ODBC v6.50.00.00 > RedHat v6.2 > > I upgraded from 7.03 to 7.1 beta4 yesterday & see the following problem. > > After the upgrade, applications like Crystal Reports, MS Query, Brio, etc. > now do not see the catalog of tables and fields in the database, login is > through user postgres. > > SQL statements sent directly through the ODBC work correctly. > > The pgAdmin utility CAN see the catalog of all of the tables & fields OK > through the same login. > > I played with all of the options of the ODBC driver & postgres security & > could not find a solution. Also, searched the site for any similar problems > & found no posts. > > Can anyone verify this problem? Any ideas? > > Thanks for the help, > > Steve Shaffer ([EMAIL PROTECTED]) >
Re: [HACKERS] Re: [BUGS] syslog logging setup broken?
>>> Tom Lane <[EMAIL PROTECTED]> 06-Feb-01 12:39:24 AM >>> > "Nic Ferrier" wrote: - the postmaster was being started without nohup Oliver wrote: >> If postmaster is being started by init, it should not need >> nohup, because init never exits and postmaster is not >> going to get shutdown unexpectedly. I agree... I was just putting into the script what was in the man page about postmaster. The man page suggests that nohup is required to init postmaster, I know this isn't true but to implement an example init file and not match up with the man page seemed foolish. I guess nohup would stop postmaster doing something awfull if it doesn't handle HUP properly but I very much doubt that you guys fail to handle HUP. Nic
[HACKERS] Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.dscript....
On Sun, 4 Feb 2001, Peter Eisentraut wrote: > Ryan Kirkpatrick writes: > > > postgresql -> This is a Linux distribution independent (or so I > > hope) init.d/rc.d script that makes use of pg_ctl. There is currently a > > few in ./contrib/linux of the pgsql source tree, but they are RedHat > > specific. This one is simple and self contained. Might be worth adding to > > the other scripts. > > I don't see how this can be more independent if it uses > > DAEMON=/home/postgres/bin/pg_ctl Ooops That is my mistake... Should have been /usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home (where there is more, faster disk space). I can submit a patch, or can some one just fix it? > LOG="/usr/local/pgsql/server.log" What is wrong with that? There really is no standard on where to put the log file, so it is either here or /var/log. > su - postgres sh -c "$DAEMON stop >& /dev/null" Hmm... What is wrong here, besides the '>&'? The '>&' can be replaced with '2>&1 >' if that is more standard. > an appropriate way to stop the server in a system shutdown situation. Uh... Isn't that the way you are supposed to stop it? pg_ctl stop? > IMHO, rather than accumulating a bunch of versions that somebody liked > better than the existing ones, why not provide actual scripts from actual > distributions? Generic scripts will just lead to generic problems. Fine by me... I just put mine up as a suggestion, as the only other one in contrib was very RH specific. The one included with the debian package is very debian specific (and over complex in IMHO). I just submitted mine as a possible generic Linux version that should work with bash on most installation. If some one has a better idea, then by all means post it. Also, from the way I understand contrib, they are user submissions and are in no way assured to work on any other machine than the user's who submitted it. I take it as given anything in contrib might need a bit of editing to fit my needs. Anyway, just my response as one who has used Slackware, RedHat, and now Debian over the years, but who in no way claims to be an uber-Linux or Unix hacker or sysadmin. :) PS. I do play a part time Linux sysadmin in real though... --- | "For to me to live is Christ, and to die is gain."| |--- Philippians 1:21 (KJV) | --- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---
Re: [HACKERS] Implementing an operator in C?
Am Sonntag, 4. Februar 2001 20:12 schrieben Sie:
> Mario Weilguni <[EMAIL PROTECTED]> writes:
> > float8 num3 = numeric_float8(num1);
>
> That won't work in the brave new world of 7.1 :-(. You need to do
> something like
>
> float8 num3 = DatumGetFloat8(DirectFunctionCall1(numeric_float8,
> NumericGetDatum(num1)));
>
> Ugly, I know ... but we have to be rigidly careful about converting
> values to Datum and back in order to avoid portability problems.
>
> A decent C compiler should've warned about type mismatches in your call,
> BTW.
>
> regards, tom lane
Thanks alot for the info, but the problem is elsewhere. Even a simple
function like
Datum
nef(PG_FUNCTION_ARGS)
{
Numeric num1 = PG_GETARG_NUMERIC(0);
PG_RETURN_BOOL(true);
}
will crash. The macro PG_GETARG_NUMERIC evaluates to:
((Numeric)pg_detoast_datum((struct varlena *) ((Pointer) ( (fcinfo->arg[0])))
and this pg_detoast_datum will lead to a crash (SIGSEGV). So I think I must
be doing something wrong here, isn't it?
Thanks!
Best regards,
Mario Weilguni
--
===
Mario Weilguni KPNQwest Austria GmbH
Senior Engineer Web Solutions Nikolaiplatz 4
tel: +43-316-813824 8020 graz, austria
fax: +43-316-813824-26 http://www.kpnqwest.at
e-mail: [EMAIL PROTECTED]
===
[HACKERS] little bug in current CVS
Hi, after make clean, make failed with message: make[2]: Entering directory /home/postgres/cvs/pgsql/src/backend' prereqdir=`cd parser/ && pwd` && \ cd ../../src/include/parser/ && rm -f parse.h && \ ln -s $prereqdir/parse.h . ln: ./parser: File exists make[2]: *** [../../src/include/parser/parse.h] Error 1 Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
[HACKERS] optimizer/planner ideas (repost)
Hello,
probably you remember my crazy idea involving using indexes
directly in scans (and resulting speedup).
The idea was given to me by experiences with M$SQL (it is
yes another M$ soft but its planner is probably better
than pg's - no flames please).
Because I studied M$ again I've got another ideas.
Every SQL query can be probably translated into joins without
need for "nested subquery" executor node.
In M$SQL7 each join has at least two properties: logical
and physical type. Physical types can be: {nested loop,
hash,merge} join and logical: {left,full,inner,semi-inner,anti-semi}.
It is the same in pgsql except for semi joins.
Inner semijoin scans its left input outputting all rows which
has its pair in right input but doesn't duplicate result when
there are duplicates at right.
The WHERE IN(select...), corelated EXISTS and ANY are
converted to it. This semijoin is simple to efectively implement
for all physical join types.
NOT IN, NOT EXISTS and ALL uses anti-semi-inner-join. The
join outputs lefts which can't be paired and don't duplicate
others. Again, simple implementation.
As I studied outputs from M$ planner, it uses those joins and
later tries to find optimal plan by combining ALL joins.
In pg we can't cross subplan node in optimizing (AFAIK). So
we can't swap relations in outer and inner plan even if it
would lead into mode effective plan.
The result is that in M$SQL7 almost all plans with [NOT]{IN,EXISTS}
I tried was much faster both in clean time of run and in number
of logical reads/scans.
Have anyone thought about it ?
regards, devik
AW: [HACKERS] timestamp in pg_dump
> I'd like to have pg_dump for 7.1 produce "timestamp with time zone" when > dealing with timestamp type(s). That will prepare us for introducing a > timestamp type without time zones, while allowing reasonable upgrades to > 7.2. But the current timestamp does not store a timezone. timestamp with time zone is supposed to store and output the timezone that was inserted. The current timestamp has it messed up (sorry), since it does not store a timezone. It stores time in UTC and always converts output to the timezone derived from [PG]TZ. IMHO timestamp is currently closest to the ANSI timestamp without time zone. Especially if you always omit a timezone for input and ignore the timezone that is output. A reasonably easy upgrade is imho not possible :-( Andreas
Re: [HACKERS] Postgre SQL for Windows
Quoting sourabh dixit <[EMAIL PROTECTED]>: > Hello! > Can anybody tell me the website from which I can download PostgreSQL > for Windows95. I'm not sure if it will run under Win95, but I have it running fine under NT using Cygwin and WinIPC. While my linux box was down, I had to use it under NT to work on the JDBC driver. Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX
> "Tom Lane" <[EMAIL PROTECTED]> writes: >> Well, my question still stands: why aren't the other four flex outputs >> also broken? They all use ECHO. I don't know why, but probably you are right. I only know that if ECHO was not redefined, when I compile with ecpg the output c file has all the original lines on the same row (without an LF). > In any case, I'd prefer to see this fixed by not including > rather than hacking up the .l files. Surely it doesn't need to be > included everywhere, as src/include/port/qnx4.h is now causing to > happen. In fact, it looks to me like qnx4.h probably includes and > defines a lot more than it needs to; would you experiment with stripping > it down? If You want I can experiment on qnx4.h. On Saturday I will post the risults. > That strikes me as *horribly* dangerous. There is too much code whose > behavior might change in unpleasant ways if Size becomes a signed type. > Please explain what problems you are seeing that make you think this is > a good idea. In 7.0.2 and 7.0.3 release I have errors about some parameters in TCP/IP functions. The compiler tells me that I have a long int where an int was expected. When I changed Size in int I compiled successfuly PGSQL. In 7.1 I changed immediatly the size type and all seems works. After your message I modified again Size type in size_t and recompiled 7.1 release. I compiled successfuly this version the only warnings are about elog lines in wich there are Size variables. The compiler tells me I have a long int where an unsigned was expected (only the format, there is a %u). However PGSQL works right. > Andreas, the QNX port is largely your work IIRC. What do you think of > these issues? Have you tried 7.1beta on QNX? I also would like to know what Andreas Kardos think. When, some month ago, I starded looking for POSTGRESQL and I had a lot of problems compiling 7.0.1 version (the major problem was what I have to do for the Size type?) I send some e-mails to Dr. Kardos and he tells me that his version working fine. After the first replay he didn't replay to me. Also other QNX users has the same problems I had and send me e-mails to know if I have compiled successfully PGSQl for QNX. Nobody has had a reply from Dr. Kardos. regards Maurizio Cauci - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Maurizio" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Bruce Momjian" <[EMAIL PROTECTED]>; "Kardos, Dr. Andreas" < Sent: Tuesday, February 06, 2001 4:08 AM Subject: Re: [HACKERS] 7.1 beta 3 CHANGES FOR QNX > "Maurizio" <[EMAIL PROTECTED]> writes: > > ECHO is defined in the following QNX gcc include files : > > termio.h > > termios.h > > If ECHO was not redefined in pgc.l you can't compile in embedded SQL C. > > Well, my question still stands: why aren't the other four flex outputs > also broken? They all use ECHO. > > In any case, I'd prefer to see this fixed by not including > rather than hacking up the .l files. Surely it doesn't need to be > included everywhere, as src/include/port/qnx4.h is now causing to > happen. In fact, it looks to me like qnx4.h probably includes and > defines a lot more than it needs to; would you experiment with stripping > it down? > > > I am also checking for another problem. > > I have some errors if I compile pgsql without change the typedef Size in > > c.h. > > To succesfully compile pgsql I have changed typedef Size in int insteed > > size_t. > > That strikes me as *horribly* dangerous. There is too much code whose > behavior might change in unpleasant ways if Size becomes a signed type. > Please explain what problems you are seeing that make you think this is > a good idea. > > > Andreas, the QNX port is largely your work IIRC. What do you think of > these issues? Have you tried 7.1beta on QNX? > > regards, tom lane
Re: [HACKERS] Using Threads?
On Mon, 5 Feb 2001, Myron Scott wrote: > I have put a new version of my multi-threaded > postgresql experiment at > > http://www.sacadia.com/mtpg.html > > This one actually works. I have added a server > based on omniORB, a CORBA 2.3 ORB from ATT. It >is much smaller than TAO and uses the thread per > connection model. I haven't added the java side > of the JNI interface yet but the C++ side is there. > > It's still not stable but it is much better than > [EMAIL PROTECTED] Sorry I haven't time to see and test your experiment, but I have a question. How you solve memory management? The current mmgr is based on global variable CurrentMemoryContext that is very often changed and used. Use you for this locks? If yes it is probably problematic point for perfomance. Karel
[HACKERS] Postgre SQL for Windows
Hello! Can anybody tell me the website from which I can download PostgreSQL for Windows95. With regards, Sourabh
