Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-13 Thread Simon Riggs
On Wed, 2007-09-12 at 10:48 -0400, Tom Lane wrote:
 Simon Riggs [EMAIL PROTECTED] writes:
  The following bug fix has not yet been applied to CVS
  http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php
 
 Frankly, this looks much more like it creates a bug than fixes one.
 I have not looked at all of the original thread, but this adds a wart
 (two warts, really) that seems certain to do the wrong thing in cases
 other than the one you are thinking of.

Well, that's not a great help for anybody.

What next action do you propose?

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


---(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] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-13 Thread Simon Riggs
On Wed, 2007-09-12 at 10:48 -0400, Tom Lane wrote:
 Simon Riggs [EMAIL PROTECTED] writes:
  The following bug fix has not yet been applied to CVS
  http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php
 
 Frankly, this looks much more like it creates a bug than fixes one.
 I have not looked at all of the original thread, but this adds a wart
 (two warts, really) that seems certain to do the wrong thing in cases
 other than the one you are thinking of.

Let me explain the bug and the fix briefly.

The current recovery code allows a file to be archived a second time,
which will fail if the archive_command is strict and refuses duplicate
files. The second failure occurs only in disaster mode, when we have no
partially written files from the failing server. The bug is fatal, but
there is an easy workaround, if you know it. The manual says this should
work and it does not.

I have added code that prevents a file from being archived when we know
for certain it has already been archived because we just de-archived it
during recovery. 

The fix also closes a loophole in XLogArchiveNotify by stopping the
writing of a .ready file if a .done already exists.

These actions fix the bug directly, following the main design.

-- 
  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] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-13 Thread Magnus Hagander
On Thu, Sep 13, 2007 at 12:12:28AM +0200, Guillaume Lelarge wrote:
 Tom Lane a écrit :
  Dave Page [EMAIL PROTECTED] writes:
  Tom Lane wrote:
  Peter usually does it --- in theory any committer could, but he actually
  knows what to do and the rest of us would have to study ;-)
  
  Study or figure it out? If it hasn't already been it should be 
  documented as part of the release process.
  
  Well, RELEASE_CHANGES has
  
  * Translation updates
  Translations are kept in the project pgtranslation on PgFoundry.
  1. Check out the messages module (of the right branch).
  2. Check out the admin module.
  3. Run sh .../admin/cp-po .../messages .../pgsql
  4. Commit.
  
  but it's not real clear (to me) which is the right branch
 
 They are named the same way PostgreSQL named its branches. For example
 REL8_2 for PostgreSQL 8.2.
 
 They are available here :
   http://pgfoundry.org/scm/?group_id=164
 
  and what the ...s signify.
 
 .../admin/cp-po : ... is the path to the cp-po shell script you get when
 you did step 2 (Check out the admin module).
 
 .../messages : ... is the path to the messages branch you get when you
 did step 1 (Check out the messages module...)
 
 .../pgsql : ... is the path to your source dir (same branch as messages)
 
  It's not a big knowledge gap but I have other things
  to worry about ...
 
 It seems pretty straightforward now. Perhaps it can be used with cron.

No. Doing that with cron is a really bad idea, imho. We do *not* want any
automated commits going into the tree. If we wanted that, why did we bother
breaking it out in the first place, and not just give everybody commit
access, which would be the same thing?

That said, it seems easy enough. I'll be happy to help doing it, but I
don't want to step on the toes of someone already working on it. Peter -
let me know if you want help mergeing them for this release - I'm availabel
to help with that today or tomorrow.

//Magnus

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-13 Thread Guillaume Lelarge
Magnus Hagander a écrit :
 On Thu, Sep 13, 2007 at 12:12:28AM +0200, Guillaume Lelarge wrote:
 [...]
 It seems pretty straightforward now. Perhaps it can be used with cron.
 
 No. Doing that with cron is a really bad idea, imho. We do *not* want any
 automated commits going into the tree. If we wanted that, why did we bother
 breaking it out in the first place, and not just give everybody commit
 access, which would be the same thing?
 

You're right. I haven't thought of that.

 That said, it seems easy enough. I'll be happy to help doing it, but I
 don't want to step on the toes of someone already working on it. Peter -
 let me know if you want help mergeing them for this release - I'm availabel
 to help with that today or tomorrow.
 

Peter just sent a message on pgtranslation's mailing list, asking us
(translators) to put our updates in pgtranslation's CVS ASAP. He'll
synchronize the translations tonight.

Thanks anyway.

Regards.


-- 
Guillaume.
http://www.postgresqlfr.org/
http://dalibo.com/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Guillaume Lelarge
Tom Lane a écrit :
 Bruce Momjian [EMAIL PROTECTED] writes:
 Alvaro Herrera wrote:
 Does this mean that if I commit something in these days to those
 branches, it will not show up in the releases?
 
 It certainly will show up if you do it before the packagers pull their
 CVS copies.
 
 No, it will show up if you do it before Marc cvs tags the release.
 Which I am currently thinking shouldn't happen till Friday or so.
 

Is it Marc's job to sync the translation on PostgreSQL CVS with those
from the pgtranslation project ? I remember this is a part of the build
process but I don't know who does this.

Thanks.

Regards.


-- 
Guillaume.
http://www.postgresqlfr.org/
http://dalibo.com/

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Dave Page

Guillaume Lelarge wrote:

Tom Lane a écrit :

Bruce Momjian [EMAIL PROTECTED] writes:

Alvaro Herrera wrote:

Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?

It certainly will show up if you do it before the packagers pull their
CVS copies.

No, it will show up if you do it before Marc cvs tags the release.
Which I am currently thinking shouldn't happen till Friday or so.



Is it Marc's job to sync the translation on PostgreSQL CVS with those
from the pgtranslation project ? I remember this is a part of the build
process but I don't know who does this.


No, thats Peter.

I'm not sure if he usually does it for point releases though.

Regards, Dave

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Guillaume Lelarge
Dave Page a écrit :
 Guillaume Lelarge wrote:
 Tom Lane a écrit :
 Bruce Momjian [EMAIL PROTECTED] writes:
 Alvaro Herrera wrote:
 Does this mean that if I commit something in these days to those
 branches, it will not show up in the releases?
 It certainly will show up if you do it before the packagers pull their
 CVS copies.
 No, it will show up if you do it before Marc cvs tags the release.
 Which I am currently thinking shouldn't happen till Friday or so.


 Is it Marc's job to sync the translation on PostgreSQL CVS with those
 from the pgtranslation project ? I remember this is a part of the build
 process but I don't know who does this.
 
 No, thats Peter.
 
 I'm not sure if he usually does it for point releases though.
 

I hope he already did it for minor releases. If not, I wonder why
pgtranslation project has major branches.

I really need to see this happening at least on these minor releases. I
worked a lot on the .po files from 7.4, 8.0, 8.1 and 8.2, fixing some
translation's issues, fine-tuning the translations. Why isn't there
some kind of automatic process that sync the translations, once per
month for example ? if this can be done, I can work on this.


-- 
Guillaume.
http://www.postgresqlfr.org/
http://dalibo.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] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Simon Riggs
On Tue, 2007-09-11 at 18:56 -0400, Bruce Momjian wrote:

 Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
 8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
 releases will happen sometime early next week.  The packagers have been
 contacted.

The following bug fix has not yet been applied to CVS
http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php

It needs to be applied to CVS HEAD and REL8_2_STABLE. 

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


---(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] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Tom Lane
Dave Page [EMAIL PROTECTED] writes:
 Guillaume Lelarge wrote:
 Is it Marc's job to sync the translation on PostgreSQL CVS with those
 from the pgtranslation project ? I remember this is a part of the build
 process but I don't know who does this.

 No, thats Peter.

Peter usually does it --- in theory any committer could, but he actually
knows what to do and the rest of us would have to study ;-)

Peter, have you got time to sync the translation files before Friday?

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Dave Page

Tom Lane wrote:

Dave Page [EMAIL PROTECTED] writes:

Guillaume Lelarge wrote:

Is it Marc's job to sync the translation on PostgreSQL CVS with those
from the pgtranslation project ? I remember this is a part of the build
process but I don't know who does this.



No, thats Peter.


Peter usually does it --- in theory any committer could, but he actually
knows what to do and the rest of us would have to study ;-)


Study or figure it out? If it hasn't already been it should be 
documented as part of the release process.


/D

---(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] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
 The following bug fix has not yet been applied to CVS
 http://archives.postgresql.org/pgsql-patches/2007-06/msg00100.php

Frankly, this looks much more like it creates a bug than fixes one.
I have not looked at all of the original thread, but this adds a wart
(two warts, really) that seems certain to do the wrong thing in cases
other than the one you are thinking of.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Tom Lane
Dave Page [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 Peter usually does it --- in theory any committer could, but he actually
 knows what to do and the rest of us would have to study ;-)

 Study or figure it out? If it hasn't already been it should be 
 documented as part of the release process.

Well, RELEASE_CHANGES has

* Translation updates
Translations are kept in the project pgtranslation on PgFoundry.
1. Check out the messages module (of the right branch).
2. Check out the admin module.
3. Run sh .../admin/cp-po .../messages .../pgsql
4. Commit.

but it's not real clear (to me) which is the right branch and what
the ...s signify.  It's not a big knowledge gap but I have other things
to worry about ...

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] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-12 Thread Guillaume Lelarge
Tom Lane a écrit :
 Dave Page [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 Peter usually does it --- in theory any committer could, but he actually
 knows what to do and the rest of us would have to study ;-)
 
 Study or figure it out? If it hasn't already been it should be 
 documented as part of the release process.
 
 Well, RELEASE_CHANGES has
 
 * Translation updates
   Translations are kept in the project pgtranslation on PgFoundry.
   1. Check out the messages module (of the right branch).
   2. Check out the admin module.
   3. Run sh .../admin/cp-po .../messages .../pgsql
   4. Commit.
 
 but it's not real clear (to me) which is the right branch

They are named the same way PostgreSQL named its branches. For example
REL8_2 for PostgreSQL 8.2.

They are available here :
  http://pgfoundry.org/scm/?group_id=164

 and what the ...s signify.

.../admin/cp-po : ... is the path to the cp-po shell script you get when
you did step 2 (Check out the admin module).

.../messages : ... is the path to the messages branch you get when you
did step 1 (Check out the messages module...)

.../pgsql : ... is the path to your source dir (same branch as messages)

 It's not a big knowledge gap but I have other things
 to worry about ...

It seems pretty straightforward now. Perhaps it can be used with cron.

Regards.


-- 
Guillaume.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-11 Thread Alvaro Herrera
Bruce Momjian wrote:
 Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
 8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
 releases will happen sometime early next week.  The packagers have been
 contacted.

Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20

2007-09-11 Thread Bruce Momjian
Alvaro Herrera wrote:
 Bruce Momjian wrote:
  Preparations are being made for PostgreSQL releases 8.2.5, 8.1.10,
  8.0.14, 7.4.18, 7.3.20.  The CVS branches are nearly ready.  The
  releases will happen sometime early next week.  The packagers have been
  contacted.
 
 Does this mean that if I commit something in these days to those
 branches, it will not show up in the releases?

It certainly will show up if you do it before the packagers pull their
CVS copies.  Right now configure/configure.in are not stamped so it is
impossible for a packager to use it.  I would check those files before
making changes to be sure.

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate