Re: [HACKERS] Getting to 8.3 beta1

2007-10-08 Thread Bruce Momjian
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

2007-10-04 Thread Guillaume Smet
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

2007-10-04 Thread Neil Conway
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

2007-10-03 Thread Joshua D. Drake
-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

2007-10-03 Thread Alvaro Herrera
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

2007-10-03 Thread Joshua D. Drake
-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

2007-10-03 Thread Tom Lane
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

2007-09-28 Thread Zeugswetter Andreas ADI SD

  * 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

2007-09-28 Thread Stephen Frost
* 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: [HACKERS] Getting to 8.3 beta1

2007-09-28 Thread Heikki Linnakangas
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: [HACKERS] Getting to 8.3 beta1

2007-09-28 Thread Gregory Stark
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: [HACKERS] Getting to 8.3 beta1

2007-09-28 Thread Nikolay Samokhvalov
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: [HACKERS] Getting to 8.3 beta1

2007-09-28 Thread Simon Riggs
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

2007-09-28 Thread Bricklen Anderson

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

2007-09-28 Thread Tom Lane
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

2007-09-28 Thread Greg Smith

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


Re: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Teodor Sigaev

* 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

2007-09-27 Thread Simon Riggs
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

2007-09-27 Thread Darcy Buskermolen
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Simon Riggs
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

2007-09-27 Thread Heikki Linnakangas
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Simon Riggs
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Simon Riggs
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

2007-09-27 Thread Simon Riggs
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

2007-09-27 Thread Andrew Dunstan



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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Martijn van Oosterhout
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Andrew Dunstan



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

2007-09-27 Thread Martijn van Oosterhout
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

2007-09-27 Thread Stephen Frost
* 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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Stephen Frost
* 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

2007-09-27 Thread Chris Browne
[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: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Zdenek . Kotala

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

2007-09-27 Thread Joshua D. Drake
-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

2007-09-27 Thread Gregory Stark
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: [HACKERS] Getting to 8.3 beta1

2007-09-27 Thread Stephen Frost
* 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

2007-09-27 Thread Tatsuo Ishii
 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

2007-09-27 Thread Joshua D. Drake
-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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Tom Lane
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

2007-09-27 Thread Pavel Stehule
  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