Re: [HACKERS] Two weeks to feature freeze
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2003 11:47 PM > To: Dann Corbit > Cc: Jason Earl; PostgreSQL-development > Subject: Re: [HACKERS] Two weeks to feature freeze > > > "Dann Corbit" <[EMAIL PROTECTED]> writes: > > Look at this: > > > http://www.mysql.com/information/crash-me.php?mysql_4_1=on&postgres=on > > This looks a little cleaner than the last time I looked at it > (more than three years ago), but it's still fundamentally a > marketing effort. It is not an exercise in spec compliance > measurement, because there are hundreds of bullet points that > all look exactly alike, whether they are measuring > spec-required elements, random vendor extensions to the spec, > or spec violations. To take just one example of the latter, > "Calculate 1--1" is still shown with a green star for MySQL > and a failure for Postgres, when a more correct reading would > be "Fails to recognize SQL-standard -- comment syntax" for > MySQL. And yes, they were called out on this three years > ago, and no they haven't fixed the entry since then. I > should believe that there is any good faith on their part? > > For another example, take a close look at the "Quoting" > section, which purports to measure compliance to the spec's > ideas about how to quote an identifier. Postgres accepts > double-quoted identifiers per spec, including doubled double > quotes per spec, and rejects bracketed or backquoted > identifiers per spec. MySQL is apparently spec compliant on > just one of those four points. Curious that they manage to > end up with a better looking display than us in this section; > in particular note that Postgres is specifically claimed > *not* to handle double-quoted identifiers. (Memory is fuzzy > after three years, but IIRC when you look at the actual test > code being used, it tests more than whether double quoted > identifiers are allowed, and really is failing us on some > quite unrelated detail.) > > Another point worth mentioning is that most of the numerical > limits shown in the table have nothing to do with actual > server limits, but with random limitations of their test > process. For instance, I'm not sure what "max index part > length 235328" really means, but I am pretty sure it's got > nothing to do with the Postgres server. Or look at "constant > string size in SELECT 16777207" ... nope, there's no such > limit. (If they'd put a "+" in there then it'd be okay, but > no.) I still remember watching crash-me trying to measure the > max query length of Postgres 7.0: the crashme client process > dumped core before Postgres did, after which the controlling > script announced that we weren't crash-safe. > > > So far, I have seen three problems pointed out (out of 600+ tests). > > These are the high spots from three-year-old memories. Do > you really want a detailed analysis? A quick look at their > table recalls plenty of bogosity to my mind. > > A last point is that this table is comparing MySQL 4.1 > (bleeding edge alpha release) against PG 7.2 (one full major > release behind the times). While I cannot really blame the > MySQL guys for not being up-to-the- minute on everyone else's > releases, this does emphasize the key point, namely that this > isn't a fair comparison run by disinterested parties but a > marketing effort of, by, and for MySQL. It seems pretty clear that there are warts on the Crashme test. Perhaps 70% or so is truly useful. Maybe the useful subset could be approximated or modified to be useful as a general tool set. Not too surprising that a commercial enterprise tries to bend the facts in their favor a bit. Some other stuff worth note: http://osdb.sourceforge.net/ http://sourceforge.net/projects/osdldbt (looks like someone has put a bunch of PostgreSQL effort into it. http://sourceforge.net/projects/ltp/ (DOTS) http://www.mysql.com/portal/software/item-222.html (I won't mention where it's from) ftp://ftp.cs.wisc.edu/OO7/ Win32 specific, but has source code: http://www.mipt.sw.ru/en/install/ots/ (ODBC testing) http://www.mipt.sw.ru/en/install/ats/ (ADO testing) Some other interesting stuff is found there too... Test tools links: http://www.softwareqatest.com/qattls1.html http://www.aptest.com/resources.html ---(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] compile failure on cvs tip --with-krb5
On Fri, Jun 20, 2003 at 07:48:02PM -0700, Joe Conway wrote:
> This change (I'm sure this will wrap poorly -- sorry):
> http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85&r2=1.86
>
> modified SockAddr, but no corresponding change was made here
> (fe-auth.c:612):
>
> case AUTH_REQ_KRB5:
> #ifdef KRB5
> if (pg_krb5_sendauth(PQerrormsg, conn->sock, &conn->laddr.in,
>&conn->raddr.in,
>hostname) != STATUS_OK)
>
> It's not obvious to me what the change ought to be though.
Please try the attached patch.
I'll try to change kerberos 4 later if I can find some
documentation about it. Especially the krb_sendauth() function.
Does Kerberos 4 support other protocols than ipv4?
Kurt
Index: ./src/interfaces/libpq/fe-auth.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-auth.c,v
retrieving revision 1.80
diff -u -r1.80 fe-auth.c
--- ./src/interfaces/libpq/fe-auth.c14 Jun 2003 17:49:53 - 1.80
+++ ./src/interfaces/libpq/fe-auth.c21 Jun 2003 10:45:53 -
@@ -357,10 +357,7 @@
*the server
*/
static int
-pg_krb5_sendauth(char *PQerrormsg, int sock,
-struct sockaddr_in * laddr,
-struct sockaddr_in * raddr,
-const char *hostname)
+pg_krb5_sendauth(char *PQerrormsg, int sock, const char *hostname)
{
krb5_error_code retval;
int ret;
@@ -611,9 +608,8 @@
case AUTH_REQ_KRB5:
#ifdef KRB5
- if (pg_krb5_sendauth(PQerrormsg, conn->sock, &conn->laddr.in,
-&conn->raddr.in,
-hostname) !=
STATUS_OK)
+ if (pg_krb5_sendauth(PQerrormsg, conn->sock,
+ hostname) != STATUS_OK)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
libpq_gettext("Kerberos 5 authentication
failed\n"));
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
- Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> Cc: "Alvaro Herrera" <[EMAIL PROTECTED]>; "Dann Corbit" <[EMAIL PROTECTED]>; "Jason Earl" <[EMAIL PROTECTED]>; "PostgreSQL-development" <[EMAIL PROTECTED]> Sent: Saturday, June 21, 2003 8:33 AM Subject: Re: [HACKERS] Two weeks to feature freeze > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > >> Maybe the NIST compliance test is adequate. > > > Plus I belive the RedHat people are getting PostgreSQL through the NIST > > compliance tests at the moment...I'd love to see MySQL pass them... > > FWIW, the first pass of those tests is complete, and it turned up > exactly one bug that we didn't already know of (the > outer-level-aggregate bizarrity that I fixed last week ... which MySQL > wouldn't be subject to since they haven't got subselects ...) > > The work is not done, because there are some tests that couldn't be run > because they were blocked by known noncompliances (such as lack of > updatable views). But I'm not getting a sense that we will learn a > whole lot from the NIST tests. As far as I can see NIST (http://www.itl.nist.gov/div897/ctg/sql_form.htm) tests are used *only* for testing SQL92 conformance. Latest available test suite version 6, dated 12/1996. Are you using about 6-7 years old test suite? Perhaps I am wrong, I would be happy If someone could point me up-to-date info about NIST conformance testing. regards, Alvis Tunkelis ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] what is the meaning of "schema"?
On Friday 20 Jun 2003 4:19 pm, _ wrote: > My understanding of "schema" that I discovered > in 7.3 (I don't think they were available before) > is that you can have two tables with the same name > if they are in different schemas. > > I have done a google search, as well as archive search > but > > pg_dump and pg_dumpall are broken if a database > contains schemas. > > First of all if there are two tables with the same > name in different schemas pg_dump only dumps out > one table. There is no way to dump other tables > and I have checked pg_dump man page Works here - v7.3.2: SET search_path = public, pg_catalog; [begin pg_dump extract] -- -- Data for TOC entry 25 (OID 2263656) -- Name: bar; Type: TABLE DATA; Schema: public; Owner: richardh -- COPY bar (m) FROM stdin; 1.00 2345.00 .00 \. SET search_path = richardh, pg_catalog; -- -- Data for TOC entry 26 (OID 2275041) -- Name: bar; Type: TABLE DATA; Schema: richardh; Owner: richardh -- COPY bar (a, b) FROM stdin; 1 aaa \. [end pg_dump extract] Did the user you pg_dumped as have visibility on your second schema? > Restoring a pg_dumpall is now a nightmare because > > I had as superuser > > # create schema test authorization httpd > > on a database not owned by database owner. > And it works merrily until the time to > dump and restore. > > pg_dumpall answers to above create authorization is > > \connect - httpd > > create schema test > > Hell breaks lose with that! Because httpd cannot > create schema on a database that it does not own. > Why couldn't pg_dumpall does > > create schema test authorization httpd Did you GRANT CREATE ON DATABASE for user httpd? That looks like what you need. > as superuser when the schema was created in that > fashion? > > I really don't think anyone is going to pay attention > to this rant since these list does not like/answer anonymous posts > but I have to post just so some poor soul might find > it in the archive and be warned. Always thought of the lists as welcoming myself, although I must admit anonymous posting is a bit odd. Especially when you could call yourself John Smith and no-one would be any the wiser. > My current versions are 7.3.2 and 7.3.3 and I have been using > posgres since 7.1 and consider myself experienced with postgres > > Schemas are the best thing since slice breads but > the baker decided to poison the bread. Nice! Let me know if this reply helps -- Richard Huxton ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] again: Bug #943: Server-Encoding from EUC_TW to
> Hello, > I reported bug #943 (I found in 7.3.2) and you checked in some change against > integer overflow. > Now I upgraded to 7.3.3 and I'm not happy with this. > The exact error as I described is fixed, but I found new errors in conversion UTF-8 > <-> EUC_TW and BIG5: > > Copy to table (DB has UTF-8 encoding) from file: > for PGCLIENTENCODING=BIG5: > WARNING: copy: line 1, LocalToUtf: could not convert (0xf9d6) BIG5 to UTF-8. Ignored > WARNING: copy: line 2, LocalToUtf: could not convert (0xf9d7) BIG5 to UTF-8. Ignored > WARNING: copy: line 3, LocalToUtf: could not convert (0xf9d8) BIG5 to UTF-8. Ignored > WARNING: copy: line 4, LocalToUtf: could not convert (0xf9db) BIG5 to UTF-8. Ignored I see no problem here. The only standard conversion map I could found on-line form so far (see below URL) does not include entries 0xf9d6 or above. http://www.unicode.org/Public/UNIDATA/Unihan.txt > for EUC_TW > WARNING: copy: line 1, LocalToUtf: could not convert (0x8ea3c3b7) EUC_TW to UTF-8. > Ignored > WARNING: copy: line 2, LocalToUtf: could not convert (0x8ea3cfd0) EUC_TW to UTF-8. > Ignored > WARNING: copy: line 3, LocalToUtf: could not convert (0x8ea3c4ce) EUC_TW to UTF-8. > Ignored > WARNING: copy: line 4, LocalToUtf: could not convert (0x8ea3bdfe) EUC_TW to UTF-8. > Ignored Hum. These seem to be CNS 11643-1993, plane 3. Currently PostgreSQL supports only: CNS 11643-1993, plane 0 CNS 11643-1993, plane 1 CNS 11643-1993, plane 2 CNS 11643-1993, plane 15 Would you like to have support for rest of CNS 11643-1993 planes: CNS 11643-1993, plane 3 CNS 11643-1993, plane 4 CNS 11643-1993, plane 5 CNS 11643-1993, plane 6 CNS 11643-1993, plane 7 support for upcoming 7.4? > Copy out to file from table (UTF-8 data): > to BIG5 > WARNING: UtfToLocal: could not convert UTF-8 (0xe7a281). Ignored > WARNING: UtfToLocal: could not convert UTF-8 (0xe98ab9). Ignored > WARNING: UtfToLocal: could not convert UTF-8 (0xe8a38f). Ignored > WARNING: UtfToLocal: could not convert UTF-8 (0xe7b2a7). Ignored > > to EUC_TW is ok! BIG5 and EUC_TW have different code points. So this is not very strange. -- Tatsuo Ishii ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Commands to change name, schema, owner
Tom Lane writes: > A few. Moving a table across schemas would require moving its indexes > and rowtype as well; conversely you should forbid moving the indexes and > rowtype by themselves, or altering their owners separately from the > table, or renaming the rowtype by itself. Right. This is mostly solved, so not really "tricky". ;-) > I am not real sure that renaming a database is safe if there are active > backends in it; doesn't a backend have its dbname stored statically in a > few places? Right, there's a global variable that stores the database name, but that will have to disappear. You'll have to look it up in the catalog like everything else. > Same goes for renaming a user who has active backends. That was cleaned up years ago, otherwise the session user/current user stack would not work. > (Even if you can fix the instances within the backend, what about > connected clients, for instance libpq's private state? That is a good point, but I'm not sure if it's really a problem. Perhaps in the first cut, active the active database and the session user may not be renamed. Later we can reconsider relaxing that. > And what if the rename means these clients should not have been allowed > to connect, per pg_hba.conf?) I'm not worried about that. This is much the same as changing your password: you should not have been allowed to connect because the password you had entered isn't right anymore. > Renaming operators would possibly change their precedence, which I don't > *think* would break rule dumps, but it's something to consider. I will check that. > Renaming sequences would break nextval() and related calls on them, > since we don't have any way to find the references and update the text > strings. It sure does, but we already allow renaming of sequences, so this won't be anything new. > Changing a function owner might be interesting for SECURITY DEFINER > functions; I'm not sure what is likely to happen for active or > already-planned calls on the function. That will not be a problem, because the user stack is adjusted once before each call, so the visible owner at the time of the call gets applied. (What happens inside the function is, of course, anyone's guess.) > > The command is: ALTER THING oldname RENAME TO newname; > > > Requires being the owner of the object (or superuser for group, user, > > language) and CREATE privilege on containing schema. > > The privilege considerations are doubtless different for the several > kinds of objects that don't live within schemas; could we see a more > complete spec? For those objects who don't live within schemas, you only need to own the object or the containing table, respectively. No privilege on any schema is required. In detail: constraint -> owner of table database -> owner of database rule -> owner of table schema -> owner of schema trigger -> owner of table Some of these call for more involved syntax: ALTER TABLE name RENAME CONSTRAINT old TO new; ALTER RULE oldname ON table RENAME TO newname; ALTER TRIGGER oldname ON table RENAME TO newname; -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit writes: > So far, I have seen three problems pointed out (out of 600+ tests). > That's 0.5% defects. Why not just drop the stupid tests, or bend them > to test for what they ought to be testing. The problem with crashme is that it tells you nothing of practical value. It doesn't tell you whether PostgreSQL works right. It doesn't tell you whether PostgreSQL works well. It doesn't tell you whether PostgreSQL conforms to some standard. It doesn't even tell whether PostgreSQL is compatible to some other product. The only thing that you could possibly get out of fixing crashme is to look better in crashme. And for the above reasons, there is little interest in working on that. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Thomas Swan writes: > Have you considered something similar to the Mozilla tinderbox approach > where you have a daemon checkout the cvs, compile, run regression tests, > and report a status or be able to report a status? Even if you could achieve near complete coverage of the platforms, platform versions, and auxilliary software versions and combinations that PostgreSQL runs with, in most cases, something breaks on a new version or combination of these things. -- 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] Two weeks to feature freeze
> > PostgreSQL has a comprehensive regression suite that is run > > by the developers all the time... > > If you mean the one that comes with PostgreSQL, then I think the MySQL > test is better. The PostgreSQL test seems to focus more on extensions > than anything else. I would be happy to make additions to the regression tests if you can give me a list of items that are missing. I've looked and didn't see anything obvious aside from inter-connection testing. Yes, tests run in parallel on multiple connections, but there is no interaction between since there is not a method of controlling the timing at the moment. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Two weeks to feature freeze
On Fri, 20 Jun 2003, Josh Berkus wrote: > Ultimately, this is one of those "technical" vs. "marketing" questions > ... whether to release now with a bunch of back-end features that the > current users want, or to release later and include the features that we > said were going to be in 7.4. And PostgreSQL is a technical project, > not a marketing one. Technical or Marketing, I think ppl are putting too much emphasis on 'visible features' and not enough on the 'not so visible' ones ... improvements to both performance and footprint are massive changes, but they are more difficult to 'market', then, say, adding schemas was ... ---(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] Two weeks to feature freeze
On Fri, 20 Jun 2003, Tom Lane wrote: > Time was that we had a major release every 3 or 4 months. As the > project matures I think it's appropriate for the cycle to get slower: a > lot of low-hanging fruit is gone, so we have larger jobs to tackle, plus > users are using PG for larger databases and don't want to face > major-version changes too often. But I don't want it to get to be a > year on average between releases, at least not yet. 8 or 9 months seems > reasonable, and by that standard we're overdue. Note that with how we've been releasing 'minors' on v7.3.x semi-regularly, slippage isn't *as* big an issue as it could have been ... ---(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] Two weeks to feature freeze
On Fri, 20 Jun 2003, Jason Earl wrote: > Heck, there are probably more than 70 machines running > CVS versions of PostgreSQL right this minute (Marc, any download > numbers to back this up?). Unfortunately, most ppl testing would be using CVS or CVSup, which don't (or, at least, I haven't been able to find?) log such .. download wise, through the FTP site, maybe 20 downloads since the 4th of June of the snapshot ... ---(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] compile failure on cvs tip --with-krb5
On Fri, Jun 20, 2003 at 07:48:02PM -0700, Joe Conway wrote:
> This change (I'm sure this will wrap poorly -- sorry):
> http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85&r2=1.86
>
> modified SockAddr, but no corresponding change was made here
> (fe-auth.c:612):
>
> case AUTH_REQ_KRB5:
> #ifdef KRB5
> if (pg_krb5_sendauth(PQerrormsg, conn->sock, &conn->laddr.in,
>&conn->raddr.in,
>hostname) != STATUS_OK)
>
> It's not obvious to me what the change ought to be though.
This patch should hopefully fix both kerberos 4 and 5.
Kurt
Index: src/backend/libpq/auth.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.102
diff -u -r1.102 auth.c
--- src/backend/libpq/auth.c12 Jun 2003 07:36:51 - 1.102
+++ src/backend/libpq/auth.c21 Jun 2003 15:02:06 -
@@ -430,6 +430,13 @@
}
case uaKrb4:
+ /* Kerberos 4 only seems to work with AF_INET. */
+ if (port->raddr.addr.ss_family != AF_INET
+ || port->laddr.addr.ss_family != AF_INET)
+ {
+ elog(FATAL,
+ "Unsupported protocol for Kerberos 4");
+ }
sendAuthRequest(port, AUTH_REQ_KRB4);
status = pg_krb4_recvauth(port);
break;
Index: src/interfaces/libpq/fe-auth.c
===
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/fe-auth.c,v
retrieving revision 1.80
diff -u -r1.80 fe-auth.c
--- src/interfaces/libpq/fe-auth.c 14 Jun 2003 17:49:53 - 1.80
+++ src/interfaces/libpq/fe-auth.c 21 Jun 2003 15:02:08 -
@@ -357,10 +357,7 @@
*the server
*/
static int
-pg_krb5_sendauth(char *PQerrormsg, int sock,
-struct sockaddr_in * laddr,
-struct sockaddr_in * raddr,
-const char *hostname)
+pg_krb5_sendauth(char *PQerrormsg, int sock, const char *hostname)
{
krb5_error_code retval;
int ret;
@@ -594,9 +591,10 @@
case AUTH_REQ_KRB4:
#ifdef KRB4
- if (pg_krb4_sendauth(PQerrormsg, conn->sock, &conn->laddr.in,
-&conn->raddr.in,
-hostname) !=
STATUS_OK)
+ if (pg_krb4_sendauth(PQerrormsg, conn->sock,
+ (struct sockaddr_in *)&conn->laddr.addr,
+ (struct sockaddr_in *)&conn->raddr.addr,
+ hostname) != STATUS_OK)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
libpq_gettext("Kerberos 4 authentication
failed\n"));
@@ -611,9 +609,8 @@
case AUTH_REQ_KRB5:
#ifdef KRB5
- if (pg_krb5_sendauth(PQerrormsg, conn->sock, &conn->laddr.in,
-&conn->raddr.in,
-hostname) !=
STATUS_OK)
+ if (pg_krb5_sendauth(PQerrormsg, conn->sock,
+ hostname) != STATUS_OK)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
libpq_gettext("Kerberos 5 authentication
failed\n"));
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Fri, 20 Jun 2003, Dann Corbit wrote: > > Hmm... I must have missed the huge corporation paying for in > > house testing of PostgreSQL. In the Free Software world the > > "beta team" is all of those people that need the new features > > so badly that they are willing to risk their own data and > > hardware testing it. > > I don't see how this model can possibly succeed then. You can't just > hope that your end users will: > 1. Exhaustively test > 2. Accurately report the findings But it does, and has for 10 years now ... > Our beta customers do help us to find bugs. Bugs reported by customers > for released products are extremely rare. Check the past archives for the mailing lists ... our "bugs reported by end users for released products" is extremely rare also, and *generally* is a result of them doing something that nobody had thought to test for before ... > Spoken like a programmer. Yes, real world data *always* turns up things > that neither the testers nor the programmers imagined. But a huge and > comprehensive conformance testing effort will turn up 99% of the > problems. And ours do ... I don't believe I can recall us having a release where we've had a stream of problem reports come flying in afterwards ... we might get one or two from ppl that have hit a 'never before seen' bug, that generally gets fixed very quickly ... > 100% code coverage is impossible. > Program proving is impossible. > 0% defect code delivery is impossible. > > But you should try to approach the ideal as closely as can be attained. And we do ... > The tests are good tests. They cover a wide range of features and > functions and discover if you can cause permanent damage to a database > by simply performing end-user queries. The scripts are a bit hokey, but > it isn't all that difficult to get them to run. Well, if you would like to volunteer to run them against PostgreSQL, and let us know what fails, we can let you know why said test is wrong in the first place ... we've been through crash-me several times before, and 'fixing crash-me' was more work then it was worth ... > > Basically any time a competitor differed from > > MySQL an error would be generated (despite the fact that it > > was very likely that it was MySQL that was wrong). > > This is unfair and untrue. (I have no connection whatsoever with the > MySQL group, BTW). Been there, done that ... even tried to get changes made to make the tests more accurate ... it was like trying to move a mountain ... > PostgreSQL has an excellent programming team. Why not try to recruit a > similar testing team? I think it would strongly differentiate the tool > set from similar free stuff. Are you volunteering? We already have a testing team we're happy with, but if you would like to extend it with your resources, please feel free to join in ... ---(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] Commands to change name, schema, owner
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Right, there's a global variable that stores the database name, but that > will have to disappear. You'll have to look it up in the catalog like > everything else. That answer is okay as long as we don't need to get at the value while outside any transaction (or in a failed transaction). Offhand I can't think of a reason we'd need to, but you'll need to look closely at the uses of that variable. [ other answers look fine ] > For those objects who don't live within schemas, you only need to own the > object or the containing table, respectively. No privilege on any schema > is required. In detail: > constraint -> owner of table > database -> owner of database > rule -> owner of table > schema -> owner of schema > trigger -> owner of table It could be argued that renaming a database should require CREATEDB rights, and that renaming a schema should require create-schema rights at the database level. For example, if user joe is given a schema joe, which he proceeds to rename to bob, it's not a lot different from him having been able to make a schema bob in the first place. ISTM if the DBA had disallowed create-schema rights to joe, he'd see this as an end run around that prohibition. The constraint/rule/trigger cases look fine, since names of those entities aren't super interesting anyway. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile failure on cvs tip --with-krb5
Kurt Roeckx wrote: This patch should hopefully fix both kerberos 4 and 5. Thanks, the patch fixes the compile issue for me. Disclaimer: I can't vouch for krb4 at all. And, although I compile support for krb5, I do that to find build problems, not because I use krb5. So I can't really speak to the correctness of the fix. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Regression tests fails to start on system without unix sockets.
The regression tests will fail to start on a system that doesn't have, or wasn't compiled for, unix domain sockets. The pg_regress script will start the postmaster with the -i option in case of QNX and BEOS, but not for instance in case of WIN32. I see some options to fix this: - Always start with -i - Make the "unix_sockets" variable depend on HAVE_UNIX_SOCKETS intead of listen the OSs. Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Thomas Swan writes: >> Have you considered something similar to the Mozilla tinderbox approach >> where you have a daemon checkout the cvs, compile, run regression tests, >> and report a status or be able to report a status? > Even if you could achieve near complete coverage of the platforms, > platform versions, and auxilliary software versions and combinations that > PostgreSQL runs with, in most cases, something breaks on a new > version or combination of these things. Still, whenever we're doing something that interacts at all with the OS, it seems we get breakages that don't show in the original author's testing, but only pop up days to months later when some beta tester tries the code on platform P or using option Q. The current difficulties with the IPv6 patches are a fine case in point. If we could get feedback more easily about whether a proposed patch compiles and passes regression on a variety of platforms, we could reduce the pain involved by a great deal, simply because the problems could be fixed while the code is still fresh in mind. I don't think there is any company involved with Postgres that is willing to commit the resources to run a Mozilla-style tinderbox setup singlehanded. But I wonder whether we couldn't set up something that is community-based: get a few dozen people with different platforms to volunteer to check the code regularly on their own machines. I'm imagining a cron job that fires daily in the wee hours, pulls the latest CVS tip, does "make distclean; configure; make; make check", and mails the results to someplace that puts 'em up on our website. It's possible that we could adapt the tinderbox software to work this way, but even if we had to write our own, it seems like a fairly simple task. And it'd give *much* better feedback on porting problems than we have now. Sure, there will always be corner cases you don't catch, but the first rule of testing is the sooner you find a bug the cheaper it is to fix. 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] Two weeks to feature freeze
--On Saturday, June 21, 2003 11:43:17 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Thomas Swan writes: Have you considered something similar to the Mozilla tinderbox approach where you have a daemon checkout the cvs, compile, run regression tests, and report a status or be able to report a status? Even if you could achieve near complete coverage of the platforms, platform versions, and auxilliary software versions and combinations that PostgreSQL runs with, in most cases, something breaks on a new version or combination of these things. Still, whenever we're doing something that interacts at all with the OS, it seems we get breakages that don't show in the original author's testing, but only pop up days to months later when some beta tester tries the code on platform P or using option Q. The current difficulties with the IPv6 patches are a fine case in point. If we could get feedback more easily about whether a proposed patch compiles and passes regression on a variety of platforms, we could reduce the pain involved by a great deal, simply because the problems could be fixed while the code is still fresh in mind. I don't think there is any company involved with Postgres that is willing to commit the resources to run a Mozilla-style tinderbox setup singlehanded. But I wonder whether we couldn't set up something that is community-based: get a few dozen people with different platforms to volunteer to check the code regularly on their own machines. I'm imagining a cron job that fires daily in the wee hours, pulls the latest CVS tip, does "make distclean; configure; make; make check", and mails the results to someplace that puts 'em up on our website. It's possible that we could adapt the tinderbox software to work this way, but even if we had to write our own, it seems like a fairly simple task. And it'd give *much* better feedback on porting problems than we have now. Sure, there will always be corner cases you don't catch, but the first rule of testing is the sooner you find a bug the cheaper it is to fix. 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]) I'm willing to run such a job on UnixWare 7.1.3 and OpenUnix 8, as well as FreeBSD 4.8 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Regression tests fails to start on system without unix sockets.
Kurt Roeckx <[EMAIL PROTECTED]> writes: > The regression tests will fail to start on a system that doesn't > have, or wasn't compiled for, unix domain sockets. > I see some options to fix this: > - Always start with -i > - Make the "unix_sockets" variable depend on > HAVE_UNIX_SOCKETS intead of listen the OSs. The second way is the way it should have been done all along. Probably the best fix is to add a command-line switch to pg_regress to instruct it to use -i, and then have the makefile test HAVE_UNIX_SOCKETS to decide whether to pass that switch. This way, hand invocation of the script could easily run the test both ways, on machines where that's possible. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
<[EMAIL PROTECTED]> writes: > As far as I can see NIST (http://www.itl.nist.gov/div897/ctg/sql_form.htm) > tests are used *only* for testing SQL92 conformance. > Latest available test suite version 6, dated 12/1996. > Are you using about 6-7 years old test suite? > Perhaps I am wrong, I would be happy If someone could point me up-to-date > info about NIST conformance testing. AFAIK, the NIST abandoned that project years ago, so there isn't any more-up-to-date test suite available. Not sure this is a big problem, since SQL92 is not a moving target. It'd be nice if they had kept working and developed tests for the non-entry-level features, but they didn't. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Fri, Jun 20, 2003 at 10:04:09PM -0700, Dann Corbit wrote: > > On Fri, Jun 20, 2003 at 09:25:08PM -0700, Dann Corbit wrote: > > > > Citing Tom Lane: > > > > I have been through crash-me in some detail, and it left a > > > > very bad taste in my mouth. Don't bother holding it up as an > > > > example of good practice. > > > > > > Every single test in their list is interesting and useful. > > > > At least on the version I just saw there are several results > > with Postgres that are weird (table names > 500 chars?). > > It does get silly at a point, but I have seen systems with 128 > characters for table names, column names, etc. Some people seem to like > it. Not me. Too much typing. I meant that the real limit on 7.2 was much lower than that unless they twiddled with sources at compile time (there's no configure switch for that AFAIR). Maybe 31 or 63 chars, I don't remember. Do you really trust the rest of the test seeing that they came up with a clearly wrong answer in such a simple test? They can't even "make vacuum run reliably" on 7.1. See the performance test. Maybe they want to test 7.3 with lazy vacuum in place. Why don't they do that? 7.1 is already 2 years old. > > Other things tested are clearly wrong (things that are = > > NULL, > > Sounds like testing for the existence of a bug. > X = NULL > X <= NULL > X >= NULL > Etc. must always test false, regardless of the contents of X. Test for > equality with NULL is a conformance error if NULL == NULL returns true. You see, you are saying "sounds like they are testing". What does the code actually test? Which is the right behaviour? Which behaviour gets the green point, MySQL's or the right one? There are lots of things like this; I don't want to waste my time actually reading the code to see what the correct answer for each test is. About the 1--1 thing Tom mentioned: be aware that Postgres happily accepts the correct 1 - -1 expression, but also correctly fails to "calculate" 1--1. Which one gets the green point? Of course it's the non-compliant one. Also they don't test things they don't support. Is there a test for subselects? What about concurrency? Transactional issues? What about performance when they have their "transaction support" enabled? > So far, I have seen three problems pointed out (out of 600+ tests). > That's 0.5% defects. Why not just drop the stupid tests, or bend them > to test for what they ought to be testing. There's already a mechanism for testing inside Postgres. Maybe more tests are needed, but crash-me offers no real value. I just became aware that the NIST test suite is quite old. Maybe what's needed is to expand it to SQL3 to develop a way of measuring the compliance level. But the cost of doing that is probably prohibitive. -- Alvaro Herrera () "Hay quien adquiere la mala costumbre de ser infeliz" (M. A. Evans) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [DEFAULT] Automated testing WAS: Two weeks to feature freeze
Dann, > > Thus, the best test > > team is a bunch of people doing unplanned things with the > > software, on a wide variety of platforms... > > That is the worst possible test plan. It totally lacks organization and > there is no hint to define when the feature set has been covered. Ad > hoc testing is a useful addition, but it cannot replace all the standard > tests that have been used by the industry for decades. Them's fighting words, Mister. We have a test team ... a good test team ... I'm one of them. I have 7.4 CVS on 2 servers right now, and have loaded them with things I doubt Tom ever expected. You're directly insulting most of the people on this list. What's your motivation, exactly? Further, results argue against you. PostgreSQL's "ad-hoc" testing beats the formal testing of many large companies -- such as Microsoft. I professionally admin both PostgreSQL and MS SQL Server (which MS puts through a multi-million dollar testing proccess) ... guess which has less bugs, and less critical bugs? You're barging on this list, criticizing its members, pointing out problems where they don't exist, and not offering any help. Are you being paid by someone who doesn't like PostgreSQL, or do you just enjoy making enemies? > > Are you volunteering to create it? Step right up. > > No. And as an outsider, I rather doubt if any procedures I developed > would be taken very seriously. That's a pretty weak-ass excuse. If you're not offering to create or at least *work on* an expanded test suite, why are you wasting our time? According to you, your company has a elaborate testing procedure with numerous staff and (I would assume) some pretty comprehensive testing software. How about a donation? > A. Combine: > B. Automate: These parts sound pretty good. How about *you* create a test suite that does this? > C. Assign: > 1. Criteria for acceptance of a build for release > 2. Authority for acceptance of a build for release > 3. Delegation rules for issue resolution > 4. Procedures for issue resolution This sounds very corporate, and not in keeping with our OSS community. Our bug and patch submission process works pretty good right now; why monkey with what works? An OSS project that tries to assign people duties and jobs they don't want is a deserted and dead OSS project. You may know lots about automated testing, Dann, but you know squat-all about Open Source and about community relations. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Commands to change name, schema, owner
Christopher Kings-Lynne writes: > > The command is: ALTER THING name AUTHORIZATION username; (This is > > consistent with the CREATE SCHEMA syntax. Anyone like OWNER better?) > k > WHy not copy the exiting ALTER TABLE / OWNER TO syntax? Because the standard specifies the syntax CREATE SCHEMA name AUTHORIZATION username. I'd rather generalize a standard syntax. But we can have both if people prefer that. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Larry Rosenman wrote: --On Saturday, June 21, 2003 11:43:17 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Thomas Swan writes: Have you considered something similar to the Mozilla tinderbox approach where you have a daemon checkout the cvs, compile, run regression tests, and report a status or be able to report a status? Even if you could achieve near complete coverage of the platforms, platform versions, and auxilliary software versions and combinations that PostgreSQL runs with, in most cases, something breaks on a new version or combination of these things. Still, whenever we're doing something that interacts at all with the OS, it seems we get breakages that don't show in the original author's testing, but only pop up days to months later when some beta tester tries the code on platform P or using option Q. The current difficulties with the IPv6 patches are a fine case in point. If we could get feedback more easily about whether a proposed patch compiles and passes regression on a variety of platforms, we could reduce the pain involved by a great deal, simply because the problems could be fixed while the code is still fresh in mind. I don't think there is any company involved with Postgres that is willing to commit the resources to run a Mozilla-style tinderbox setup singlehanded. But I wonder whether we couldn't set up something that is community-based: get a few dozen people with different platforms to volunteer to check the code regularly on their own machines. I'm imagining a cron job that fires daily in the wee hours, pulls the latest CVS tip, does "make distclean; configure; make; make check", and mails the results to someplace that puts 'em up on our website. It's possible that we could adapt the tinderbox software to work this way, but even if we had to write our own, it seems like a fairly simple task. And it'd give *much* better feedback on porting problems than we have now. Sure, there will always be corner cases you don't catch, but the first rule of testing is the sooner you find a bug the cheaper it is to fix. 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]) I'm willing to run such a job on UnixWare 7.1.3 and OpenUnix 8, as well as FreeBSD 4.8 I'll have a machine shortly where I can run RH9 SMP tests.. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] interval's and printing...
Why does the interval type not print seconds when they are zero? This leads to inconsistent reading of the information. 7.3.3: ler=# select '13 minutes'::interval; interval -- 00:13 (1 row) ler=# select '13 minutes 1 second'::interval; interval -- 00:13:01 (1 row) ler=# I noticed this when I loaded the data from my long distance company into a PG database. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Tom Lane wrote: > I have been through crash-me in some detail, and it left a very bad > taste in my mouth. Don't bother holding it up as an example of good > practice. You seem to miss Dan's point. The specific implementation of crashme is undoubtedly flawed in a number of ways, but the idea is very useful as part of an acceptance testing suite. In short, it would probably be beneficial to us to fix crashme so that it tests the proper, standards-compliant things and reports the actual results, and then include it in the test suite. Indeed, we could even go so far as to use it for our own marketing purposes! Have it cite, for each test, which part of the SQL spec it's testing and what the result should be. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] interval's and printing...
Larry Rosenman <[EMAIL PROTECTED]> writes: > Why does the interval type not print seconds when they are zero? Seems like a bug to me too. Anyone think it's not? Note this only occurs with DateStyle = ISO, the other datestyles use a different format for intervals. 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] Two weeks to feature freeze
I wrote: > Tom Lane wrote: > > I have been through crash-me in some detail, and it left a very bad > > taste in my mouth. Don't bother holding it up as an example of good > > practice. > > You seem to miss Dan's point. The specific implementation of crashme > is undoubtedly flawed in a number of ways, but the idea is very useful > as part of an acceptance testing suite. In short, it would probably > be beneficial to us to fix crashme so that it tests the proper, > standards-compliant things and reports the actual results, and then > include it in the test suite. Actually, now that I think about it, it would probably be more beneficial to merge any correct tests that we aren't already performing into our existing regression test framework, provided that the end result doesn't take too long to run (as you pointed out elsewhere, regression tests that take a really long time to run simply won't be run by most people, except perhaps in a tinderbox type of environment). Overall, it might be of some benefit to mark individual regression tests with a priority, and then make it possible to run only those tests of a specified priority or higher. That way, the indvidual developer may decide for himself which group of regression tests to run based on the amount of time he's willing to let it take and how much hardware he has to throw at it. And at the same time, it would make it easier for new tests to be included in the suite without worrying about the impact it would have on people running the tests. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
- Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Peter Eisentraut" <[EMAIL PROTECTED]> Cc: "Thomas Swan" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, June 21, 2003 11:43 AM Subject: Re: [HACKERS] Two weeks to feature freeze > I don't think there is any company involved with Postgres that is > willing to commit the resources to run a Mozilla-style tinderbox setup > singlehanded. But I wonder whether we couldn't set up something that is > community-based: get a few dozen people with different platforms to > volunteer to check the code regularly on their own machines. I'm > imagining a cron job that fires daily in the wee hours, pulls the latest > CVS tip, does "make distclean; configure; make; make check", and mails > the results to someplace that puts 'em up on our website. > > It's possible that we could adapt the tinderbox software to work this > way, but even if we had to write our own, it seems like a fairly simple > task. And it'd give *much* better feedback on porting problems than we > have now. Sure, there will always be corner cases you don't catch, > but the first rule of testing is the sooner you find a bug the cheaper > it is to fix. > Two thoughts: 1. we'd need a matrix of hardware / (OS/version) / other environmental things to ensure some sort of good coverage. 2. we'd need to test various configuration sets too, e.g. --with-krb5 I too have an old spare x86 machine lying around that I can set up with whatever free *nix might not have coverage and contribute to the effort. 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
[HACKERS] a problem with index and user define type
Hi all:
I write a use define type (UUID)
typedef struct uuid
{
uint32 time_low;
uint16 time_mid;
uint16 time_hi_and_version;
uint8 clock_seq_hi_and_reserved;
uint8 clock_seq_low;
uint8 node[6];
} uuid;
make all btree index function and operator, such as
CREATE OPERATOR CLASS uuid_btree_ops
DEFAULT FOR TYPE uuid USING btree
AS
OPERATOR1 < ,
OPERATOR2 <= ,
OPERATOR3 = ,
OPERATOR4 >= ,
OPERATOR5 > ,
FUNCTION1 uuid_cmp(uuid, uuid),
create table test_uuid(id uuid primary key default uuid_time(), name
char(40));
but this query: select * from test_uuid where id =
'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid dosn't use index
QUERY PLAN
---
Seq Scan on test_uuid (cost=0.00..22.50 rows=500 width=140)
Filter: (id = 'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid)
why ??
source code see attachement
MikeWang
-
What is uuid?
uuid is a kind of data type, provide for PostgreSQL to implement unique
id in cyberspace,
it's based one UUID URN name space IETF draft (see
doc/draft-mealling-uuid-urn-00.txt),
now, pguuid support NIL(0), Time-Base(1), Name-Base(3) and
Random-Base(4) type UUID.
It's propuse is
provide a solution
for data replication, merge, and distribute.
what is the use of uuid?
1, pguuid provide PostgreSQL a data type: uuid, it can provide unique
id in
cyberspace.
2, provide type uuid related operator (e.g. =, <>, <, >, >=, <=)
3, provide functions to generate Time-base, Name-base, Random-base and
Nil-UUID.
4, provide functions to parse uuid type.
license:
BSD
_
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
uuid-v2.0.1.0.tar.gz
Description: GNU Zip compressed data
---(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] Two weeks to feature freeze
Rod Taylor wrote: > > Do we have any "killer" features added to 7.4 that we can shout about? > > There's usually been one or two in the past...? > > A quick glance at the TODO list shows a number of speed improvements in > specific areas (IN, GROUP BY, Subselects in views), ARRAY improvements, > some utility command improvements / additions, and a significant > protocol update. > > The protocol update may not be flashy, but it is a large step forward in > presenting a clean experience for developers using PostgreSQL (reduces > chance of rare, unexpected, and difficult to find logic errors). > > If nothing else, it makes for an excellent cleanup release that rounds > off some of the sharp corners (tab completion for schema elements in > psql, schema dump in psql, fixed cluster support, transactional > truncate, alter sequence, new regex code for fast MultiByte, etc). The problem with cleanup releases is that most of our recent releases have been of that type. Each release is a good step forward, but I was hoping for a set of killer features for this release. Tom said that our low-hanging fruit is gone and only hard items are left. This is certainly true. What is hard to accept is that those big items take _weeks_ of focused development, and we just don't have enough full-time developers who can spend that amount of time to do them. The sad truth is that there is alway something _else_ to do, rather than block out weeks to code a complex feature. And these are usually features that can't be done incrementally, but require a huge input of time before there is any payback. I tried with Win32, and spent a few weeks getting us closer, but my other work of housecleaning (email/patches/cleanup), and marketing (speaking and tutorial preparation) just make it impossible to spend the time needed to complete a big item. And people were rightly upset that the patches weren't getting applied or cleanup done in a timely manner. It is depressing. -- 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 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] Two weeks to feature freeze
Tom Lane wrote: > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > What about the nested transaction stuff? > > With all due respect to Alvaro et al, I can't imagine that that will > make it into 7.4. (I have no confidence that PITR or Win32 native port > will make it either...) > > > Do we have any "killer" features added to 7.4 that we can shout about? > > We have a lot of pretty good stuff. You're not happy that the > performance of IN (subselect) has been fixed? That btree index bloat is > fixed (at least in large part, it remains to be seen whether the field > performance is all that we need...)? > > In my opinion the project is not at a state where whizzy new Features > with a capital F are going to jump out of the woodwork. We are making > good advances in performance, reliability, SQL spec compliance, and > stuff like that, but fancy-sounding bullet points are hard to come by. What does bother me is that we weren't getting any closer on those _hard_ items. At least with this release, we will be _closer_ on Win32 and PITR. -- 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] Two weeks to feature freeze
Oleg Bartunov wrote: > > Do we have any "killer" features added to 7.4 that we can shout about? > > There's usually been one or two in the past...? > > I'm not sure if contrib/tsearch is a "killer" feature, but we hope > to submit completely new version of tsearch V2 before July 1. > Actually, we have stable code already used in some projects but > currently lacking documentation. Several people are working on tutorial, > reference guide. The problem is that Bruce seems is very overloaded and > for sure he'll have many patches close to July 1. Is it possible > to get rights to commit our changes ? I am sorry there has been such a delay in patches. I will try go improve that, or someone else can apply them. -- 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] Two weeks to feature freeze
Andrew Dunstan wrote: > > Maybe a better strategy would be to get a release out soon but not wait 6 > months for another release which would contain the Win32 port and the PITR > stuff (assuming those aren't done in time for this release). What concerns me is that we thought that after 7.3, and didn't do much work on either until we got near 7.4 release. I wonder if this is just going to be a pattern, where these items are so large, we can't get any motivation to focus on them until we get near the final release. I guess if each final release gets us a little closer, eventually we will get there, but this process is not ideal. The big puzzle is how do you get people (including myself) motivated to work on a feature that takes a _huge_ amount of work to see any payoff? I would like to know. Anyone? -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Jason Earl wrote: > > I'd rather see the dev cycle shortened by a month, then extended ... > > Why couldn't you just release the win32 version of 7.4 when it was > finished. If it takes an extra month then that just gives you guys > the chance to circulate *two* press releases. The Native Win32 port > is likely to make a big enough splash all by itself. I am working to try to get fork/exec and signals in before the feature freeze so a Win32 patch to 7.4 is possible. -- 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] PQfreemem??
What happened to: void PQfreemem(void *) in libpq-fe.h? I thought it was going to be included in 7.3.3 ? -Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Sat, 21 Jun 2003, Bruce Momjian wrote: > What does bother me is that we weren't getting any closer on those > _hard_ items. At least with this release, we will be _closer_ on Win32 > and PITR. Maybe our problem is such a ... hatred of #ifdef? Maybe its time to go back a bit to our roots ... get the 'experimental features' in with #ifdef so that others have a chance to look at and work on it, and once ready for prime time, pull the #ifdef's out ... ? ---(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] Two weeks to feature freeze
Dann Corbit wrote: > > Adding a new platform--especially a platform as diverse from > > the rest of PostgreSQL's supported platforms as Windows--is > > what adds the work. Testing the new platform is relatively > > easy. All you need to do is to start using the Win32 version > > with real live data. > > That is not testing. Using the world as your beta team seems to be a > business model used by a few software giants that is largely frowned > upon. I would think that there is an opportunity to do things > differently. [Read 'properly']. > > We (at CONNX Solutions Inc.) have a formal release procedure that > includes many tens of thousands of automated tests using dozens of > different platforms. There are literally dozens of machines (I would > guess 70 or so total) running around the clock for 7 days before we even > know if we have a release candidate. The QA team is distinct from the > development team, and if they say "FLOP!" the release goes nowhere. No > formal release until QA passes it. > > If there is no procedure for PostgreSQL of this nature, then there > really needs to be. I am sure that MySQL must have something in place > like that. Their "Crash-Me" test suite shows (at least) that they have > put a large effort into testing. One thing you might be missing is that we have a _very_ close relationship with our users. We can send out code and debug/fix things much faster than a company can that ships binaries. If you look at the changes that go into minor releases (post X.X.0 releases) you will see very few fixes, and the ones we do fine are usually for very esoteric problem cases. Maybe it isn't ideal, but given our limited resources, it works very well. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Dann Corbit wrote: > Perhaps all that is needed is some sort of automated, formal reporting > procedure. For example, a large test set might be created that runs a > thorough regression feature list. When the test completes, a data file > is emailed to some central repository, parsed, and stored in a database. I do have an automated build/initdb/regression that I run every night and email the results to myself. [ "X$1" != "X-n" ] && CLEAN="-c" && shift . /etc/profile pgstop rm -r /u/pg/data # return command error value (pgmakeall $CLEAN 2>&1; echo "$?" > $TMP/ret) | (tee $TMP/0; exit `cat $TMP/ret`) && aspg initdb && pgstart && newdb test && cd /pg/test/regress && gmake clean && aspg gmake installcheck grep warning $TMP/0 | grep -v setproctitle | grep -v find_rule | grep -v yy_flex_realloc | grep -v '\[javac\] 1 warning' I also run this after I apply patches. -- 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 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] Two weeks to feature freeze
Dann Corbit wrote: > That is the worst possible test plan. It totally lacks organization and > there is no hint to define when the feature set has been covered. Ad > hoc testing is a useful addition, but it cannot replace all the standard > tests that have been used by the industry for decades. > > If you run literally hundreds of tests designed to ensure that your > product conforms to ANSI/ISO standards then the bugs that are missed > will be few and far between. Unless you are bad at designing tests. > > Designing tests is busywork. Desiging tests is boring. Nobody wants to > design tests, let alone interpret the results and define correct > baselines. But testing is very, very important. I remember when I was with Great Bridge they said, "Oh, we are going to have a test setup and do all sorts of testing to improve PostgreSQL." I told them I doubted their testing was going to shake out many more bugs than our existing testing setup, and you know what, I was pretty much right. Sure, they found a few, but it wasn't much. -- 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 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] Two weeks to feature freeze
The Hermit Hacker wrote: > On Sat, 21 Jun 2003, Bruce Momjian wrote: > > > What does bother me is that we weren't getting any closer on those > > _hard_ items. At least with this release, we will be _closer_ on Win32 > > and PITR. > > Maybe our problem is such a ... hatred of #ifdef? Maybe its time to go > back a bit to our roots ... get the 'experimental features' in with #ifdef > so that others have a chance to look at and work on it, and once ready for > prime time, pull the #ifdef's out ... ? That's a tough call. I do worry about readability. We have made Win32 changes, and they aren't ifdefs, and we still have a running system, and I think we can do that for PITR too. I think the big issue, which may be your point, is to get incremental work into CVS as soon as possible so we continue to take small steps. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] a problem with index and user define type
"Wang Mike" <[EMAIL PROTECTED]> writes: > but this query: select * from test_uuid where id = > 'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid dosn't use index > QUERY PLAN > --- > Seq Scan on test_uuid (cost=0.00..22.50 rows=500 width=140) >Filter: (id = 'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid) > why ?? The rows estimate looks pretty fishy --- I think you are getting the 0.5 default selectivity estimate for an operator that has no restriction estimator. Most likely you should have created the operator using eqsel and eqjoinsel as the restriction/join estimators. 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] Two weeks to feature freeze
I have added a cleaned up version of this to CVS as src/tools/pgtest. --- Bruce Momjian wrote: > Dann Corbit wrote: > > Perhaps all that is needed is some sort of automated, formal reporting > > procedure. For example, a large test set might be created that runs a > > thorough regression feature list. When the test completes, a data file > > is emailed to some central repository, parsed, and stored in a database. > > I do have an automated build/initdb/regression that I run every night > and email the results to myself. > > > [ "X$1" != "X-n" ] && CLEAN="-c" && shift > > . /etc/profile > pgstop > rm -r /u/pg/data > # return command error value > (pgmakeall $CLEAN 2>&1; echo "$?" > $TMP/ret) | > (tee $TMP/0; exit `cat $TMP/ret`) && > aspg initdb && > pgstart && > newdb test && > cd /pg/test/regress && > gmake clean && > aspg gmake installcheck > grep warning $TMP/0 | > grep -v setproctitle | > grep -v find_rule | > grep -v yy_flex_realloc | > grep -v '\[javac\] 1 warning' > > I also run this after I apply patches. > > -- > 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 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 > -- 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
Re: [HACKERS] PQfreemem??
"David Brown" <[EMAIL PROTECTED]> writes: > What happened to: void PQfreemem(void *) in libpq-fe.h? I thought it was > going to be included in 7.3.3 ? 7.4 branch only, AFAICS. regards, tom lane ---(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] Two weeks to feature freeze
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom said that our low-hanging fruit is gone and only hard items are > left. This is certainly true. What is hard to accept is that those big > items take _weeks_ of focused development, and we just don't have enough > full-time developers who can spend that amount of time to do them. The > sad truth is that there is alway something _else_ to do, rather than > block out weeks to code a complex feature. And these are usually > features that can't be done incrementally, but require a huge input of > time before there is any payback. I spent weeks doing hash aggregates, weeks doing IN-subselect optimization, and am in the middle of many weeks on FE/BE protocol improvement. I am sorry that you don't see these as killer features ... but they are all things that we desperately needed to do. regards, tom lane ---(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] Two weeks to feature freeze
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom said that our low-hanging fruit is gone and only hard items are > > left. This is certainly true. What is hard to accept is that those big > > items take _weeks_ of focused development, and we just don't have enough > > full-time developers who can spend that amount of time to do them. The > > sad truth is that there is alway something _else_ to do, rather than > > block out weeks to code a complex feature. And these are usually > > features that can't be done incrementally, but require a huge input of > > time before there is any payback. > > I spent weeks doing hash aggregates, weeks doing IN-subselect > optimization, and am in the middle of many weeks on FE/BE protocol > improvement. I am sorry that you don't see these as killer features > ... but they are all things that we desperately needed to do. > Yes, I know they are _very_ needed, but they don't increase functionality the way Win32 or PITR would do. Please don't feel I am minimizing these features. If I had to choose, I would choose those features over Win32 or PITR. It is just that I wanted all of them. :-( -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
- Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> > Tom said that our low-hanging fruit is gone and only hard items are > left. This is certainly true. What is hard to accept is that those big > items take _weeks_ of focused development, and we just don't have enough > full-time developers who can spend that amount of time to do them. The > sad truth is that there is alway something _else_ to do, rather than > block out weeks to code a complex feature. And these are usually > features that can't be done incrementally, but require a huge input of > time before there is any payback. > > I tried with Win32, and spent a few weeks getting us closer, but my > other work of housecleaning (email/patches/cleanup), and marketing > (speaking and tutorial preparation) just make it impossible to spend the > time needed to complete a big item. And people were rightly upset that > the patches weren't getting applied or cleanup done in a timely manner. > > It is depressing. I was disappointed that Satoshi Nagayasu's two-phase commit patches seemed to be implicitly rejected by lack of an enthusiastic response by any of the core members. Distributed query (not replication) would have been a very nice feature. It's what separates, in part, Oracle Enterprise Edition from the Standard Edition, and it appeared someone (Satoshi Nagayasu) was more than willing to get the ball rolling. But the flight path bothered some I guess so we got nothin' Mike Mascari [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])
