Re: [HACKERS] Build farm
Andrew Dunstan writes: If there's general interest I'll try to cook something up. (This kind of stuff is right up my alley). I'd prefer some automated display of results, though. A simple CGI script should be all that's required for that. The real problem will be to find enough machines so that the build farm becomes useful. IMO, that would mean *more* machines than are currently lines in the supported-platforms table. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Win32 port
Le Mardi 18 Novembre 2003 20:22, ow a écrit : Not really. I simply think there are more pressing issues than win32 port. Dear friends, Porting to Win32 can multiply: - direct users (i.e. developers) by a factor of two or three, - indirect users by a larger factor, provided that major projects include PostgreSQL in their offer. PostgreSQL is a potential candidate for integration in OpenOffice, PHP bundles and several other projects. This is not the case of Firebird or MySQL which are not mature enough and do not cover all needs like PostgreSQL does. PostgreSQL Win32 users can account in millions of people, not hundred thousands like today. OK, now, some of us will complain that Win32 is not needed at a time when the Debian Synaptic graphical installer gives access to 13.748 packages. Win32 sounds like an old Atari game station. Agreed. On the long-run, everyone will leave Win32, even my grand-mother. But, on the converse, porting PostgreSQL to Windows today should be considered with care, because Win32 is the last component needed to reach a portfolio effect. [or to make a comparision in the Risk strategy game, when you have all countries in a continent, you win the continent]. Presently, PostgreSQL can be viewed as a large range of products and solutions. But this range only needs the Win32 port to become a complete portfolio. A portfolio effect is reached when you always answer questions with Yes or All. Do you do this or do that? Answer A: yes, we do them All. Answer B: yes, we do them All. Answer C: yes, we do them All. = portfolio effect ... You wake-up and suddenly PostgreSQL becomes the next Office-suite in the domain of databases. This attracks more developers and everyone is happy with business. Cheers, Jean-Michel ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] PG7.4 ordering operator
Testing postgis support in PG7.4 (2003-11-11) I've encountered to this problem: ERROR: could not identify an ordering operator for type geometry HINT: Use an explicit ordering operator or modify the query. Whenever I issue one of these commands: gis=# select the_geom from table1 UNION select the_geom from table2; gis=# select DISTINCT the_geom from table1; gis=# select the_geom from table1 ORDER BY the_geom; Operators '', '', '=' are available: oprname | leftoperand | rightoperand -+-+-- | geometry| geometry | geometry| geometry | geometry| geometry | geometry| geometry | geometry| geometry ~= | geometry| geometry @ | geometry| geometry ~ | geometry| geometry = | geometry| geometry | geometry| geometry | geometry| geometry (11 rows) Previous PG versions does not show this problem. Any hint on what might be missing ? --strk; ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Win32 port
Jean-Michel POURE wrote: OK, now, some of us will complain that Win32 is not needed at a time when the Debian Synaptic graphical installer gives access to 13.748 packages. Win32 sounds like an old Atari game station. Agreed. On the long-run, everyone will leave Win32, even my grand-mother. Well, jokes and rants aside, win32 port is on high priority. The whole debate started on advocacy was 'Whether win32 port is killer-enough feature?' and not 'Whether win32 port is required now?' Win32 will happen. and we will revisit this debate when there is another release with win32..:-) Shridhar ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Is there going to be a port to Solaris 9 x86 in the
Greg == Greg Stark [EMAIL PROTECTED] writes: Greg I think you're talking about situations like where x = ? or Greg y = ? or where x = ? and y = ? Greg When both `x' and `y' are indexed. It's possible to do the Greg index lookup, gather a list of tid pointers in some Greg efficient format like a bit vector, and apply the and/or and Greg any other clauses. Yes, Index ANDing/ORing are useful whether or not the list of tids are in an efficient format. Especially ORing for performing disjunctions. Greg Oracle can do this, and it's useful in some cases when you Greg have DSS-style where all the indexes have poor selectivity Greg but using enough of them together gets you a reasonable Greg number of records. I guess this is the piece where variant indexes is useful - essentially when you have a large number of matches for a given key. I'm not sure how useful it is in practice - I've only read the original research paper. Greg I think this is different from what he meant, but yes, Greg bitmap indexes might be an interesting project. Like hash You're right .. a sorted TLF is really something quite simple that can make quite a difference in accessing a non-clustered index. I believe this is something all the commercial guys do. Sorting the Tids before fetching 'em buys you buffer cache locality. When there are large numbers of hits, it also buys you sequential scans where the file system prefetcher can help. The additional overhead you pay is the sorting cost. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ECPG: EXEC SQL CREATE SCHEMA foo Broken
Hi, please apply patch below to correct the EXEC SQL CREATE SCHEMA
construct in ECPG. Currently (versions 7.3.x, 7.4) the preprocessor
emmits create scheme in error, rather than create schema.
A workaround also exists for those who require it (but I guess no-one
apart from me does since it's went unreported through 7.3), rather
than (checking omitted):
EXEC SQL CREATE SCHEMA foo;
you can use:
EXEC SQL BEGIN DECLARE SECTION;
char l_cmd[50];
EXEC SQL END DECLARE SECTION;
snprintf(l_cmd, sizeof(l_cmd), CREATE SCHEMA foo);
EXEC SQL EXECUTE IMMEDIATE :l_cmd;
Thanks, L.
*** src/interfaces/ecpg/preproc/preproc.y.orig 2003-11-19 10:52:25.0 +
--- src/interfaces/ecpg/preproc/preproc.y 2003-11-19 10:52:30.0 +
***
*** 966,974
*/
CreateSchemaStmt: CREATE SCHEMA UserId OptSchemaName AUTHORIZATION UserId
OptSchemaEltList
! { $$ = cat_str(6, make_str(create scheme), $3, $4,
make_str(authorization), $6, $7); }
| CREATE SCHEMA ColId OptSchemaEltList
! { $$ = cat_str(3, make_str(create scheme), $3, $4); }
;
OptSchemaName: ColId { $$ = $1; }
--- 966,974
*/
CreateSchemaStmt: CREATE SCHEMA UserId OptSchemaName AUTHORIZATION UserId
OptSchemaEltList
! { $$ = cat_str(6, make_str(create schema), $3, $4,
make_str(authorization), $6, $7); }
| CREATE SCHEMA ColId OptSchemaEltList
! { $$ = cat_str(3, make_str(create schema), $3, $4); }
;
OptSchemaName: ColId { $$ = $1; }
---(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] initdb segfaults - latest cvs
Running initdb: creating template1 database in /pgroot-cvs/data/base/1 ... child process was terminated by signal 11 ---(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] Build farm
Peter Eisentraut wrote: Andrew Dunstan writes: If there's general interest I'll try to cook something up. (This kind of stuff is right up my alley). I'd prefer some automated display of results, though. A simple CGI script should be all that's required for that. The real problem will be to find enough machines so that the build farm becomes useful. IMO, that would mean *more* machines than are currently lines in the supported-platforms table. Useful is probably subjective. That list would at least be a good place to start, though. What combinations of variables do you think we would need? This would be a fairly painless way for users to be helpful to the project, btw - the way I am envisioning things this would be fairly much a set and forget process. I'll have an example page available in a few days. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Is there going to be a port to Solaris 9 x86 in the
Robert Treat wrote: On Tue, 2003-11-18 at 17:31, Sailesh Krishnamurthy wrote: One step at a time :-) Actually a big problem is figuring out new pieces for the projects. Most of the items in the TODO list are way too much for a class project - we gave 'em 3 weeks to make the Hash GroupedAgg work for large numbers of unique values (by using a form of hybrid hashing). Another thing I toyed with was having an implementation of a Tid-List-Fetch .. sorting a TID-list from an index and fetching the records of the relation off the sorted list for better IO performance. AFAICT something like this isn't present yet .. can pgsql do this already ? While some form of bitmapped indexing would be cool, other ideas might be to implement different buffer manager strategies. I was impressed by how quickly Jan was able to implement ARC over LRU, but there are a host of other strategies that could also be implemented. Remember that interview with Jim Gray: http://www.acmqueue.org/modules.php?name=Contentpa=showpagepid=43 Certainly we have to convert from random disk access to sequential access patterns. Disks will give you 200 accesses per second, so if you read a few kilobytes in each access, you're in the megabyte-per-second realm, and it will take a year to read a 20-terabyte disk. If you go to sequential access of larger chunks of the disk, you will get 500 times more bandwidthyou can read or write the disk in a day. So programmers have to start thinking of the disk as a sequential device rather than a random access device. Isn't a TID-List-Fetch implementation a crucial first step in the right direction? Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Commercial binary support?
If by up to date you mean 7.4, your probably going to have to wait, but
I believe that Command Prompt, dbExperts, Red Hat, and SRA all have some
type of binary based support available.
Robert Treat
On Tue, 2003-11-18 at 17:19, Austin Gonyou wrote:
I've been looking all over but I can't seem to see a company that is
providing *up-to-date* postgresql support and provides their own
supported binaries. Am I barking up the wrong tree entirely here?
TIA
--
Austin Gonyou [EMAIL PROTECTED]
Coremetrics, Inc.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Release cycle length
Marc G. Fournier wrote: On Tue, 18 Nov 2003, Peter Eisentraut wrote: The time from release 7.3 to release 7.4 was 355 days, an all-time high. We really need to shorten that. We already have a number of significant improvements in 7.5 now, and several good ones coming up in the next few weeks. We cannot let people wait 1 year for that. I suggest that we aim for a 6 month cycle, consisting of approximately 4 months of development and 2 months of cleanup. So the start of the next beta could be the 1st of March. What do you think? That is the usual goal *nod* Same goal we try for each release, and never quite seem to get there ... we'll try 'yet again' with v7.5 though, as we always do :) I don't see much of a point for a shorter release cycle as long as we don't get rid of the initdb requirement for releases that don't change the system catalog structure. All we gain from that is spreading out the number of different versions used in production. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] ECPG: EXEC SQL CREATE SCHEMA foo Broken
On Wed, Nov 19, 2003 at 11:02:59AM +, Lee Kindness wrote: Hi, please apply patch below to correct the EXEC SQL CREATE SCHEMA construct in ECPG. Currently (versions 7.3.x, 7.4) the preprocessor emmits create scheme in error, rather than create schema. Thanks. Applied to HEAD and 7.4. I take it it will make it into 7.4.1 this way. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] Is there going to be a port to Solaris 9 x86 in the
On Tue, 2003-11-18 at 17:31, Sailesh Krishnamurthy wrote:
Mike == Mike Mascari [EMAIL PROTECTED] writes:
Mike How about extra credit for PITR?
One step at a time :-)
Actually a big problem is figuring out new pieces for the
projects. Most of the items in the TODO list are way too much for a
class project - we gave 'em 3 weeks to make the Hash GroupedAgg work
for large numbers of unique values (by using a form of hybrid hashing).
Something like PITR could be interesting, as there is already a patch
that starts the work, the extra credit would be to take the existing
patch and actually make it work.
Another thing I toyed with was having an implementation of a
Tid-List-Fetch .. sorting a TID-list from an index and fetching the
records of the relation off the sorted list for better IO
performance. AFAICT something like this isn't present yet .. can pgsql
do this already ?
While some form of bitmapped indexing would be cool, other ideas might
be to implement different buffer manager strategies. I was impressed by
how quickly Jan was able to implement ARC over LRU, but there are a host
of other strategies that could also be implemented.
I think there are other good projects in there, like allowing indexes
for searching nulls, or adding concurrency to GIST, or allowing non
btree indexes to handle unique's
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Build farm
Andrew Dunstan writes: Useful is probably subjective. That list would at least be a good place to start, though. What combinations of variables do you think we would need? First of all, I don't necessarily think that a large list of CPU/operation system combinations is going to help much. IIRC, this round of platform testing showed us two real problems, and both happened because the operating system version in question came out the previous day, so we could not have caught it. Much more problems arise when people use different versions of secondary packages, such as Tcl, Perl, Kerberos, Flex, Bison. So you would need to compile a large collection of these things. The problem again is that it is usually the brand-new or the odd intermediate version of such a tool that breaks things, so a set and forget build farm is not going to catch it. Another real source of problems are real systems. Weird combinations of packages, weird network setups, weird applications, custom kernels. These cannot be detected on out of the box setups. In fact, the regression tests might not detect them at all. Hence the open-source community approach. Closed-source development teams can do all the above, with great effort. But by throwing out the code and have real people test them on real systems with real applications, you can do much better. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Background writer process
1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if Without grouping WAL writes that does not fly. Iff however such grouping is implemented that should deliver optimal performance. I don't think flushing WAL to the OS early (before a tx commits) is necessary, since writing 8k or 256k to disk with one call takes nearly the same time. The WAL write would need to be done as soon as eighter 256k fill or a txn commits. That means no special treatment to WAL files? If it works, great. There would be single class of files to take care w.r.t sync. issue. Even more simpler. No, WAL needs special handling. Eighter leave it as is with write + f[data]sync, or implement O_SYNC|O_DIRECT with grouping of writes (the current O_SYNC implementation is only good for small (8kb) transactions). Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Is there going to be a port to Solaris 9 x86 in the
Mike == Mike Mascari [EMAIL PROTECTED] writes: Mike Robert Treat wrote: While some form of bitmapped indexing would be cool, other ideas might be to implement different buffer manager strategies. I was impressed by how quickly Jan was able to implement ARC over LRU, but there are a host of other strategies that could also be implemented. We already do that ! We have a first warm-up assignment for which they get 2 weeks and have to change the strategy to MRU from LRU (in an earlier semester they were assigned 2Q). The idea here more to just get used to the code and the debugger. Sadly the undergraduate OS class uses Java (horrors) as an implementation language and many of our juniors and seniors are not as uncomfortable with C programming (and pointers) as I'd like. The good news is that they all pretty much got into the groove fast. Re PITR, maybe that's an option - the thing is we are looking less at a full semester long project and more at a 3/4 week assignment where students get to hack something, learn about the practical side to what's in lecture, and learn to do some performance comparisons. Mike If you go to sequential access of larger chunks of the disk, you will Mike get 500 times more bandwidthyou can read or write the disk in a day. Mike So programmers have to start thinking of the disk as a sequential Mike device rather than a random access device. Mike Isn't a TID-List-Fetch implementation a crucial first step in the Mike right direction? I believe so .. I think it's a clear win. I believe there are some concurrency issues although I'm not sure .. what if there is a vaccuum that comes in between building the Tid list and then doing a fetch ? -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Commercial binary support?
On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] A big thanks to SuSE
On Monday 17 November 2003 05:28 pm, Daniele Orlandi wrote: Yesterday I was a bit worried... I switched to SuSE just 2 weeks ago... my newly installed databse server was waitinI thought that I would have to wait so much to have RPMs for SuSE and today I see v7.4 compiled for many flavors of SuSE, even for X86-64. Wow :) Reinhard Max does good work. SuSE is different enough from Red Hat-style distributions to where my packages historically didn't fit well within their framework, so they have typically done their own thing. Apparently Peter is working with them at this point, which is good for PostgreSQL. And he is getting paid to do it, unlike me. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] initdb segfaults - latest cvs
strk wrote: Running initdb: creating template1 database in /pgroot-cvs/data/base/1 ... child process was terminated by signal 11 It is working fine for me (RH9). Can you provide more details? Platform? How you are calling initdb? cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Commercial binary support?
Robert Treat wrote: If by up to date you mean 7.4, your probably going to have to wait, but I believe that Command Prompt, dbExperts, Red Hat, and SRA all have some type of binary based support available. Don't forget to mention us ... ;). Cheers, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706 or +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ECPG: EXEC SQL CREATE SCHEMA foo Broken
Michael Meskes wrote: On Wed, Nov 19, 2003 at 11:02:59AM +, Lee Kindness wrote: Hi, please apply patch below to correct the EXEC SQL CREATE SCHEMA construct in ECPG. Currently (versions 7.3.x, 7.4) the preprocessor emmits create scheme in error, rather than create schema. Thanks. Applied to HEAD and 7.4. I take it it will make it into 7.4.1 this way. Yes. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Background writer committed
I committed the first part of the background writer process. We had a consensus on attempting to avoid write() calls from regular backends, but did no come to any conclusions what to do to force the kernel to actually do some IO. Consequently, this patch is a separate process launched by postmaster, that periodically write()'s out some dirty buffers in LRU order. This causes the buffers returned for replacement (when a backend needs to read in a page) to be clean allways. The process does no sync(), fsync() or any other calls thus far. Nothing has changed in the checkpoint logic either. The configuration options controlling the process are all PGC_SIGHUP: # - Background writer - #bgwriter_delay = 200 # 10-5000 milliseconds #bgwriter_percent = 1 # 0-100% of dirty buffers #bgwriter_maxpages = 100# 1-1000 buffers max at once Delay is the number of milliseconds to wait between loops. If there was nothing to do at all in one loop (all buffers clean), then the process will sleep for 10 seconds. Percent is the percentage of dirty pages to write per loop. This is independant of the size of the buffer pool. If percent = 0 the postmaster will not start the process at all. Maxpages is an upper bound to prevent the background writer from producing a write storm if a sequential operation causes all pages of a large buffer pool to be dirtied at once. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Build farm
Peter Eisentraut wrote: Andrew Dunstan writes: Useful is probably subjective. That list would at least be a good place to start, though. What combinations of variables do you think we would need? First of all, I don't necessarily think that a large list of CPU/operation system combinations is going to help much. IIRC, this round of platform testing showed us two real problems, and both happened because the operating system version in question came out the previous day, so we could not have caught it. Much more problems arise when people use different versions of secondary packages, such as Tcl, Perl, Kerberos, Flex, Bison. So you would need to compile a large collection of these things. The problem again is that it is usually the brand-new or the odd intermediate version of such a tool that breaks things, so a set and forget build farm is not going to catch it. Another real source of problems are real systems. Weird combinations of packages, weird network setups, weird applications, custom kernels. These cannot be detected on out of the box setups. In fact, the regression tests might not detect them at all. Hence the open-source community approach. Closed-source development teams can do all the above, with great effort. But by throwing out the code and have real people test them on real systems with real applications, you can do much better. The fact that something doesn't find everything doesn't mean it is of no value. (Thinks of Scott Adams' nice example: Your theory of gravity doesn't prove why there are no unicorns, so it is wrong. ;-) ) I don't believe there is a single open source community approach - open source projects all have differing ways of handling problems. At least 2 very significant open source projects I know of run build farms, notwithstanding that your objections should apply equally to them. Mozilla's is fairly centralised and very complex and heavy, but gives fairly immediate feedback if anything gets broken. Samba's is much lighter, distributed, and they still apparently see good value in it. (Samba uses a torture test - perhaps we need one of those in addition to the regression tests.) Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I have an open mind about it. I don't think incompleteness is an argument against it, though. cheers andrew ---(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] Is there going to be a port to Solaris 9 x86 in the
Robert == Robert Treat [EMAIL PROTECTED] writes: Robert allowing indexes for searching nulls, or adding Robert concurrency to GIST, or allowing non btree indexes to Oh this has come up before on -hackers and I've been meaning to chime in. Marcel Kornacker did implement concurrency for GiST - I confirmed as much with Joe Hellerstein (his advisor). I know there's a paper he wrote with C.Mohan on it. I don't know which version his implementation was for. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A big thanks to SuSE
On Wednesday 19 November 2003 12:02 pm, Peter Eisentraut wrote: Lamar Owen writes: And he is getting paid to do it, unlike me. That's news to me. :-) Reinhard Max is getting paid to do it, not you. Bad english on my part. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logical column position
Christopher Kings-Lynne wrote: Will adding the logical attribute number break all of the external tools? pg_dump, etc are all dependent on attnum now? Would it be possible to keep the meaning of attnum the same externally and add another column internally to represent the physical number? Interesting idea. It would require a lot of code renaming in the backend, but it could be done. Given that the interfaces comprise pgadmin, phppgadmin, jdbc and odbc and all the main developers for those lists read all these posts, I think the massive amount of effort to maintain the external interface isn't worth it. I can vouch that it would take me exactly 2 minutes to add support for attlognums in phpPgAdmin. Lesson 1 in SQL for beginners says Don't use SELECT * if you rely on the order of columns. This discussion is about fixing a problem that only inexperienced programmers have. It's like an extra set of wheels on top of your car, just in case you drive wrong way... What's happening if you simply delete a column? Ordering 1,2,3,5? Insert another column of the same name, as a previously deleted, will it get the old position number? And so on. IMHO, way too much effort for working around situations that should be avoided anyway. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A big thanks to SuSE
Lamar Owen writes: And he is getting paid to do it, unlike me. That's news to me. :-) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Commercial binary support?
On Wed, 19 Nov 2003, Michael Meskes wrote: On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. We don't either, nor do we worry about specific platforms ... Marc G. Fournier PostgreSQL, Inc (http://www.pgsql.com) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] unsubscribe
---(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] Background writer committed
TODO updated: * -Use background process to write dirty shared buffers to disk --- Jan Wieck wrote: I committed the first part of the background writer process. We had a consensus on attempting to avoid write() calls from regular backends, but did no come to any conclusions what to do to force the kernel to actually do some IO. Consequently, this patch is a separate process launched by postmaster, that periodically write()'s out some dirty buffers in LRU order. This causes the buffers returned for replacement (when a backend needs to read in a page) to be clean allways. The process does no sync(), fsync() or any other calls thus far. Nothing has changed in the checkpoint logic either. The configuration options controlling the process are all PGC_SIGHUP: # - Background writer - #bgwriter_delay = 200 # 10-5000 milliseconds #bgwriter_percent = 1 # 0-100% of dirty buffers #bgwriter_maxpages = 100# 1-1000 buffers max at once Delay is the number of milliseconds to wait between loops. If there was nothing to do at all in one loop (all buffers clean), then the process will sleep for 10 seconds. Percent is the percentage of dirty pages to write per loop. This is independant of the size of the buffer pool. If percent = 0 the postmaster will not start the process at all. Maxpages is an upper bound to prevent the background writer from producing a write storm if a sequential operation causes all pages of a large buffer pool to be dirtied at once. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 8: explain analyze is your friend
Re: [HACKERS] logical column position
Andreas, The point of this is to maintain the column position. I don't think that an alter of a column type should move the column position. It may be that programmers should not rely on this, but it happens, and in very large projects. If we can avoid unexpected side-affects like moving the columns position, then I think we should. Dave On Wed, 2003-11-19 at 12:30, Andreas Pflug wrote: Christopher Kings-Lynne wrote: Will adding the logical attribute number break all of the external tools? pg_dump, etc are all dependent on attnum now? Would it be possible to keep the meaning of attnum the same externally and add another column internally to represent the physical number? Interesting idea. It would require a lot of code renaming in the backend, but it could be done. Given that the interfaces comprise pgadmin, phppgadmin, jdbc and odbc and all the main developers for those lists read all these posts, I think the massive amount of effort to maintain the external interface isn't worth it. I can vouch that it would take me exactly 2 minutes to add support for attlognums in phpPgAdmin. Lesson 1 in SQL for beginners says Don't use SELECT * if you rely on the order of columns. This discussion is about fixing a problem that only inexperienced programmers have. It's like an extra set of wheels on top of your car, just in case you drive wrong way... What's happening if you simply delete a column? Ordering 1,2,3,5? Insert another column of the same name, as a previously deleted, will it get the old position number? And so on. IMHO, way too much effort for working around situations that should be avoided anyway. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] A big thanks to SuSE
Lamar Owen wrote: On Wednesday 19 November 2003 12:02 pm, Peter Eisentraut wrote: Lamar Owen writes: And he is getting paid to do it, unlike me. That's news to me. :-) Reinhard Max is getting paid to do it, not you. Bad english on my part. As I remember, Peter's company, Credativ, is a big Debian house. -- 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 8: explain analyze is your friend
Re: [HACKERS] initdb segfaults - latest cvs
andrew wrote: Ok, seriously weird. This is apparently from the pg_type relation and looks just fine on my installation. Have you tried make distclean; cvs update; configure; make check ? Tried now: 4 of 93 tests failed. .. initdb does not fault though ;) It seems that the build system is missing something (make distclean made it work) Thanks for you support --strk; ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] logical column position
Dave Cramer wrote: Andreas, The point of this is to maintain the column position. I don't think that an alter of a column type should move the column position. Why should ALTER COLUMN change the column number, i.e. position? It may be that programmers should not rely on this, but it happens, and in very large projects. If we can avoid unexpected side-affects like moving the columns position, then I think we should. This is *expected* if behaviour if you delete and add columns; is there any DB system out there that allows to reshuffle the column ordering? Instead of some order-ordering facility it would be better to support all kinds of column type changes, not only binary compatible ones. This would help everybody, not only maintainers of ill-designed software. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logical column position
Andreas, On Wed, 2003-11-19 at 13:07, Andreas Pflug wrote: Dave Cramer wrote: Andreas, The point of this is to maintain the column position. I don't think that an alter of a column type should move the column position. Why should ALTER COLUMN change the column number, i.e. position? Rod's current proposed patch does that if you do an alter column alter type. This is an artifact of the underlying mechanism. (ren old col, add new col, update newcol=oldcol::newtype). Which is the point of the logical column number discussion, and the todo item. It may be that programmers should not rely on this, but it happens, and in very large projects. If we can avoid unexpected side-affects like moving the columns position, then I think we should. This is *expected* if behaviour if you delete and add columns; is there any DB system out there that allows to reshuffle the column ordering? Yes, informix allows you to add the column before|after a column, and mysql allows for add column after col. those are the only two I know about.there could be more. Instead of some order-ordering facility it would be better to support all kinds of column type changes, not only binary compatible ones. This would help everybody, not only maintainers of ill-designed software. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Build farm
Andrew Dunstan writes: Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I have an open mind about it. I don't think incompleteness is an argument against it, though. If you want to do it, by all means go for it. I'm sure it would give everyone a fuzzy feeling to see the green lights everywhere. But realistically, don't expect any significant practical benefits, such cutting beta time by 10%. The Samba build daemon suite is pretty good. We have a couple of those hosts in our office in fact. (I think they're building PostgreSQL regularly as well.) A tip: You might find that adopting the source code of the Samba suite to PostgreSQL is harder than writing a new one. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] logical column position
Dave Cramer wrote: Andreas, On Wed, 2003-11-19 at 13:07, Andreas Pflug wrote: Dave Cramer wrote: Andreas, The point of this is to maintain the column position. I don't think that an alter of a column type should move the column position. Why should ALTER COLUMN change the column number, i.e. position? Rod's current proposed patch does that if you do an alter column alter type. This is an artifact of the underlying mechanism. (ren old col, add new col, update newcol=oldcol::newtype). I must have missed that, can't find it in hackers?!? In this case the old attnum value should simply be reused, to retain the original ordering. IMHO this is necessary to prevent problems with any object referencing a column (index, view, ...) The current proposal invents the attpos for column ordering purpose only, but views/indexes/etc will reference attnum, and would need updates. Actually, a column that changes its attnum is just like a table changing its oid, i.e. it's not the same object any more. This will provoke problems in administration tools (at least in pgAdmin3, which will try to refresh its display with the formerly known oid/attnum af ter executing a change), and maybe other places too. To put it differently: a ALTER COLUMN command may never-ever change the identifier of the column, i.e. attrelid/attnum. Regards, Andreas ---(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] Commercial binary support?
On Wed, 2003-11-19 at 11:31, Marc G. Fournier wrote: On Wed, 19 Nov 2003, Michael Meskes wrote: On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. We don't either, nor do we worry about specific platforms ... I agree. We shouldn't have to really care, so long as there are guidelines for which platforms/distributions/sources are supported. Thus, the binaries provided == all of that combined. I think that the aforementioned requirements is easier, and more intelligent to require of a support organization, but our dev guys were complaining a bit and sought this as a resolution to their complaints. I don't see it being entirely feasible, but we'll see. Marc G. Fournier PostgreSQL, Inc (http://www.pgsql.com) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Austin Gonyou [EMAIL PROTECTED] Coremetrics, Inc. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Commercial binary support?
Marc G. Fournier wrote: On Wed, 19 Nov 2003, Michael Meskes wrote: On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. We don't either, nor do we worry about specific platforms ... And I know CommandPrompt doesn't care either. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Commercial binary support?
On Wed, 19 Nov 2003, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 19 Nov 2003, Michael Meskes wrote: On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. We don't either, nor do we worry about specific platforms ... And I know CommandPrompt doesn't care either. I don't even know what it means. If I were to build the 7.4 source, install it somewhere, tarball it up would that then count as providing our own supported binaries (assuming the support service is also offered of course)? Surely it's fairly common for someone to sell support and be happy to include the service of supplying the binaries so if requested, what's so special about it? Nigel Andrews ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Reentrant Locale API
Where have you found this? I've been looking for that but have not found it. I run a rh9 system, do you have something newer? Maybe I have just not looked in the right place in the documentation. Glibc 2.3 implements both reentrant and a thread local locale APIs. The reentrant API provides versions of isalpha, isupper, toupper, strcoll, and so on that take a separate locale parameter. The thread locale API is simpler - it adds new a uselocale() function, that once called places a thread in its own thread specific local, after which all locale dependent functions use the thread locale instead of the global one (which is the default for backward compatibility). See this paper for details: http://people.redhat.com/drepper/lt2002talk.pdf ---(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] Is there going to be a port to Solaris 9 x86 in the
On Wed, 2003-11-19 at 12:16, Sailesh Krishnamurthy wrote:
Robert == Robert Treat [EMAIL PROTECTED] writes:
Robert allowing indexes for searching nulls, or adding
Robert concurrency to GIST, or allowing non btree indexes to
Oh this has come up before on -hackers and I've been meaning to chime
in.
Marcel Kornacker did implement concurrency for GiST - I confirmed as
much with Joe Hellerstein (his advisor). I know there's a paper he
wrote with C.Mohan on it. I don't know which version his
implementation was for.
I did a bit of googleing and came up with the following papers:
http://www.eecs.berkeley.edu/IPRO/Summary/97abstracts/marcel.1.html
but the only references I saw to implementation were in something called
amdb. If he did code it for postgresql, even an old version, having that
code/info available (if even as a link from the TODO) might be enough to
inspire someone to implement it in the current sources.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Build farm
Peter Eisentraut wrote: The Samba build daemon suite is pretty good. We have a couple of those hosts in our office in fact. (I think they're building PostgreSQL regularly as well.) A tip: You might find that adopting the source code of the Samba suite to PostgreSQL is harder than writing a new one. Yes, I agree. I have looked at it for ideas, but not for code. I'm not using rsync or anything like that, for instance. I'm going for something very simple to start with. Essentially what I have is something like this pseudocode: cvs update check if there really was an update and if not exit configure; get config.log make 21 | make-filter makelog make check 21 | check-filter checklog (TBD) send config status, make status, check status, logfiles make distclean The send piece will probably be a perl script using LWP and talking to a CGI script. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Least interesting to many user perhaps, but lost of them seen to think that it's important for expanding our userbase: http://www.postgresql.org/survey.php?View=1SurveyID=9 That does not say that better entertainment will attract new viewers, just that the existing viewers think that. Perhaps more compelling is this survey, which shows that 21% of the users are on actually the win32/cygwin platform now hence are not enjoying the performance or ease of installation that the other 79% of us get. http://www.postgresql.org/survey.php?View=1SurveyID=11 -Nick ---(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] question about fixes in v7.4...
My company is fairly new at Postgresql, but we have hit a problem, where we modify a table using ALTER, and our stored procedures stop working. We have a grasp as to why this happens, but I was wondering if this v7.4 upgrade fixes this issue? Don Sceifers Harvest Info attachment: winmail.dat ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Win32 Port WAS: Not 7.5, but 8.0 ?
Hi You probably aren't faced with this issue as much in Germany, but it happens often to us folks in the US Canada. About half of the mails that I get are Cygwin-Windows related. So I consider it of great interest in Germany. Regards Conni ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
On Tue, Nov 18, 2003 at 12:18:51PM -0500, Andrew Sullivan wrote: On Tue, Nov 18, 2003 at 08:39:29AM -0800, ow wrote: Have *never* seen ppl running Oracle or Sybase on Windows. I _have_ certainly seen plenty of people running Oracle on Windows. They weren't necessarily happy, of course, but people do it all the time. As for Sybase, you don't see that because Sybase on Windows was, for a long time, SQL Server. Not exaclty. Sybase 4.21 = MS SQL server 4.21. But then they ended their relationship (much like MS and IBM did over OS/2). This was somewhere around the mid 90's. Since then Sybase has renamed their enterprise product to Adaptive Server Enterprise, and versions 10, 11, 11.5 and beyond have always been available on windows. A few years after they split up with Microsoft, they bought the product SQL Anywhere (forgot the firm they bought it from). It took them a few years to make this product 100% SQL compatible with ASE. This product was ported to some Unix platforms around that time too. -- __ Nothing is as subjective as reality Reinoud van Leeuwen[EMAIL PROTECTED] http://www.xs4all.nl/~reinoud __ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] What's the difference between int2 and int16?
I found the uses of int2, int16 and other similiar types misleading in PostgreSQL's source code. Sometime it is difficult to figure out which should be prefered. Maybe int2, int4, and int8 refer to database types, while int16, int32 and int64 refer to C data types. If this is the convention, maintenance may be easier. ---(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] 4 Clause license?
On Mon, 17 Nov 2003 14:48:08 -0500 Rod Taylor [EMAIL PROTECTED] wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 This appears to be an original UCB Copyright notice. From /usr/src/COPYRIGHT: NOTE: The copyright of UC Berkeley's Berkeley Software Distribution (BSD) source has been updated. The copyright addendum may be found at ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is included below. July 22, 1999 To All Licensees, Distributors of Any Version of BSD: As you know, certain of the Berkeley Software Distribution (BSD) source code files require that further distributions of products containing all or portions of the software, acknowledge within their advertising materials that such products contain software developed by UC Berkeley and its contributors. Specifically, the provision reads: * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *This product includes software developed by the University of *California, Berkeley and its contributors. Effective immediately, licensees and distributors are no longer required to include the acknowledgement within advertising materials. Accordingly, the foregoing paragraph of those BSD Unix files containing it is hereby deleted in its entirety. William Hoskins Director, Office of Technology Licensing University of California, Berkeley -- Alexander Kabaev ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 4 Clause license?
On Mon, Nov 17, 2003 at 02:48:08PM -0500, Rod Taylor wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 Is this intentionally under the 4 clause license or does the copyright from the website (2 clause) applied to everything that is non-contrib? http://www.freebsd.org/copyright/freebsd-license.html That copyright notice on the website should apply to everything that is not under some other license. Different parts of the system is under different licenses and copyrights depending on who wrote it. The mkdir.c *was* under the 4 clause license. However all material that was part of the original BSDs and thus was copyrighted by The Regents of the University of California has had its license changed such that clause 3 (the advertising clause) no longer apply. This would seem to include mkdir.c Most of the files in the source tree have not had their copyright notices updated to reflect this. See http://www.freebsd.org/copyright/license.html for details on this license. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ---(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] question about fixes in v7.4...
On Wed, 2003-11-19 at 11:17, Don Sceifers wrote: My company is fairly new at Postgresql, but we have hit a problem, where we modify a table using ALTER, and our stored procedures stop working. We have a grasp as to why this happens, but I was wondering if this v7.4 upgrade fixes this issue? At this time function bodies do not have the dependency tracking capabilities that a majority of the system has, so it is unable to complain when you remove or alter an object it depends on. With SQL functions it should be feasible. For functions that build queries on the fly this will be virtually impossible. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Commercial binary support?
Nigel J. Andrews wrote: On Wed, 19 Nov 2003, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 19 Nov 2003, Michael Meskes wrote: On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. We don't either, nor do we worry about specific platforms ... And I know CommandPrompt doesn't care either. I don't even know what it means. If I were to build the 7.4 source, install it somewhere, tarball it up would that then count as providing our own supported binaries (assuming the support service is also offered of course)? Surely it's fairly common for someone to sell support and be happy to include the service of supplying the binaries so if requested, what's so special about it? Nigel Andrews Nigel, The name of the game is warranty. PostgreSQL is BSD license and therefore there is no warranty. A good support company will pick up the risk and fix bugs, backport bugs and features, and provide improved tarballs. There is nothing special - it's just a service. However, it is a service which is necessary because larger companies have to be sure that things are working properly. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706 or +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Commercial binary support?
Hello, I think what the person is looking for is: COMPANY PostgreSQL for Red Hat Enterprise 3.0. They probably have some commercial mandate that says that they have to have a commercial company backing the product itself. This doesn't work for most PostgreSQL companies because they back the Open Source version of PostgreSQL. Where someone like Command Prompt, although we happily support the Open Source version, we also sell Command Prompt PostgreSQL. It is purely a business thing, liability and the like. Sincerely, Joshua Drake Nigel J. Andrews wrote: On Wed, 19 Nov 2003, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 19 Nov 2003, Michael Meskes wrote: On Tue, Nov 18, 2003 at 04:19:35PM -0600, Austin Gonyou wrote: I've been looking all over but I can't seem to see a company that is providing *up-to-date* postgresql support and provides their own supported binaries. Am I barking up the wrong tree entirely here? Why do you insist on their own binaries? I think there are several companies out there providing support for a given version of PostgreSQL and doubt they all ask for their own binaries. At least we do not. We don't either, nor do we worry about specific platforms ... And I know CommandPrompt doesn't care either. I don't even know what it means. If I were to build the 7.4 source, install it somewhere, tarball it up would that then count as providing our own supported binaries (assuming the support service is also offered of course)? Surely it's fairly common for someone to sell support and be happy to include the service of supplying the binaries so if requested, what's so special about it? Nigel Andrews ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Is there going to be a port to Solaris 9 x86 in the
On Wed, 2003-11-19 at 10:47, Sailesh Krishnamurthy wrote:
Mike == Mike Mascari [EMAIL PROTECTED] writes:
Mike Robert Treat wrote:
While some form of bitmapped indexing would be cool, other ideas might
be to implement different buffer manager strategies. I was impressed by
how quickly Jan was able to implement ARC over LRU, but there are a host
of other strategies that could also be implemented.
We already do that !
:-)
We have a first warm-up assignment for which they get 2 weeks and
have to change the strategy to MRU from LRU (in an earlier semester
they were assigned 2Q). The idea here more to just get used to the
code and the debugger.
It would be cool if some of these were posted to -patches... *in theory*
it would give folks a chance to do real stress testing on different
implementations. if nothing else we could bug Jan some more about making
the buffer management code configurable ;-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Commercial binary support?
Hello Tell me if I am significantly wrong but Command Prompt PostgreSQL is nothing more than Open Source PostgreSQL including some application server stuff, some propriertary PL/Perl || PL/PHP and not much more. Ahh no. First our PL/Perl and PL/PHP is not propiertary in any way. It is open source, you are free to download it and use it at your leisure. Second we have better SSL support (although this is fixed in the current cvs for 7.3 series) Third we have compression over the connection stream for more efficient connectivity over congested networks. Also: Included graphical management tools (also now open source, pgManage) Modified shared memory management for better performance A policy of a minimum of 2005 before we won't support PostgreSQL. 24 hour / 7 day support with a history of performance for the customer. Oh... and: Native, built in as part of the database replication. Can you tell me a reason why somebody should use a closed source version of an Open Source product unless it contains some really significant improvement (say native Win32 or something like that)? See above. Can you tell me ONE reason why this does not work for other PostgreSQL companies such as `eval LONG LIST`? Personally I think everybody can have its business strategy but what REALLY sets me up is that this mail seems to mean that Command Prompt is the only support company around which is actually WRONG! No... not at all, nor was that my intent. There are many good PostgreSQL support companies. PgSQL, Inc. and Aglios come to mind. I was just trying to provide an example of what that particular company might be looking for. I wasn't even saying that we were the right company for them. I was just saying what I thought they were looking for. In my opinion everybody who has enough skills can do this kind of job. Being a support company has nothing to do with making a good Open Source product a closed source product. In my opinion giving something a new name and hiding away some code does not mean commercial backing and it does not mean being the god of all support companies. What in the world brought this on? I wasn't suggesting any of this. I was just trying to help clarify the guys statement. He couldn't have been talking about Red Hat for all I care. Sincerely, Joshua D. Drake Regards, Hans -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] RPM building fun
Kind people, Is there some magic I can use to keep the following from happening in the when I build from the .spec file? I'm starting with the Postgresql 7.3.4 spec file, version bumped, patches removed. configure: error: unrecognized option: --infodir=/usr/share/info Is there some way to remove this piece of sh^H^Hlegacy from the configure script? Does anybody actually use info? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Commercial binary support?
All, I sincerely apologize for possibly starting a flame war, I wasn't aware this might be a hot-button issue. Hopefully some good will come of it none-the-less, like others who come after me might see the reasons our db application developers want this type of go to support. I would also sincerely like to thank all who've responded as this has given a lot of insight, I think, for all of us involved thus far. It's good to have different perspectives, even if we don't all agree all the time. Thanks again. -- Austin Gonyou [EMAIL PROTECTED] Coremetrics, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] RPM building fun
Is there some way to remove this piece of sh^H^Hlegacy from the configure script? Does anybody actually use info? All of GNU. Cheers, D -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] logical column position
Andreas Pflug kirjutas K, 19.11.2003 kell 20:45: Dave Cramer wrote: Why should ALTER COLUMN change the column number, i.e. position? Rod's current proposed patch does that if you do an alter column alter type. This is an artifact of the underlying mechanism. (ren old col, add new col, update newcol=oldcol::newtype). I must have missed that, can't find it in hackers?!? Was on [PATCHES] IIRC. In this case the old attnum value should simply be reused, to retain the original ordering. IMHO this is necessary to prevent problems with any object referencing a column (index, view, ...) Actually these have to be recreaqted, especially when changing column type. Rod's patchs does that too ;) The current proposal invents the attpos for column ordering purpose only, That's the only place _user_ sees it. The other uses are taken care of inide database backend. but views/indexes/etc will reference attnum, and would need updates. they also reference column type, and thus need to be updated anyway when column type changes. Actually, a column that changes its attnum is just like a table changing its oid, i.e. it's not the same object any more. This will provoke problems in administration tools (at least in pgAdmin3, which will try to refresh its display with the formerly known oid/attnum af ter executing a change), and maybe other places too. Sure. _any_ change to database structure could break a client not (designed to be) aware of that change. To put it differently: a ALTER COLUMN command may never-ever change the identifier of the column, i.e. attrelid/attnum. to be even more restirictive: ALTER COLUMN may never-ever change the type of the column, as this too may break some apps. Nah! - Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Commercial binary support?
I don't think *we* thought it was a hot button issue.. at least I
certainly didn't when I initially responded. There is no need for you to
apologize, in fact, I'll apologize for the list, we sometimes get a
little heated on -hackers. Hopefully you've not been to startled by this
outburst :-)
Robert Treat
On Wed, 2003-11-19 at 17:17, Austin Gonyou wrote:
All,
I sincerely apologize for possibly starting a flame war, I wasn't aware
this might be a hot-button issue. Hopefully some good will come of it
none-the-less, like others who come after me might see the reasons our
db application developers want this type of go to support.
I would also sincerely like to thank all who've responded as this has
given a lot of insight, I think, for all of us involved thus far. It's
good to have different perspectives, even if we don't all agree all the
time. Thanks again.
--
Austin Gonyou [EMAIL PROTECTED]
Coremetrics, Inc.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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
[HACKERS] ALTER COLUMN/logical column position
Hannu Krosing wrote: To put it differently: a ALTER COLUMN command may never-ever change the identifier of the column, i.e. attrelid/attnum. to be even more restirictive: ALTER COLUMN may never-ever change the type of the column, as this too may break some apps. Nah! Yeah, and the data should be read only :-) Seriously: Methinks that only a part of the -patches thread was turned over to -hackers, some important parts are missing. First, there are column type changes that don't need any index/view/constraint recheck or data transformation at all, being of the very popular class hell, I need to stuff 12 bytes in my varchar(10). Some months ago, this was discussed, and there was consense that binarily compatible types may be changed with few special precautions (e.g. varchar(12) - varchar(10) e.g. needs a check for len=10). As a consequence, this kind of column type change is implemented in pgAdmin3. Probably a large percentage of real life column type changes are such binarily compatible ones, so it's senseful to handle them separately. Second, column type changes needing a nontrivial cast function should be implemented in a way that preserve attnum. This could be done like this: - decompile dependent objects, and memorize them for later recreation - ADD tmpCol, UPDATE tmpCol=col::newtype, DROP old column, cascading to dependent objects, RENAME tmpCol (known stuff) - restore old attnum, which is a simple UPDATE to pg_attribute at this stage - recreate all dependent objects Voila! No need for an additional attpos. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Build farm
Andrew Dunstan writes: Essentially what I have is something like this pseudocode: cvs update Be sure check past branches as well. check if there really was an update and if not exit OK. configure; get config.log Ideally, you'd try all possible option combinations for configure. Or at least enable everything. make 21 | make-filter makelog make check 21 | check-filter checklog You could also try out make distcheck. It tries out the complete build, installation, uninstallation, regression test, and distribution building. (TBD) send config status, make status, check status, logfiles OK. make distclean When I played around with this, always copied the CVS tree to a new directory and deleted that one at the end. That way, bugs in the clean procedure (known to happen) don't trip up the whole process. The send piece will probably be a perl script using LWP and talking to a CGI script. That will be the difficult part to organize, if it's supposed to be distributed and autonomous. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Is there going to be a port to Solaris 9 x86 in the
Marcel Kornacker did implement concurrency for GiST - I confirmed as much with Joe Hellerstein (his advisor). I know there's a paper he wrote with C.Mohan on it. I don't know which version his implementation was for. The 7.4 GiST docs have a link to Kornacker's thesis that details how to implement concurrent GiST and unique GiST: http://citeseer.nj.nec.com/448594.html I have been reading it, but I think my skills aren't really sufficient to implement it :P Chris ---(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] logical column position
Why should ALTER COLUMN change the column number, i.e. position? Because it creates a NEW column. It may be that programmers should not rely on this, but it happens, and in very large projects. If we can avoid unexpected side-affects like moving the columns position, then I think we should. This is *expected* if behaviour if you delete and add columns; is there any DB system out there that allows to reshuffle the column ordering? MySQL Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [PERFORM] More detail on settings for pgavd?
Josh Berkus wrote: Shridhar, I was looking at the -V/-v and -A/-a settings in pgavd, and really don't understand how the calculation works. According to the readme, if I set -v to 1000 and -V to 2 (the defaults) for a table with 10,000 rows, pgavd would only vacuum after 21,000 rows had been updated. This seems wrong. No. that is correct. It is calculated as threshold = base + scale*numebr of current rows Which translates to 21,000 = 1000 + 2*1000 However I do not agree with this logic entirely. It pegs the next vacuum w.r.t current table size which is not always a good thing. I would rather vacuum the table at 2000 updates, which is what you probably want. Furthermore analyze threshold depends upon inserts+updates. I think it should also depends upon deletes for obvious reasons. Can you clear this up a little? I'd like to tweak these settings but can't without being better aquainted with the calculation. What did you expected in above example? It is not difficult to tweak pg_autovacuum calculations. For testing we can play around. Also, you may want to reverse your default ratio for Vacuum/analyze frequency. True, analyze is a less expensive operation than Vacuum, but it's also needed less often -- only when the *distribution* of data changes.I've seen databases where the optimal vacuum/analyze frequency was every 10 min/once per day. OK vacuum and analyze thresholds are calculated with same formula as shown above but with different parameters as follows. vacthresh = vacbase + vacscale*ntuples anathresh = anabase + anascale*ntuples What you are asking for is vacthresh = vacbase*vacscale anathresh = anabase + anascale*ntuples Would that tilt the favour the way you want? i.e. an analyze is triggered when a fixed *percentage* of table changes but a vacuum is triggered when a fixed *number of rows* are changed. I am all for experimentation. If you have real life data to play with, I can give you some patches to play around. And BTW, this is all brain child of Mathew O.Connor(Correct? I am not good at either names or spellings). The way I wrote pgavd originally, each table got to get separate threshold..:-). That was rather a brute force approach. Shridhar ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PERFORM] More detail on settings for pgavd?
Shridhar, However I do not agree with this logic entirely. It pegs the next vacuum w.r.t current table size which is not always a good thing. No, I think the logic's fine, it's the numbers which are wrong. We want to vacuum when updates reach between 5% and 15% of total rows. NOT when updates reach 110% of total rows ... that's much too late. Hmmm ... I also think the threshold level needs to be lowered; I guess the purpose was to prevent continuous re-vacuuuming of small tables? Unfortunately, in the current implementation, the result is tha small tables never get vacuumed at all. So for defaults, I would peg -V at 0.1 and -v at 100, so our default calculation for a table with 10,000 rows is: 100 + ( 0.1 * 10,000 ) = 1100 rows. I would rather vacuum the table at 2000 updates, which is what you probably want. Not necessarily. This would be painful if the table has 10,000,000 rows. It *should* be based on a % of rows. Furthermore analyze threshold depends upon inserts+updates. I think it should also depends upon deletes for obvious reasons. Yes. Vacuum threshold is counting deletes, I hope? What did you expected in above example? It is not difficult to tweak pg_autovacuum calculations. For testing we can play around. Can I set the settings to decimals, or are they integers? vacthresh = vacbase*vacscale anathresh = anabase + anascale*ntuples Nope, see above. My comment about the frequency of vacuums vs. analyze is that currently the *default* is to analyze twice as often as you vacuum.Based on my experiece as a PG admin on a variety of databases, I believe that the default should be to analyze half as often as you vacuum. I am all for experimentation. If you have real life data to play with, I can give you some patches to play around. I will have real data very soon . -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] question about fixes in v7.4...
Don Sceifers wrote: My company is fairly new at Postgresql, but we have hit a problem, where we modify a table using ALTER, and our stored procedures stop working. We have a grasp as to why this happens, but I was wondering if this v7.4 upgrade fixes this issue? This is a known issue. There is no way for us to know what stored tables/columns you are using in your function. You might find that reconnecting to the database after the ALTER will fix the problem. We do cache function code, so reconnecting will erase that cache. If still have problems, please report the ALTER command and function that is causing the problem. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] commenting on polymorphic aggregates possible?
Christopher Kings-Lynne [EMAIL PROTECTED] writes: COMMENT ON AGGREGATE newcnt (any) IS 'an any agg comment'; ERROR: syntax error at or near any at character 30 ANY is a reserved word. To reference the pseudotype named any, you need quotes: COMMENT ON AGGREGATE newcnt (any) IS 'an any agg comment'; No doubt it would've been better to use a different name for the pseudotype, but I think the behavior of CREATE AGGREGATE's basetype = 'any' was chosen long before there was any thought of making Postgres SQL-compliant :-( 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: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Josh Berkus [EMAIL PROTECTED] writes: Peter wrote: Also note that most major number changes in the past weren't because the features were cool, but because the project has moved to a new phase. I don't see any such move happening. Now that is interesting. I missed that. Can you explain how that worked with 7.0? Personally I thought that the 6.5-7.0 jump was a mistake ... but that's water over the dam now. I would be willing to call a PG release 8.0 when it has built-in replication support --- that would be the sort of major-league functionality jump that would justify a top-number bump. There are not that many other plausible reasons for a top-number bump that I can think of right now. PG is really getting to be a pretty mature product, and ISTM that should be reflected in a disinclination to call it all new. You can be dead certain that a Windows port will not be sufficient reason to call it 8.0. Perhaps 6.6.6 would the right starting version number for that one ;-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PG7.4 ordering operator
strk [EMAIL PROTECTED] writes: Testing postgis support in PG7.4 (2003-11-11) I've encountered to this problem: ERROR: could not identify an ordering operator for type geometry Previous PG versions does not show this problem. Any hint on what might be missing ? A default btree operator class for type geometry. PG 7.4 no longer uses assumptions about operator names to determine sorting/grouping behavior. If you have some operators that provide a scalar sort ordering on your datatype, then make a btree opclass to show that. See http://www.postgresql.org/docs/7.4/static/xindex.html#XINDEX-OPCLASS-DEPENDENCIES regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] RPM building fun
Joshua D. Drake wrote: Is there some way to remove this piece of sh^H^Hlegacy from the configure script? Does anybody actually use info? All of GNU. Additionally it is very good resource when you use Konqueror to browse it as html.. Shridhar ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Background writer committed
Jan Wieck wrote: I committed the first part of the background writer process. We had a consensus on attempting to avoid write() calls from regular backends, but did no come to any conclusions what to do to force the kernel to actually do some IO. Consequently, this patch is a separate process launched by postmaster, that periodically write()'s out some dirty buffers in LRU order. This causes the buffers returned for replacement (when a backend needs to read in a page) to be clean allways. The process does no sync(), fsync() or any other calls thus far. Nothing has changed in the checkpoint logic either. Can we have some idea where to tweak sync routines for comparing results? I mean I would like to run pgbench with same config all along and compare the performance difference between sync, fsync and fdatasync etc. If we could get to run any live world data test by that, it would be great as well. Shridhar ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] with(isstrict) vs ISSTRICT
Does with(isStrict) still work ? If not when did postgres drop its support ? TIA --strk; ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
