Обсуждение: Re: Skytools committed without hackers discussion/review
Jan Wieck wrote: > > I don't see how timing has anything to do with this. You could have > > added it between beta1 and beta2 after sufficient hackers discussion. > > Doing it the way you did with no warning, right before beta, and then > > leaving is the worse of all times. I am surprised we are not backing > > out the patch and requiring that the patch go through the formal review > > process. > > > > This is not the first time you have had trouble with patches. There was > > an issue with your patch of February, 2007: > > > > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00385.php > > That email might contain the keyword COMMIT, but it doesn't have to do > with anything I committed to CVS. The trigger changes you are referring > to have been discussed and a patch for discussion was presented here: > > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00146.php Right, but at the time you didn't want to give a good explaination and I had to ask for it. That should not have been necessary. > > (In summary, you had to be coaxed to explain your patch to the > > community.) Basically, I am not sure you understand the process that > > has to be followed, or feel you are somehow immune from following it. > > I don't see how you leap from the above example to that conclusion. You have had only a few commits in 2007, and there have been two problems. That ratio seems too high to me, hence my questions above. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On 10/9/2007 4:22 PM, Bruce Momjian wrote: > Jan Wieck wrote: >> > I don't see how timing has anything to do with this. You could have >> > added it between beta1 and beta2 after sufficient hackers discussion. >> > Doing it the way you did with no warning, right before beta, and then >> > leaving is the worse of all times. I am surprised we are not backing >> > out the patch and requiring that the patch go through the formal review >> > process. >> > >> > This is not the first time you have had trouble with patches. There was >> > an issue with your patch of February, 2007: >> > >> > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00385.php >> >> That email might contain the keyword COMMIT, but it doesn't have to do >> with anything I committed to CVS. The trigger changes you are referring >> to have been discussed and a patch for discussion was presented here: >> >> http://archives.postgresql.org/pgsql-hackers/2007-02/msg00146.php > > Right, but at the time you didn't want to give a good explaination and I > had to ask for it. That should not have been necessary. > >> > (In summary, you had to be coaxed to explain your patch to the >> > community.) Basically, I am not sure you understand the process that >> > has to be followed, or feel you are somehow immune from following it. >> >> I don't see how you leap from the above example to that conclusion. > > You have had only a few commits in 2007, and there have been two > problems. That ratio seems too high to me, hence my questions above. You are misrepresenting the situation. The discussion about the commit timestamp, where you asked for a complete functional specification of a multimaster replication system based on it before anything should be done feature wise at all, was not about any CVS activity that happened. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > On 10/9/2007 4:22 PM, Bruce Momjian wrote: > > Jan Wieck wrote: > >> > I don't see how timing has anything to do with this. You could have > >> > added it between beta1 and beta2 after sufficient hackers discussion. > >> > Doing it the way you did with no warning, right before beta, and then > >> > leaving is the worse of all times. I am surprised we are not backing > >> > out the patch and requiring that the patch go through the formal review > >> > process. > >> > > >> > This is not the first time you have had trouble with patches. There was > >> > an issue with your patch of February, 2007: > >> > > >> > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00385.php > > You have had only a few commits in 2007, and there have been two > > problems. That ratio seems too high to me, hence my questions above. > > You are misrepresenting the situation. The discussion about the commit > timestamp, where you asked for a complete functional specification of a > multimaster replication system based on it before anything should be > done feature wise at all, was not about any CVS activity that happened. Here is a quote of exactly what I had to ask for, which I shouldn't have had to ask for: What I did want to hear is a layout of how the system would work,and an exchange of ideas until almost everyone was happy. Also, I saw the trigger patch with no explaination of why it wasimportant or who would use it --- that also isn't going toflywell. So, to add something, the community needs to hear how it is going tohelp users, because every code addition has cost, andwe don't want toadd things unless it has general utility. If someone can't explain theutility of an addition, I questionwhether the person has fully thoughtthrough were they are going. Not sure where you got the "complete functional specification of a multimaster replication system". I go back to my original question, do you understand the process that has to be followed for patch submission/application, and that it applies to all of us, including you? A simple "yes" is all I need to hear. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On 10/9/2007 5:13 PM, Bruce Momjian wrote: > Jan Wieck wrote: >> On 10/9/2007 4:22 PM, Bruce Momjian wrote: >> > Jan Wieck wrote: >> >> > I don't see how timing has anything to do with this. You could have >> >> > added it between beta1 and beta2 after sufficient hackers discussion. >> >> > Doing it the way you did with no warning, right before beta, and then >> >> > leaving is the worse of all times. I am surprised we are not backing >> >> > out the patch and requiring that the patch go through the formal review >> >> > process. >> >> > >> >> > This is not the first time you have had trouble with patches. There was >> >> > an issue with your patch of February, 2007: >> >> > >> >> > http://archives.postgresql.org/pgsql-hackers/2007-02/msg00385.php >> > You have had only a few commits in 2007, and there have been two >> > problems. That ratio seems too high to me, hence my questions above. >> >> You are misrepresenting the situation. The discussion about the commit >> timestamp, where you asked for a complete functional specification of a >> multimaster replication system based on it before anything should be >> done feature wise at all, was not about any CVS activity that happened. > > Here is a quote of exactly what I had to ask for, which I shouldn't have > had to ask for: > > What I did want to hear is a layout of how the system would work, > and an exchange of ideas until almost everyone was happy. > > Also, I saw the trigger patch with no explaination of why it was > important or who would use it --- that also isn't going to fly > well. > > So, to add something, the community needs to hear how it is going to > help users, because every code addition has cost, and we don't want to > add things unless it has general utility. If someone can't explain the > utility of an addition, I question whether the person has fully thought > through were they are going. > > Not sure where you got the "complete functional specification of a > multimaster replication system". > > I go back to my original question, do you understand the process that > has to be followed for patch submission/application, and that it applies > to all of us, including you? A simple "yes" is all I need to hear. > Yes, Sir. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Tue, 2007-10-09 at 17:13 -0400, Bruce Momjian wrote: > I go back to my original question, do you understand the process that > has to be followed for patch submission/application, and that it > applies to all of us, including you? I think you're braking a little hard here. Nothing bad has happened has it? My understanding of committing stuff was about taking responsibility for what's in there. Jan definitely has the knowledge and track record to be trusted, plus we know he has time to fix any mistakes. That close to release, only Core members should be doing that and Jan is Core. Personally, I want to see Jan contribute more, not less. The link with Slony and related replication technology is critically important to Postgres, which is why Jan has spent so long on it. Generally we should be encouraging everybody to contribute; the project must have an orientation towards action and growth if we are to survive. If Jan had not done this, would there have been a storm of protest? Anyway, its a good release and its out now. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Simon Riggs wrote: > That close to > release, only Core members should be doing that and Jan is Core. > > > My understanding (not being a member :-) ) is that Core is an administrative group, not a group of committers. Some members of Core are committers, some not, some committers are in Core, some not. cheers andrew
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote: > Simon Riggs wrote: > > That close to > > release, only Core members should be doing that and Jan is Core. > > > My understanding (not being a member :-) ) is that Core is an > administrative group, not a group of committers. Some members of Core > are committers, some not, some committers are in Core, some not. By observation, all committers are not equal. If they are equal then we must censure others also, as well as Jan, but I see no need personally. If they are not equal, then Jan deserves extra leeway, IMHO. Either way, we should not focus just upon Jan, especially when so many will thank him for his actions. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
On Tue, 09 Oct 2007 17:55:48 -0400
Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> Simon Riggs wrote:
> > That close to
> > release, only Core members should be doing that and Jan is Core.
> >
> >
> >
>
> My understanding (not being a member :-) ) is that Core is an
> administrative group, not a group of committers. Some members of Core
> are committers, some not, some committers are in Core, some not.
That is my understanding as well and has been substantiated buy other
members of core.
Sincerely,
Joshua D. Drake
>
> cheers
>
> andrew
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 1: if posting/reading
> through Usenet, please send an appropriate subscribe-nomail command
> to majordomo@postgresql.org 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/
Andrew Dunstan wrote: > > > Simon Riggs wrote: > > That close to > > release, only Core members should be doing that and Jan is Core. > > > > > > > > My understanding (not being a member :-) ) is that Core is an > administrative group, not a group of committers. Some members of Core > are committers, some not, some committers are in Core, some not. Correct. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Simon Riggs wrote: > On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote: > >> Simon Riggs wrote: >>> That close to >>> release, only Core members should be doing that and Jan is Core. >>> > >> My understanding (not being a member :-) ) is that Core is an >> administrative group, not a group of committers. Some members of Core >> are committers, some not, some committers are in Core, some not. > > By observation, all committers are not equal. If they are equal then we > must censure others also, as well as Jan, but I see no need personally. > If they are not equal, then Jan deserves extra leeway, IMHO. Either way, > we should not focus just upon Jan, especially when so many will thank > him for his actions. Correct, we certainly shouldn't focus on any one person. We should focus upon our own policies - were they broken or not. And if they weren't, it seems that the majority of people want those policies changed (for next time). If they were, what do we do about it? //Magnus
On Wed, 2007-10-10 at 00:19 +0200, Magnus Hagander wrote: > Simon Riggs wrote: > > On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote: > > > >> Simon Riggs wrote: > >>> That close to > >>> release, only Core members should be doing that and Jan is Core. > >>> > > > >> My understanding (not being a member :-) ) is that Core is an > >> administrative group, not a group of committers. Some members of Core > >> are committers, some not, some committers are in Core, some not. > > > > By observation, all committers are not equal. If they are equal then we > > must censure others also, as well as Jan, but I see no need personally. > > If they are not equal, then Jan deserves extra leeway, IMHO. Either way, > > we should not focus just upon Jan, especially when so many will thank > > him for his actions. > > Correct, we certainly shouldn't focus on any one person. We should focus > upon our own policies - were they broken or not. And if they weren't, it > seems that the majority of people want those policies changed (for next > time). If they were, what do we do about it? Well for me: Nothing broke, so we needn't discuss policy at all. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Simon Riggs wrote: > On Wed, 2007-10-10 at 00:19 +0200, Magnus Hagander wrote: >> Simon Riggs wrote: >>> On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote: >>> >>>> Simon Riggs wrote: >>>>> That close to >>>>> release, only Core members should be doing that and Jan is Core. >>>>> >>>> My understanding (not being a member :-) ) is that Core is an >>>> administrative group, not a group of committers. Some members of Core >>>> are committers, some not, some committers are in Core, some not. >>> By observation, all committers are not equal. If they are equal then we >>> must censure others also, as well as Jan, but I see no need personally. >>> If they are not equal, then Jan deserves extra leeway, IMHO. Either way, >>> we should not focus just upon Jan, especially when so many will thank >>> him for his actions. >> Correct, we certainly shouldn't focus on any one person. We should focus >> upon our own policies - were they broken or not. And if they weren't, it >> seems that the majority of people want those policies changed (for next >> time). If they were, what do we do about it? > > Well for me: Nothing broke, so we needn't discuss policy at all. Well, buildfarm broke. But it's been fixed now. Also, does that mean you volunteer to fix pginstaller, and any other packages that needs it? ;-) //Magnus
Simon Riggs wrote: > On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote: > > >> Simon Riggs wrote: >> >>> That close to >>> release, only Core members should be doing that and Jan is Core. >>> >>> > > >> My understanding (not being a member :-) ) is that Core is an >> administrative group, not a group of committers. Some members of Core >> are committers, some not, some committers are in Core, some not. >> > > By observation, all committers are not equal. If they are equal then we > must censure others also, as well as Jan, but I see no need personally. > If they are not equal, then Jan deserves extra leeway, IMHO. Either way, > we should not focus just upon Jan, especially when so many will thank > him for his actions. > > I think this project has got too big for us to make things up as we go along. We need to follow processes that are well understood and transparent. I have tried not to concentrate on Jan in this discussion. It could be argued, however, that contrary to being the recipients of extra slack, core members have a special responsibility to set a good example. cheers andrew
> > > We allow /contrib to be more lax about beta changes. > > > > the postgresql ecosystem is growing and there is a lot of people like > > packagers that will be a quite irritated if we keep randomly adding > > completely new code and modules during BETA. > > Should packagers be concerned with /contrib at all ? Our users want it. Because we have important features that live there. > As noted before /contrib is a technical way of ensuring that something > gets updated together with core, not a recommendation to include it in a > "package". Then why did it get added there with the motivation that a lot of users will want it? /Magnus
Ühel kenal päeval, K, 2007-10-10 kell 07:44, kirjutas Magnus Hagander: > > > > We allow /contrib to be more lax about beta changes. > > > > > > the postgresql ecosystem is growing and there is a lot of people like > > > packagers that will be a quite irritated if we keep randomly adding > > > completely new code and modules during BETA. > > > > Should packagers be concerned with /contrib at all ? > > Our users want it. Because we have important features that live there. Sure, but some features are also moved from /contrib to pgfoundry, and users still may want these too. And sure there are features in contrib that "most" users don't want. > > > As noted before /contrib is a technical way of ensuring that something > > gets updated together with core, not a recommendation to include it in a > > "package". > > Then why did it get added there with the motivation that a lot of users will want it? I think that the main motivation was to ensure that a feature that a lot of users will want will be "stable", that is, maintained together with core postgres. exposing stable xid and snapshot to userspace is something needed by more than one postgres add-on (Slony1 replication, Skytools universal queueing and replication) makes it much easier to develop these packages without need to have an extra package to maintain separately from these, yet in sync with core postgres. ------------ Hannu
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote: > I think this project has got too big for us to make things up as we go > along. We need to follow processes that are well understood and > transparent. Well said, I very much agree. Mostly we do, but since we've just spent more than 6 months between Feature Freeze and Beta. There were no well understood or transparent processes during that period, so nobody is on solid ground trying to enforce a small number of rules with a single individual. Especially when discussing what might be argued was a major item in 8.3 -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
> > > > > We allow /contrib to be more lax about beta changes. > > > > > > > > the postgresql ecosystem is growing and there is a lot of people like > > > > packagers that will be a quite irritated if we keep randomly adding > > > > completely new code and modules during BETA. > > > > > > Should packagers be concerned with /contrib at all ? > > > > Our users want it. Because we have important features that live there. > > Sure, but some features are also moved from /contrib to pgfoundry, and > users still may want these too. Sure. This is why Dave created stackbuilder. The point is users expect us to ship whatever isincluded in core postgresql, which includes contrib. > And sure there are features in contrib that "most" users don't want. Sure. There are features in the backend that most users don't even know about, much less use/want. > > > > > As noted before /contrib is a technical way of ensuring that something > > > gets updated together with core, not a recommendation to include it in a > > > "package". > > > > Then why did it get added there with the motivation that a lot of users will want it? > > I think that the main motivation was to ensure that a feature that a lot > of users will want will be "stable", that is, maintained together with > core postgres. IMSHO, this is far from enough motivation to put something in post beta. I could accept it *with* proper discussion, duringfeature freze. Where the argument of not putting it in contrib, but backend-actual instead, could've been properlymade. > exposing stable xid and snapshot to userspace is something needed by > more than one postgres add-on (Slony1 replication, Skytools universal > queueing and replication) makes it much easier to develop these packages > without need to have an extra package to maintain separately from these, > yet in sync with core postgres. So, it should be in the backend, not contrib. And since we're past beta, that means 8.4. If discussion had happened just a day or two before the comit, we could've delayed beta a day to get it in.... /Magnus
Simon Riggs wrote: > > Personally, I want to see Jan contribute more, not less. The link with > Slony and related replication technology is critically important to > Postgres, which is why Jan has spent so long on it. > > Generally we should be encouraging everybody to contribute; the project > must have an orientation towards action and growth if we are to survive. > If Jan had not done this, would there have been a storm of protest? > > > +1 Having said that, the fact that the discussion happened in a forum other than -hackers is clearly something to be avoided in future (ISTR something similar happening with some changes coming from Bizgres a while ago). I don't know how we can avoid this sort of thing happening every now and again, except to encourage folk to include -hackers in their discussions before sending the final patch in (Bruce and others have stated this previously - maybe we need to re-iterate it few weeks *before* every feature freeze...) Cheers Mark
On Wed, 2007-10-10 at 07:08 +0100, Simon Riggs wrote: > On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote: > > > I think this project has got too big for us to make things up as we go > > along. We need to follow processes that are well understood and > > transparent. > > Well said, I very much agree. > > Mostly we do, but since we've just spent more than 6 months between > Feature Freeze and Beta. There were no well understood or transparent > processes during that period, so nobody is on solid ground trying to > enforce a small number of rules with a single individual. Especially > when discussing what might be argued was a major item in 8.3 I should add that I'm not unhappy about how things have happened and I have no complaints to lodge anywhere with anybody. Just wanted to give Jan a bit of moral support, and I've done that now, so time for me to stop. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Simon Riggs wrote: > On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote: > > > I think this project has got too big for us to make things up as we go > > along. We need to follow processes that are well understood and > > transparent. > > Well said, I very much agree. > > Mostly we do, but since we've just spent more than 6 months between > Feature Freeze and Beta. There were no well understood or transparent > processes during that period, so nobody is on solid ground trying to > enforce a small number of rules with a single individual. Especially > when discussing what might be argued was a major item in 8.3 What? Even Jan agrees he didn't follow the procedures. I have no idea how you are coming to the conclusion there are no well understood processes. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Hi, On Wed, 2007-10-10 at 09:19 +0100, Simon Riggs wrote: > I should add that I'm not unhappy about how things have happened and I > have no complaints to lodge anywhere with anybody. Just wanted to give > Jan a bit of moral support I have the same feelings, so +1. Regards, -- Devrim GÜNDÜZ PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
On Wed, 2007-10-10 at 10:29 -0400, Bruce Momjian wrote: > Simon Riggs wrote: > > Mostly we do, but since we've just spent more than 6 months between > > Feature Freeze and Beta. There were no well understood or transparent > > processes during that period, so nobody is on solid ground trying to > > enforce a small number of rules with a single individual. Especially > > when discussing what might be argued was a major item in 8.3 > > What? Even Jan agrees he didn't follow the procedures. I have no idea > how you are coming to the conclusion there are no well understood > processes. Results look good to me, so I'm not lodging a complaint, just explaining my position. The main rule is discuss-it-first-on-Hackers and if Jan didn't follow that then he is wrong. But since he nearly got it right by discussing it with some people, nothing bad happened and the outcome is worth having I don't see why we would want to pick Jan up for anything, or back-out those changes. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Simon Riggs wrote: > On Wed, 2007-10-10 at 10:29 -0400, Bruce Momjian wrote: > > Simon Riggs wrote: > > > > Mostly we do, but since we've just spent more than 6 months between > > > Feature Freeze and Beta. There were no well understood or transparent > > > processes during that period, so nobody is on solid ground trying to > > > enforce a small number of rules with a single individual. Especially > > > when discussing what might be argued was a major item in 8.3 > > > > What? Even Jan agrees he didn't follow the procedures. I have no idea > > how you are coming to the conclusion there are no well understood > > processes. > > Results look good to me, so I'm not lodging a complaint, just explaining > my position. > > The main rule is discuss-it-first-on-Hackers and if Jan didn't follow > that then he is wrong. But since he nearly got it right by discussing it > with some people, nothing bad happened and the outcome is worth having I > don't see why we would want to pick Jan up for anything, or back-out > those changes. The results have nothing to do with whether the process was followed. We do not ignore process violations just because the outcome was OK. And Jan did not come even close to following procedure. He just asked core if they would object to such an addition post-feature freeze. He did not show code to core so there is no sense the core approved the patch. And Jan did not show the patch to hackers or discuss the patch application. I do not want to keep bashing Jan but Simon's statements require me to set the record straight. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, 2007-10-10 at 12:08 -0400, Bruce Momjian wrote: > The results have nothing to do with whether the process was followed. > We do not ignore process violations just because the outcome was OK. > > And Jan did not come even close to following procedure. He just asked > core if they would object to such an addition post-feature freeze. He > did not show code to core so there is no sense the core approved the > patch. And Jan did not show the patch to hackers or discuss the patch > application. > > I do not want to keep bashing Jan but Simon's statements require me to > set the record straight. Record straight; please consider my comments withdrawn. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
On 10/10/2007 12:08 PM, Bruce Momjian wrote: > The results have nothing to do with whether the process was followed. > We do not ignore process violations just because the outcome was OK. Agreed. But reversing something that came out OK for no other reason than that the process was violated? I know you don't, but some people are asking for exactly that. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> > The results have nothing to do with whether the process was followed. > > We do not ignore process violations just because the outcome was OK. > > Agreed. But reversing something that came out OK for no other reason > than that the process was violated? I know you don't, but some people > are asking for exactly that. So as long as something is committed, and only breaks certain (for now unnamed) platforms (until fixed that is), then proceduredoesn't apply. And it helps if certain external projects ask for it. I'm not entirely clear on the criteria for those projects. I don't particularly like that fact but I think it's good to have discussed it and spelled it out. And I will certainly acceptit since it's been discussed in public and seems to have fair agreement between core members. The important thing is that we have documented a way around the rules so next time it's done noone needs to bother complaining. /Magnus
Magnus Hagander wrote: > > > > The results have nothing to do with whether the process was followed. > > > We do not ignore process violations just because the outcome was OK. > > > > Agreed. But reversing something that came out OK for no other reason > > than that the process was violated? I know you don't, but some people > > are asking for exactly that. > > So as long as something is committed, and only breaks certain (for now > unnamed) platforms (until fixed that is), then procedure doesn't apply. No, if someone does this again they are going to be raked over the coals like Jan was. That is probably enough to keep people following procedure. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +