Re: [HACKERS] Getting to 8.3 beta1
Alvaro Herrera wrote: Greg Smith wrote: On Thu, 27 Sep 2007, Tom Lane wrote: Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched...I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). Bruce you mentioned in a post earlier this week that you were going to jump back on the release notes. Earlier last week, I said I would jump on them as did Greg. Greg went through the effort to do the below... shall we use it together? Too late. Tom already did a lot of the work. See http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508r2=1.509 or the HTML version at http://momjian.us/main/writings/pgsql/sgml/release-8-3.html Sorry I dropped the ball on the release notes. My wife had minor surgery last Monday and I hoped to be freed up earlier but the recovery was longer than expected. I am back to reading email now. Thanks to Tom for doing the release notes, and to others for helping. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting to 8.3 beta1
Hi, On 10/4/07, Tom Lane [EMAIL PROTECTED] wrote: At this point the bulk of the work is done, except for SGML markup prettification. There is a typo in the contrib part: # Add GIN support for hstore (Guillaume Smet, Teodor) # Add GIN support for pg_trgm (Guillaume Smet, Teodor0 s/Teodor0/Teodor)/ And I didn't participate to the GIN support of hstore, I just added it to pg_trgm with the help of Teodor so it should be Teodor alone on hstore GIN support. Regards, -- Guillaume ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-10-04 at 09:04 +0200, Guillaume Smet wrote: There is a typo in the contrib part: # Add GIN support for hstore (Guillaume Smet, Teodor) # Add GIN support for pg_trgm (Guillaume Smet, Teodor0 s/Teodor0/Teodor)/ And I didn't participate to the GIN support of hstore, I just added it to pg_trgm with the help of Teodor so it should be Teodor alone on hstore GIN support. Fixed, thanks. -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Smith wrote: On Thu, 27 Sep 2007, Tom Lane wrote: Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched...I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). Bruce you mentioned in a post earlier this week that you were going to jump back on the release notes. Earlier last week, I said I would jump on them as did Greg. Greg went through the effort to do the below... shall we use it together? Joshua D. Drake I just dumped a copy of Tom's file on my personal page and posted a much slimmed down version that's missing the names of the files touched onto the wiki at http://developer.postgresql.org/index.php/8.3_Changelog (with a pointer to the full text in case anyone needs to dig back into the details to figure out what a commit touched). There was already an outline for building the release notes into at http://developer.postgresql.org/index.php/8.3release What I was thinking might be a useful way for multiple people to hack away at this problem is to start fleshing out the standard release note one-line summaries onto the one page, then delete the relevant commits from the other. When the changelog page is empty, then everything is documented. I didn't actually start doing this though as I didn't want to dump any more time into a process that may not actually be used. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBAWGATb/zqfZUUQRAt/sAKCjvXWSJ0J4N6Vp5HlokJqeSt22QwCglGJw 996PY4JCX+o6AfhrDftOiJ0= =eEQw -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Smith wrote: On Thu, 27 Sep 2007, Tom Lane wrote: Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched...I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). Bruce you mentioned in a post earlier this week that you were going to jump back on the release notes. Earlier last week, I said I would jump on them as did Greg. Greg went through the effort to do the below... shall we use it together? Too late. Tom already did a lot of the work. See http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508r2=1.509 or the HTML version at http://momjian.us/main/writings/pgsql/sgml/release-8-3.html -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC Ellos andaban todos desnudos como su madre los parió, y también las mujeres, aunque no vi más que una, harto moza, y todos los que yo vi eran todos mancebos, que ninguno vi de edad de más de XXX años (Cristóbal Colón) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alvaro Herrera wrote: Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Smith wrote: On Thu, 27 Sep 2007, Tom Lane wrote: Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched...I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). Bruce you mentioned in a post earlier this week that you were going to jump back on the release notes. Earlier last week, I said I would jump on them as did Greg. Greg went through the effort to do the below... shall we use it together? Too late. Tom already did a lot of the work. See http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508r2=1.509 or the HTML version at http://momjian.us/main/writings/pgsql/sgml/release-8-3.html Right... I believe... that was first run though, at which point he asked for helpers to which greg and I responded. I could be wrong? Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBAv7ATb/zqfZUUQRAsHeAJ0XhEY+7/Qr12bT5mD3g2c1wr+SaQCfaJD/ +3AApwJxH/px8f77F4jq/Ug= =+n1R -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting to 8.3 beta1
Joshua D. Drake [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Too late. Tom already did a lot of the work. See http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml?r1=1.508r2=1.509 Right... I believe... that was first run though, at which point he asked for helpers to which greg and I responded. That was last week ... I didn't see anything happening so I went back to it. At this point the bulk of the work is done, except for SGML markup prettification. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
* Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? -1. You don't bump major if the old api can be used 1:1 with the new lib. New functions is not a reason for a major bump. The major version business is to protect you from ruining currently running (old) programs, not from using a too old lib with newly compiled programs. Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote: Gregory Stark wrote: What we want to know is that things like pgadmin can connect properly to either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the server authentication is configured. Do they work correctly if the server tries to do password authentication, ident, kerberos, etc. That's a matter of protocol-compatibility, and that's not the issue here. We're talking about *ABI* compatibility. In a nutshell, if you have a an program that's compiled with 8.2 libpq-library, will it work when linked to 8.3 library at runtime? And if you have a program compiled with 8.3 library, does it work with a 8.2 library? Right. But yeah, the regression tests won't help much with that. I suppose you could try to use an 8.2 psql with an 8.3 library and see if it works, but I don't know how much of the library interface psql exercises. Eh, I figure it'll test the more common calls, though I agree that it doesn't hit every symbol... Perhaps we should look at expanding the regression tests to try and cover everything exported? That might require a new binary if we don't want to clutter up psql, but it strikes me as a pretty decent idea in general. I think it's easier and more reliable to just go through the commit logs for libpq, and see if anything has changed. Even that isn't bullet-proof though. For example, if there's an incompatible change to a struct or a typedef that's used as a function parameter, that breaks binary compatibility as well. I agree that this is certainly the best approach, if practical. Another option would be to just check the symbol list using objdump. Sounds like Tom already did something similar though by looking through the exports file. In the future, we should try to keep this in mind during the development cycle, and bump the minor version number the first time a backwards-compatible change, like adding a new function, is made, and bump the major version number the first time an incompatible change is made. Like we do for catalog version, except that we only want to bump the libpq version number once per release. (though we do sometimes forget to bump the catalog version number as well) Agreed. Thanks, Stephen signature.asc Description: Digital signature
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
Zdenek Kotala wrote: I'm Sorry for confusion, I overlooked it. You have right. Unfortunately struct Port has been modified and by my opinion it means we must bump major version. See http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63 That header file is *not* part of the libpq interface, see the comment at the beginning of the file. So no major version bump required. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
Heikki Linnakangas [EMAIL PROTECTED] writes: Zdenek Kotala wrote: struct Port has been modified and by my opinion it means we must bump major version. See http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63 That header file is *not* part of the libpq interface, see the comment at the beginning of the file. So no major version bump required. Right, and even pqcomm.h (to which the comment refers) is material that is known to libpq (and other implementors of the FE/BE protocol), but is not exposed to client applications. This comment in pqcomm.c might be helpful: * At one time, libpq was shared between frontend and backend, but now * the backend's backend/libpq is quite separate from interfaces/libpq. * All that remains is similarities of names to trap the unwary... The only material that is officially part of the libpq client API is libpq-fe.h (and postgres_ext.h which it includes). Anyone including other headers does so at their own risk. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting to 8.3 beta1
Gregory Stark wrote: What we want to know is that things like pgadmin can connect properly to either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the server authentication is configured. Do they work correctly if the server tries to do password authentication, ident, kerberos, etc. That's a matter of protocol-compatibility, and that's not the issue here. We're talking about *ABI* compatibility. In a nutshell, if you have a an program that's compiled with 8.2 libpq-library, will it work when linked to 8.3 library at runtime? And if you have a program compiled with 8.3 library, does it work with a 8.2 library? But yeah, the regression tests won't help much with that. I suppose you could try to use an 8.2 psql with an 8.3 library and see if it works, but I don't know how much of the library interface psql exercises. I think it's easier and more reliable to just go through the commit logs for libpq, and see if anything has changed. Even that isn't bullet-proof though. For example, if there's an incompatible change to a struct or a typedef that's used as a function parameter, that breaks binary compatibility as well. In the future, we should try to keep this in mind during the development cycle, and bump the minor version number the first time a backwards-compatible change, like adding a new function, is made, and bump the major version number the first time an incompatible change is made. Like we do for catalog version, except that we only want to bump the libpq version number once per release. (though we do sometimes forget to bump the catalog version number as well) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
Zdenek Kotala wrote: Stephen Frost wrote: * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: I'm for bumbing. Because if we use same number it also means that new binary will able to use old library. But if there are two new functions number must be increased. Standard practice how ELF loader works is following: Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores Z number. It means any binaries can be linked e.g. with X.Y.Z+1 or X.Y.Z-1. This is used for bugfixing. Middle number Y means that binaries which requires Y can also use Y+1 (and linker takes it), but not Y-1. It is used for adding new thing into interface - backward compatible. Change in major number X means it is not backward compatible libraries. Right, so bump the minor and leave the major (and the overall 'soname') the same. In PostgreSQL perspective, we use only major number. We can increase main number (X) or best way is add Y and keep major number same. But I don't know if it is possible in current infrastructure and if it will work everywhere. I'm confused by this. I see both in Makefile.shlib and on my system that we have a minor version so I don't entirely follow when you say we use only major number. I'm Sorry for confusion, I overlooked it. You have right. Unfortunately struct Port has been modified and by my opinion it means we must bump major version. See http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63 Uh, that's the backend, not the client lib, no? cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Getting to 8.3 beta1
Stephen Frost [EMAIL PROTECTED] writes: This is where I was suggesting doing something like running the regression tests using old client libraries linked against the new library. If there's a binary-incompatible change then the path is clear. If the regression tests work fine then I'd feel comfortable just bumping the minor version and leaving the real 'soname' alone. Unfortunately the regression tests don't really test the library interface. They test that various forms of SQL work but all with a single client and a single form of authentication. What we want to know is that things like pgadmin can connect properly to either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the server authentication is configured. Do they work correctly if the server tries to do password authentication, ident, kerberos, etc. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
Heikki Linnakangas wrote: Zdenek Kotala wrote: I'm Sorry for confusion, I overlooked it. You have right. Unfortunately struct Port has been modified and by my opinion it means we must bump major version. See http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63 That header file is *not* part of the libpq interface, see the comment at the beginning of the file. So no major version bump required. I see. You are right. I rechecked also install and this file is not delivered. OK green for minor bumping. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting to 8.3 beta1
On 9/27/07, Tom Lane [EMAIL PROTECTED] wrote: * Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. I've modified XML part of wiki page: XML Support * This new data type (XML) validates input for well-formedness and has a set of type-safe operations. * SQL/XML publishing functions, per SQL:2003 * xpath() function for XPath 1.0 expressions evaluation (with Namespaces support) * Alternative XML export function -- Best regards, Nikolay ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
Stephen Frost wrote: * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: I'm for bumbing. Because if we use same number it also means that new binary will able to use old library. But if there are two new functions number must be increased. Standard practice how ELF loader works is following: Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores Z number. It means any binaries can be linked e.g. with X.Y.Z+1 or X.Y.Z-1. This is used for bugfixing. Middle number Y means that binaries which requires Y can also use Y+1 (and linker takes it), but not Y-1. It is used for adding new thing into interface - backward compatible. Change in major number X means it is not backward compatible libraries. Right, so bump the minor and leave the major (and the overall 'soname') the same. In PostgreSQL perspective, we use only major number. We can increase main number (X) or best way is add Y and keep major number same. But I don't know if it is possible in current infrastructure and if it will work everywhere. I'm confused by this. I see both in Makefile.shlib and on my system that we have a minor version so I don't entirely follow when you say we use only major number. I'm Sorry for confusion, I overlooked it. You have right. Unfortunately struct Port has been modified and by my opinion it means we must bump major version. See http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63 Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: AFAICS the correct test would be if (InArchiveRecovery) since needNewTimeLine can only be true iff InArchiveRecovery is true. It's often a good idea to disable archive_mode when doing a recovery to avoid trying to send files to the same archive as the primary, which would then also fail. So requiring XLogArchivingActive() also may not be desirable. Well, that I think is exactly the core of the issue: the input archive area might or might not be the same as the output one. If they're different then this isn't a critical problem; but we have no good way to know that. But your simplification may be a good idea anyway --- the fewer behaviors to think about, the better. Amen to that. Anyway, if you can test this tomorrow that'll be great. I have enough other things to do today ... Looks good to me. I was and am still nervous of weird knock-on effects, but I think its the right patch to apply. There's a whole wedge of new functionality there, so beta should be fun. We need to reword the doc section about time travel, but I'll let you tackle that bit, at least for now. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Getting to 8.3 beta1
Simon Riggs wrote: ...knock-on... tackle Been watching the Rugby World Cup? :) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote: Anyway, if you can test this tomorrow that'll be great. I have enough other things to do today ... Looks good to me. I was and am still nervous of weird knock-on effects, but I think its the right patch to apply. Me too --- committed and back-patched. We need to reword the doc section about time travel, but I'll let you tackle that bit, at least for now. Right, done. BTW, I realized that the reason I objected to your option #4 originally was that I thought you were proposing to make *every* recovery start a new timeline. It's not hard to imagine sorcerer's-apprentice problems in a repeated crash and restart scenario. But actually this is just starting one new timeline per (successful) archive recovery, and each one of those will require manual intervention to kick it off; so it's pretty much impossible to believe an installation would ever create an untenable number of timelines. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 27 Sep 2007, Tom Lane wrote: Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched...I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). I just dumped a copy of Tom's file on my personal page and posted a much slimmed down version that's missing the names of the files touched onto the wiki at http://developer.postgresql.org/index.php/8.3_Changelog (with a pointer to the full text in case anyone needs to dig back into the details to figure out what a commit touched). There was already an outline for building the release notes into at http://developer.postgresql.org/index.php/8.3release What I was thinking might be a useful way for multiple people to hack away at this problem is to start fleshing out the standard release note one-line summaries onto the one page, then delete the relevant commits from the other. When the changelog page is empty, then everything is documented. I didn't actually start doing this though as I didn't want to dump any more time into a process that may not actually be used. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Getting to 8.3 beta1
We're so close I can almost taste it ... Here are the open tasks I can see, does anyone have others? * Review the one remaining patch from Simon that's on Bruce's patch queue page http://momjian.us/cgi-bin/pgpatches (Everything else on that page is either dealt with, mentioned explicitly below, or simply a documentation improvement issue, which need not hold up beta1.) * Deal with the #define FRONTEND issue that Hiroshi Saito is working on (see Warning is adjusted of pgbench thread). * Decide whether we need to change CSVLOG output to emit virtual XIDs instead of, or perhaps in addition to, regular XIDs. I'm of the opinion that this has to happen, but there didn't seem much enthusiasm for it elsewhere. * Pending patches for pre-existing bugs in contrib/pgcrypto --- this doesn't seem like a beta-stopper anyway. * What are we going to do with contrib/tsearch2? Probably not a beta stopper either, but it needs to be decided. * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? * Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. I think we could possibly release 8.3beta1 on Monday, or certainly next week sometime. And I don't know about anyone else, but I'm antsy to get this thing out the door ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Getting to 8.3 beta1
* Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. Pls, add: * Indexes (B-Tree and GiST) could be used for IS NULL clause * User-defined types now could have a type modifiers * nulls first/last could be specified in CREATE INDEX .. USING btree -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-09-27 at 11:22 -0400, Tom Lane wrote: * Review the one remaining patch from Simon that's on Bruce's patch queue page http://momjian.us/cgi-bin/pgpatches (Everything else on that page is either dealt with, mentioned explicitly below, or simply a documentation improvement issue, which need not hold up beta1.) Dang, me again eh? :-) Well, I'm available now and tomorrow to do any further work required. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Getting to 8.3 beta1
On Thursday 27 September 2007 08:22:46 Tom Lane wrote: We're so close I can almost taste it ... Here are the open tasks I can see, does anyone have others? * Review the one remaining patch from Simon that's on Bruce's patch queue page http://momjian.us/cgi-bin/pgpatches (Everything else on that page is either dealt with, mentioned explicitly below, or simply a documentation improvement issue, which need not hold up beta1.) * Deal with the #define FRONTEND issue that Hiroshi Saito is working on (see Warning is adjusted of pgbench thread). * Decide whether we need to change CSVLOG output to emit virtual XIDs instead of, or perhaps in addition to, regular XIDs. I'm of the opinion that this has to happen, but there didn't seem much enthusiasm for it elsewhere. I think it should be both * Pending patches for pre-existing bugs in contrib/pgcrypto --- this doesn't seem like a beta-stopper anyway. * What are we going to do with contrib/tsearch2? Probably not a beta stopper either, but it needs to be decided. * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? +1 on the bump * Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. I think we could possibly release 8.3beta1 on Monday, or certainly next week sometime. And I don't know about anyone else, but I'm antsy to get this thing out the door ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Darcy Buskermolen The PostgreSQL company, Command Prompt Inc. http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
Simon Riggs [EMAIL PROTECTED] writes: Dang, me again eh? :-) Well, I'm available now and tomorrow to do any further work required. Looking back at your original discussion of the bug, http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php I'm wondering why you chose option #3 rather than option #4? I still find the proposed patch a bit crufty. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Getting to 8.3 beta1
I wrote:
Looking back at your original discussion of the bug,
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
I'm wondering why you chose option #3 rather than option #4?
I still find the proposed patch a bit crufty.
In particular, it seems like a patch per #4 would be a one-liner:
*** src/backend/access/transam/xlog.c.orig Wed Sep 26 18:36:30 2007
--- src/backend/access/transam/xlog.c Thu Sep 27 12:20:56 2007
***
*** 5092,5101
*
* If we stopped short of the end of WAL during recovery, then we are
* generating a new timeline and must assign it a unique new ID.
* Otherwise, we can just extend the timeline we were in when we ran out
* of WAL.
*/
! if (needNewTimeLine)
{
ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
ereport(LOG,
--- 5092,5103
*
* If we stopped short of the end of WAL during recovery, then we are
* generating a new timeline and must assign it a unique new ID.
+* We also force a new timeline when recovering from an archive, to
avoid
+* problems with trying to overwrite existing archived segments.
* Otherwise, we can just extend the timeline we were in when we ran out
* of WAL.
*/
! if (needNewTimeLine || (InArchiveRecovery XLogArchivingActive()))
{
ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
ereport(LOG,
though I admit I've not tested this. The comments in
exitArchiveRecovery probably need adjustment too --- re-reading them,
it seems obvious that the current approach is broken by design, because
it *must* lead to an attempt to overwrite a previously archived version
of the last segment.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-09-27 at 12:07 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Dang, me again eh? :-) Well, I'm available now and tomorrow to do any further work required. Looking back at your original discussion of the bug, http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php I'm wondering why you chose option #3 rather than option #4? IIRC you rejected #4 here http://archives.postgresql.org/pgsql-admin/2007-03/msg00237.php I was raising it again 'cos I thought it sensible, and still do. #4 is easy enough to implement, so I worked on #3 so we had a choice. I still find the proposed patch a bit crufty. Your coding is always neater than mine, so we need not debate my cruftiness. There are two parts to the patch as submitted; IIRC the shorter chunk *may* be cosmetic only - though its too far back for me to recall with precision. The main issue is that we send *back* to the archive a file that we just got from it, which is always wrong. Stopping it from doing that in a direct manner seems much neater to me. #4 solves another problem (mentioned in the thread you quote on Admin), so I want that, but I dislike the circuitous manner in which it solves this problem. We'd need to document carefully to avoid a future bug there. I would prefer #3 and #4 together... -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Getting to 8.3 beta1
Tom Lane wrote: * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? I'm not very familiar with library versioning, but the modern solution is to use symbol versioning. In that scheme, a backwards-compatible change, like adding new functions, requires a bump of the minor version number only. I believe all major modern platforms supports symbol versioning. At runtime, the dynamic linker checks that the major version matches the one the appliction is compiled with, and that the version number on each symbol is the same or newer than the one the application was compiled with. I don't know what's required from the build system to support that, but I can find out if no-one else volunteers. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting to 8.3 beta1
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: * Decide whether we need to change CSVLOG output to emit virtual XIDs instead of, or perhaps in addition to, regular XIDs. I'm of the opinion that this has to happen, but there didn't seem much enthusiasm for it elsewhere. Given we have both in log_line_prefix I'm inclined to say we should do both. Works for me. Do you want to fix it or shall I? On other matters, I think it has been sufficiently established that the regression issues with ECPG/MSVC have nothing to do with the build or vcregress scripts, so I am going to go ahead and commit my changes for those ahead of beta. IIUC, that won't break buildfarm results because the MSVC critters are skipping the ecpg tests at present anyway, right? If so, +1. We can work out how to fix the ecpg results during beta. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote: I wrote: Looking back at your original discussion of the bug, http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php I'm wondering why you chose option #3 rather than option #4? I still find the proposed patch a bit crufty. In particular, it seems like a patch per #4 would be a one-liner: Yes, thats my understanding too. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: * Do we bump the .so major version number for libpq? I'm not very familiar with library versioning, but the modern solution is to use symbol versioning. In that scheme, a backwards-compatible change, like adding new functions, requires a bump of the minor version number only. I believe all major modern platforms supports symbol versioning. Yeah, but we are still supporting some not-so-modern platforms. In any case, to go this route we would have to figure out how to make symbol versioning work on *every* supported platform, not only the easy ones. That might be a good long-term goal but I don't want to buy into making it happen for 8.3. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote: In particular, it seems like a patch per #4 would be a one-liner: Yes, thats my understanding too. Do you have time to test that and see if it actually solves the problem? Also, I'm not entirely sure how far back the patch would work; I seem to recall that we've changed some things in that area ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote:
I wrote:
Looking back at your original discussion of the bug,
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00234.php
I'm wondering why you chose option #3 rather than option #4?
I still find the proposed patch a bit crufty.
In particular, it seems like a patch per #4 would be a one-liner:
*** src/backend/access/transam/xlog.c.origWed Sep 26 18:36:30 2007
--- src/backend/access/transam/xlog.c Thu Sep 27 12:20:56 2007
***
*** 5092,5101
*
* If we stopped short of the end of WAL during recovery, then we are
* generating a new timeline and must assign it a unique new ID.
* Otherwise, we can just extend the timeline we were in when we ran out
* of WAL.
*/
! if (needNewTimeLine)
{
ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
ereport(LOG,
--- 5092,5103
*
* If we stopped short of the end of WAL during recovery, then we are
* generating a new timeline and must assign it a unique new ID.
+ * We also force a new timeline when recovering from an archive, to
avoid
+ * problems with trying to overwrite existing archived segments.
* Otherwise, we can just extend the timeline we were in when we ran out
* of WAL.
*/
! if (needNewTimeLine || (InArchiveRecovery XLogArchivingActive()))
{
ThisTimeLineID = findNewestTimeLine(recoveryTargetTLI) + 1;
ereport(LOG,
AFAICS the correct test would be
if (InArchiveRecovery)
since needNewTimeLine can only be true iff InArchiveRecovery is true.
It's often a good idea to disable archive_mode when doing a recovery to
avoid trying to send files to the same archive as the primary, which
would then also fail. So requiring XLogArchivingActive() also may not be
desirable.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Getting to 8.3 beta1
On Thu, 2007-09-27 at 12:45 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2007-09-27 at 12:26 -0400, Tom Lane wrote: In particular, it seems like a patch per #4 would be a one-liner: Yes, thats my understanding too. Do you have time to test that and see if it actually solves the problem? Also, I'm not entirely sure how far back the patch would work; I seem to recall that we've changed some things in that area ... Yes, but I won't be finished until tomorrow. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: * Decide whether we need to change CSVLOG output to emit virtual XIDs instead of, or perhaps in addition to, regular XIDs. I'm of the opinion that this has to happen, but there didn't seem much enthusiasm for it elsewhere. Given we have both in log_line_prefix I'm inclined to say we should do both. Works for me. Do you want to fix it or shall I? If you have a chance please do it - I'm slightly snowed under. It would probably be Sunday before I could look at it. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
Simon Riggs [EMAIL PROTECTED] writes: AFAICS the correct test would be if (InArchiveRecovery) since needNewTimeLine can only be true iff InArchiveRecovery is true. It's often a good idea to disable archive_mode when doing a recovery to avoid trying to send files to the same archive as the primary, which would then also fail. So requiring XLogArchivingActive() also may not be desirable. Well, that I think is exactly the core of the issue: the input archive area might or might not be the same as the output one. If they're different then this isn't a critical problem; but we have no good way to know that. But your simplification may be a good idea anyway --- the fewer behaviors to think about, the better. Anyway, if you can test this tomorrow that'll be great. I have enough other things to do today ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting to 8.3 beta1
On Thu, Sep 27, 2007 at 05:39:11PM +0100, Heikki Linnakangas wrote: I'm not very familiar with library versioning, but the modern solution is to use symbol versioning. In that scheme, a backwards-compatible change, like adding new functions, requires a bump of the minor version number only. I believe all major modern platforms supports symbol versioning. The original patch for controlling the export list on Linux included support for symbol versioning. Eventually a version of the export.list control was committed, but without the versioning (it was rejected for some reason, don't remember why). In any case, to add it now for linux would be a one-line change. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Getting to 8.3 beta1
Martijn van Oosterhout [EMAIL PROTECTED] writes: The original patch for controlling the export list on Linux included support for symbol versioning. Eventually a version of the export.list control was committed, but without the versioning (it was rejected for some reason, don't remember why). My recollection is that it didn't work on older Linuxen. A lot of this would come down to are we willing to discontinue support for platforms that don't have symbol versioning? Without some legwork to find out what that actually means, it's premature to try to make a decision. Anyway I think this is not 8.3 material; it's something to tackle during a fresh development cycle. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
Tom Lane wrote: * Decide whether we need to change CSVLOG output to emit virtual XIDs instead of, or perhaps in addition to, regular XIDs. I'm of the opinion that this has to happen, but there didn't seem much enthusiasm for it elsewhere. Given we have both in log_line_prefix I'm inclined to say we should do both. On other matters, I think it has been sufficiently established that the regression issues with ECPG/MSVC have nothing to do with the build or vcregress scripts, so I am going to go ahead and commit my changes for those ahead of beta. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Getting to 8.3 beta1
On Thu, Sep 27, 2007 at 01:07:33PM -0400, Tom Lane wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: The original patch for controlling the export list on Linux included support for symbol versioning. Eventually a version of the export.list control was committed, but without the versioning (it was rejected for some reason, don't remember why). My recollection is that it didn't work on older Linuxen. Near as I can tell, glibc has been using symbol versioning for nearly 10 years. http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/NEWS.diff?r1=1.24r2=1.25cvsroot=glibcf=h So the chance that there are linux systems out there not supporting it is fairly slim. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Getting to 8.3 beta1
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote: Tom Lane wrote: * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? I'm not very familiar with library versioning, but the modern solution is to use symbol versioning. In that scheme, a backwards-compatible change, like adding new functions, requires a bump of the minor version number only. I believe all major modern platforms supports symbol versioning. You're kind of half-right... The 'modern' solution is symbol versioning, but it's certainly not required. A backwards-compatible change is usually a minor revision bump so that utilities which use the new functions know that they need a more recent version to use it, while old utilities can continue to use the interfaces in place. It should *not* change the soname. Systems do not need symbol versioning support to handle this properly. Stictly speaking, you don't have to change anything. The new library will work for old binaries, that's the primary concern and if functions are only added there's no problem. If you're concerned about new binaries with an old library then bump the minor version. It won't stop them from attempting to link but it's a signal to packagers to update their dependencies accordingly. Few projects have moved to symbol versioning, unfortunately. glibc is the big user of it and they do a good job of it in general. This allows in-place upgrades of glibc and supporting multiple versions of glibc symbols being exported at once. It also means that multiple glibc's can be linked in to a running binary at once. Bumping the soname is an indication of a binary-incompatible change and means that old binaries *can't* link against the new library, and so everything has to be recompiled. Please don't do that unless it really is a binary-incompatible change because it's alot of extra work for packagers to deal with all of their reverse dependencies and getting everyone to recompile. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Getting to 8.3 beta1
Stephen Frost [EMAIL PROTECTED] writes: Tom Lane wrote: * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? Bumping the soname is an indication of a binary-incompatible change and means that old binaries *can't* link against the new library, and so everything has to be recompiled. Please don't do that unless it really is a binary-incompatible change because it's alot of extra work for packagers to deal with all of their reverse dependencies and getting everyone to recompile. It's not only a question of whether old binaries can use the newer library; it's a question of whether a package's dependencies correctly show that it needs the newer library (if it does). Without this, dependency-solving update systems like yum, apt, etc may fail to install prerequisite updates. If we can skip the compatibility-package pushup this time around, I'll be as happy as anyone. But I'm worried about getting into the kind of mess we had in 8.0, where we decided *after* release that we needed a soname bump :-( Anyone on -packagers want to weigh in on this? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
* Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Bumping the soname is an indication of a binary-incompatible change and means that old binaries *can't* link against the new library, and so everything has to be recompiled. Please don't do that unless it really is a binary-incompatible change because it's alot of extra work for packagers to deal with all of their reverse dependencies and getting everyone to recompile. It's not only a question of whether old binaries can use the newer library; it's a question of whether a package's dependencies correctly show that it needs the newer library (if it does). Without this, dependency-solving update systems like yum, apt, etc may fail to install prerequisite updates. Right, the minor version bump tells the maintainer (and/or if he/she follows the dev lists/release notes) to adjust the dependencies. The maintainer would then adjust, at least on Debian, the shlibs files when building the new library and packages using dh_makeshlibs, dh_shlibdeps, dpkg-shlibdeps, etc would pick up on the new dependency. The new version of the library will be installed whenever it's scheduled to be upgraded, or immediately if new binaries that have been compiled against it are also being installed. Technically, that's strictly harsher than it has to be, but if you're recompiling you might as well require the latest ABI even if you don't use the new functions. Figuring out if the new functions are being used or not so that you could perhaps allow for use of an older library is probably more trouble than it's worth and would require much more complicated dependencies that would buy very little... If we can skip the compatibility-package pushup this time around, I'll be as happy as anyone. But I'm worried about getting into the kind of mess we had in 8.0, where we decided *after* release that we needed a soname bump :-( I agree, that's certainly quite ugly, but if we've only added functions and not changed existing function ABIs at all then I can't see any reason why that would happen here. We're quite confident there have been only new funcs, right? Would it be possible to run the regression tests with an older binary and the libraries from HEAD? I would think that would be a good test if we're unsure. Of course, that would be problematic if the PG binaries use unexported symbols in the libraries which changed between the releases (that's rather nasty to do, imv, but it certainly wouldn't be the first time I've seen it done in a project). We could test some non-PG binaries in that case, of course, but it wouldn't be as good a test. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Getting to 8.3 beta1
[EMAIL PROTECTED] (Teodor Sigaev) writes: * Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. Pls, add: * Indexes (B-Tree and GiST) could be used for IS NULL clause * User-defined types now could have a type modifiers * nulls first/last could be specified in CREATE INDEX .. USING btree The third item was already on the list; I have added the other two, but don't have much explanation for them... -- let name=cbbrowne and tld=cbbrowne.com in name ^ @ ^ tld;; http://www3.sympatico.ca/cbbrowne/multiplexor.html In man-machine symbiosis, it is man who must adjust: The machines can't. -- Alan J. Perlis ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
Tom Lane wrote: Stephen Frost [EMAIL PROTECTED] writes: Tom Lane wrote: * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? Bumping the soname is an indication of a binary-incompatible change and means that old binaries *can't* link against the new library, and so everything has to be recompiled. Please don't do that unless it really is a binary-incompatible change because it's alot of extra work for packagers to deal with all of their reverse dependencies and getting everyone to recompile. It's not only a question of whether old binaries can use the newer library; it's a question of whether a package's dependencies correctly show that it needs the newer library (if it does). Without this, dependency-solving update systems like yum, apt, etc may fail to install prerequisite updates. If we can skip the compatibility-package pushup this time around, I'll be as happy as anyone. But I'm worried about getting into the kind of mess we had in 8.0, where we decided *after* release that we needed a soname bump :-( Anyone on -packagers want to weigh in on this? I'm for bumbing. Because if we use same number it also means that new binary will able to use old library. But if there are two new functions number must be increased. Standard practice how ELF loader works is following: Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores Z number. It means any binaries can be linked e.g. with X.Y.Z+1 or X.Y.Z-1. This is used for bugfixing. Middle number Y means that binaries which requires Y can also use Y+1 (and linker takes it), but not Y-1. It is used for adding new thing into interface - backward compatible. Change in major number X means it is not backward compatible libraries. More information you can get there: http://www.iecc.com/linker/ In PostgreSQL perspective, we use only major number. We can increase main number (X) or best way is add Y and keep major number same. But I don't know if it is possible in current infrastructure and if it will work everywhere. Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Getting to 8.3 beta1
Tom Lane wrote: We're so close I can almost taste it ... Here are the open tasks I can see, does anyone have others? * Pending patches for pre-existing bugs in contrib/pgcrypto --- this doesn't seem like a beta-stopper anyway. I agree It is not show stooper for beta. In emergency case patch should be split to two separate patches. One is easy and fix core dump problem. Second part is more complicated and Marko works on adjustment. But I don't think that it is necessary for beta. Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Getting to 8.3 beta1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: We're so close I can almost taste it ... Here are the open tasks I can see, does anyone have others? * What are we going to do with contrib/tsearch2? Probably not a beta stopper either, but it needs to be decided. IMO, we loose contrib/tsearch2. I think it will be confusing and cause problems to have both. I think we could possibly release 8.3beta1 on Monday, or certainly next week sometime. And I don't know about anyone else, but I'm antsy to get this thing out the door ... +1 Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG/CgVATb/zqfZUUQRAo2ZAJ98mVUJSrnnhxsI7ScnFO0sXHUzXQCeOuph FllSKn/XvdWfjuvxNF9IfEw= =lLk1 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Getting to 8.3 beta1
Tom Lane [EMAIL PROTECTED] writes: Stephen Frost [EMAIL PROTECTED] writes: Tom Lane wrote: * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? Bumping the soname is an indication of a binary-incompatible change and means that old binaries *can't* link against the new library, and so everything has to be recompiled. Please don't do that unless it really is a binary-incompatible change because it's alot of extra work for packagers to deal with all of their reverse dependencies and getting everyone to recompile. It's not only a question of whether old binaries can use the newer library; it's a question of whether a package's dependencies correctly show that it needs the newer library (if it does). Without this, dependency-solving update systems like yum, apt, etc may fail to install prerequisite updates. Well either way would work for apt. It notices the version of the library installed when you build a package and records that version as the dependency of the package. If you don't bump then it means you can only have one version of libpq installed at the same time. When installing the new libpq from the 8.3 packages all existing packages would immediately start using it. Any packages built while the new library was installed would claim to depend on the new version (unless the packager overrode the automatic shlib dependency). If you do bump then it means you can keep both copies of the library installed. All old packages would continue to use the old library until they're rebuilt. If they're rebuilt when the new package is installed then they'll start depending on the new version. I'm not sure how yum works, does it not handle this case? Separately are we really sure the shared libraries are completely binary compatible? Didn't the password authentication do something tricky? If you have existing binaries there's no case where they'll break if you swap the shared library out from under them? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-packagers] [HACKERS] Getting to 8.3 beta1
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: I'm for bumbing. Because if we use same number it also means that new binary will able to use old library. But if there are two new functions number must be increased. Standard practice how ELF loader works is following: Each library could have tree numbers libxxx-X.Y.Z. Loader/Linker ignores Z number. It means any binaries can be linked e.g. with X.Y.Z+1 or X.Y.Z-1. This is used for bugfixing. Middle number Y means that binaries which requires Y can also use Y+1 (and linker takes it), but not Y-1. It is used for adding new thing into interface - backward compatible. Change in major number X means it is not backward compatible libraries. Right, so bump the minor and leave the major (and the overall 'soname') the same. In PostgreSQL perspective, we use only major number. We can increase main number (X) or best way is add Y and keep major number same. But I don't know if it is possible in current infrastructure and if it will work everywhere. I'm confused by this. I see both in Makefile.shlib and on my system that we have a minor version so I don't entirely follow when you say we use only major number. In practice, at least on Debian, all that really matters is that the maintainer update the Debian 'shlibs' for the library so that new compilations depend on the newer version. He can gather that needs to be done through a number of different ways, but bumping the minor version is a common and sensible way in general. Bumping the major version forces recompilation for anything which depends on the library and is alot of wasted effort when it's unnecessary. It's not sensible for individual distros to change the soname either though since that would cause all kinds of cross-distro issues and confusion. It really needs to be handled upstream, and handled correctly. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Getting to 8.3 beta1
* Gregory Stark ([EMAIL PROTECTED]) wrote: Tom Lane [EMAIL PROTECTED] writes: Stephen Frost [EMAIL PROTECTED] writes: Bumping the soname is an indication of a binary-incompatible change and means that old binaries *can't* link against the new library, and so everything has to be recompiled. Please don't do that unless it really is a binary-incompatible change because it's alot of extra work for packagers to deal with all of their reverse dependencies and getting everyone to recompile. It's not only a question of whether old binaries can use the newer library; it's a question of whether a package's dependencies correctly show that it needs the newer library (if it does). Without this, dependency-solving update systems like yum, apt, etc may fail to install prerequisite updates. Well either way would work for apt. It notices the version of the library installed when you build a package and records that version as the dependency of the package. More specifically, it records the shlibs of the library into the dependency of the package being built. That is *not* the same as the exact version of the particular library being being against. The shlibs shouldn't ever be *higher* than the version of the library, but it can, and often is, *lower*. If you don't bump then it means you can only have one version of libpq installed at the same time. When installing the new libpq from the 8.3 packages all existing packages would immediately start using it. Any packages built while the new library was installed would claim to depend on the new version (unless the packager overrode the automatic shlib dependency). Right, assuming that we're talking about a case where there was some backward-compatible change in the ABI (functions were added), as in this case. If you do bump then it means you can keep both copies of the library installed. All old packages would continue to use the old library until they're rebuilt. If they're rebuilt when the new package is installed then they'll start depending on the new version. This really is rather ugly when you have to deal with it though. It means that packages *have* to be rebuilt to use the new library and it makes it a huge pain to get rid of the old library. It also puts you in the ugly and annoying situation that both libraries can end up linked into the same running binary. I'm not sure how yum works, does it not handle this case? Yeah, I'm not familiar with non-Debian systems, though the major/minor approach to libraries is used on most systems I've had occation to work with. Though, honestly, on the commercial (Sun, Irix, HPUX, etc) systems I've run into, the admins tend to ignore the whole issue entirely and just recompile/upgrade everything anyway. It's been a while tho, so perhaps things have changed. Separately are we really sure the shared libraries are completely binary compatible? Didn't the password authentication do something tricky? If you have existing binaries there's no case where they'll break if you swap the shared library out from under them? This is where I was suggesting doing something like running the regression tests using old client libraries linked against the new library. If there's a binary-incompatible change then the path is clear. If the regression tests work fine then I'd feel comfortable just bumping the minor version and leaving the real 'soname' alone. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Getting to 8.3 beta1
We're so close I can almost taste it ... Here are the open tasks I can see, does anyone have others? * Review the one remaining patch from Simon that's on Bruce's patch queue page http://momjian.us/cgi-bin/pgpatches (Everything else on that page is either dealt with, mentioned explicitly below, or simply a documentation improvement issue, which need not hold up beta1.) * Deal with the #define FRONTEND issue that Hiroshi Saito is working on (see Warning is adjusted of pgbench thread). * Decide whether we need to change CSVLOG output to emit virtual XIDs instead of, or perhaps in addition to, regular XIDs. I'm of the opinion that this has to happen, but there didn't seem much enthusiasm for it elsewhere. * Pending patches for pre-existing bugs in contrib/pgcrypto --- this doesn't seem like a beta-stopper anyway. * What are we going to do with contrib/tsearch2? Probably not a beta stopper either, but it needs to be decided. * Do we bump the .so major version number for libpq? I think we should because there are two new exported functions since 8.2, and on at least some platforms there's nothing else than major number to disambiguate whether a client needs these or not. Comments? * Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. I see no problem here. However the list looks to miss some 8.3 features (for example JIS2004 support). Also it lacks mentioning the imcompatibilty with earilier version or removed features. Since I have to prepare Japanese materials for 8.3 to promote it anyway, it's ok for me. I have already made presentations about 8.3 last month and this month, and am going to write one or two articles for some publishers in Japan. I believe 8.3 is one of the greatest versions since PostgreSQL was born. I would like to promote 8.3's superiorly as much as possible. I would like to say thank you to everyone who have been working hard for 8.3! -- Tatsuo Ishii SRA OSS, Inc. Japan I think we could possibly release 8.3beta1 on Monday, or certainly next week sometime. And I don't know about anyone else, but I'm antsy to get this thing out the door ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting to 8.3 beta1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched. After cutting out docs-only commits, issues that were also back-patched (and hence are release-noted already), bug fixes to new-in-8.3 code, etc, there were still nearly 300 messages that seem interesting for release-note purposes. We've been busy. I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). I'd be happy to send it off-list to anyone who is interested in trying to distill some preliminary release notes. I would be happy to give it a shot. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG/HadATb/zqfZUUQRAuhfAJ0chJp3zIWBh/TZhMcrtdW/v9oByQCZAXo1 PahgKEFqgJJovdcVem0Kjl8= =cMXa -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Getting to 8.3 beta1
Tatsuo Ishii [EMAIL PROTECTED] writes: * Draft release notes --- can't really ship a beta without these, else beta testers won't know what to test. Traditionally this has taken a fair amount of time, but I wonder whether we couldn't use http://developer.postgresql.org/index.php/WhatsNew83 for at least the first cut. I see no problem here. However the list looks to miss some 8.3 features (for example JIS2004 support). Also it lacks mentioning the imcompatibilty with earilier version or removed features. Anyone want to add those points to the wiki page? Also, I spent a dreary two or three hours this afternoon examining the CVS commit logs since 8.3 branched. After cutting out docs-only commits, issues that were also back-patched (and hence are release-noted already), bug fixes to new-in-8.3 code, etc, there were still nearly 300 messages that seem interesting for release-note purposes. We've been busy. I tried to post that info to pgsql-docs but it broke the list's message size limits (even gzipped, it's about 90K). I'd be happy to send it off-list to anyone who is interested in trying to distill some preliminary release notes. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Getting to 8.3 beta1
Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: * What are we going to do with contrib/tsearch2? Probably not a beta stopper either, but it needs to be decided. IMO, we loose contrib/tsearch2. I think it will be confusing and cause problems to have both. Certainly we aren't going to ship it as-is. What I was wondering was whether there was any use in creating a backwards-compatibility package for current users of tsearch2 --- and if so whether anyone felt like making that happen. If not, we'll just cvs remove the thing before 8.3 final release; but I'm throwing the point out as something that somebody might want to work on before final. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Getting to 8.3 beta1
IMO, we loose contrib/tsearch2. I think it will be confusing and cause problems to have both. Certainly we aren't going to ship it as-is. What I was wondering was whether there was any use in creating a backwards-compatibility package for current users of tsearch2 --- and if so whether anyone felt like making that happen. If not, we'll just cvs remove the thing before 8.3 final release; but I'm throwing the point out as something that somebody might want to work on before final. Hello, next week I can work on it. I expect so compatibility functions will be only sql wrappers Regards Pavel Stehule ---(end of broadcast)--- TIP 6: explain analyze is your friend
