Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20
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
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
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
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
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
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
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
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
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
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
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 tag"s 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
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 tag"s 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
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 tag"s 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
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 tag"s the release. Which I am currently thinking shouldn't happen till Friday or so. Please do be sure to get that CHECK_FOR_INTERRUPTS fix in there. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20
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
Re: [HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20
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
[HACKERS] Preparation for PostgreSQL releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20
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. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq