Thread: Ready for beta yet?
Are we ready to roll a beta yet? Any more patches or commits outstanding? Regards, Dave
Dave Page wrote: >Are we ready to roll a beta yet? Any more patches or commits >outstanding? > > Um, please let me this weekend (including monday) to review slony stuff. Regards, Andreas
I will complete spanish translation for monday. Regards, Diego. El vie, 30-09-2005 a las 16:03 +0100, Dave Page escribió: > Are we ready to roll a beta yet? Any more patches or commits > outstanding? > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > >
OK, thanks Diego. Translations are not essential until RC, but are always nice to get early :-) /D -----Original Message----- From: "Diego Gil"<diego@adminsa.com> Sent: 30/09/05 19:13:54 To: "Dave Page"<dpage@vale-housing.co.uk> Cc: "pgadmin-hackers"<pgadmin-hackers@postgresql.org> Subject: Re: [pgadmin-hackers] Ready for beta yet? I will complete spanish translation for monday. Regards, Diego. El vie, 30-09-2005 a las 16:03 +0100, Dave Page escribió: > Are we ready to roll a beta yet? Any more patches or commits > outstanding? > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > > -----Unmodified Original Message----- I will complete spanish translation for monday. Regards, Diego. El vie, 30-09-2005 a las 16:03 +0100, Dave Page escribió: > Are we ready to roll a beta yet? Any more patches or commits > outstanding? > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > >
OK, we'll aim for Tuesday then. /D -----Original Message----- From: "Andreas Pflug"<pgadmin@pse-consulting.de> Sent: 30/09/05 18:47:48 To: "Dave Page"<dpage@vale-housing.co.uk> Cc: "pgadmin-hackers"<pgadmin-hackers@postgresql.org> Subject: Re: [pgadmin-hackers] Ready for beta yet? Dave Page wrote: >Are we ready to roll a beta yet? Any more patches or commits >outstanding? > > Um, please let me this weekend (including monday) to review slony stuff. Regards, Andreas -----Unmodified Original Message----- Dave Page wrote: >Are we ready to roll a beta yet? Any more patches or commits >outstanding? > > Um, please let me this weekend (including monday) to review slony stuff. Regards, Andreas
Dave Page wrote: > OK, we'll aim for Tuesday then. Yup, I'll give you a 'go'. Um, seeing that apparently nothing I posted in the last 4 weeks to slony-general is fixed appropriately or finally discussed, and we really need to roll a beta quite soon, I'm afraid we'll have to fork the slony creation scripts. We already discussed to include the creation scripts into pgadmin installations to make administrator's life easier, but apparently we *must* do that to have pgadmin working on slony 1.1. I just tested slony cvs head, and found that creation from scratch (using the unmodified slony scripts) will work ok, but joining will fail with the bug reported repeatedly from enablenode_int inserting into sl_confirm (illegal default for con_timestamp). Since I didn't test 1.1.1, this might not apply to that version, don't know so far, don't have the time to test right now. Second, there's still not a viable alternative how to store path information without admin nodes. I'm running out of time now, so I'll continue that way, we'll have to make sure that in our fork listens are generated from enabled nodes only (AFAICS usual slonik work will never leave un-enabled nodes, so nobody should ever notice). To identify the version, I'll add a slonyAdminVersion() so that pgAdmin can be sure it runs on a workable version, or recommend upgrading (probably another case for the guru). AFAIR upgradeNode isn't implemented yet, will do that this weekend. Regards, Andreas
cbbrowne@ca.afilias.info wrote: >>I just tested slony cvs head, and found that creation from scratch >>(using the unmodified slony scripts) will work ok, but joining will fail >>with the bug reported repeatedly from enablenode_int inserting into >>sl_confirm (illegal default for con_timestamp). Since I didn't test >>1.1.1, this might not apply to that version, don't know so far, don't >>have the time to test right now. > > > This is not, and never has been, a bug in Slony-I. > > It IS a bug in your system configuration, in that your environment is > using a timezone incompatible with PostgreSQL. You're kidding. I'll certainly *not* modify the timezone of the server, which is set correctly. The server *is* located in the MESZ timezone, but I certainly wouldn't expect pgsql to be able to interpret all possible variations of time strings timeofday() might emit. Using a function that returns timestamp directly and thus not needing to convert won't break anything, just improve things. > > I am reluctant to go to heroic extremes Hu? So using now() instead of timeofday()::timestamp is heroic? > > There never was a real proposal presented, so there hasn't been anything > to consider. It is posted... > > I'm a bit disagreeable about it; if my impressions are correct that this > is about coming up with a place to stow the "admin conninfo" information, > I think pgadmin should stow it in its own additional table, therefore > making the new data completely invisible and irrelevant to slon/slonik. I > haven't heard any reasons to consider that wrong. I'm not really against it; this was partially proposed beginning this year. Still, as I already mentioned, it is necessary to have this table propagated to all nodes, just as any other node information. So if you invent a helper table that's replicated automatically as sl_node and sl_path, ok. Regards, Andreas
> I just tested slony cvs head, and found that creation from scratch > (using the unmodified slony scripts) will work ok, but joining will fail > with the bug reported repeatedly from enablenode_int inserting into > sl_confirm (illegal default for con_timestamp). Since I didn't test > 1.1.1, this might not apply to that version, don't know so far, don't > have the time to test right now. This is not, and never has been, a bug in Slony-I. It IS a bug in your system configuration, in that your environment is using a timezone incompatible with PostgreSQL. "Fixing" Slony-I so that it is less likely to report this problem merely masks the true problem which will persist until you fix TZ/PGTZ in your environment. You can expect, based on the incorrect configuration of timezone information on your system, that you will sporadically encounter problems (unrelated to Slony-I) where transactions will fail due to this incorrect configuration. I am reluctant to go to heroic extremes to prevent people from "shooting themselves in the foot." People who can't get their system configuration set up correctly ought to wonder if it's a wise idea to add the risks of further "moving parts" such as replication to their environment. > Second, there's still not a viable alternative how to store path > information without admin nodes. I'm running out of time now, so I'll > continue that way, we'll have to make sure that in our fork listens are > generated from enabled nodes only (AFAICS usual slonik work will never > leave un-enabled nodes, so nobody should ever notice). There never was a real proposal presented, so there hasn't been anything to consider. I'm a bit disagreeable about it; if my impressions are correct that this is about coming up with a place to stow the "admin conninfo" information, I think pgadmin should stow it in its own additional table, therefore making the new data completely invisible and irrelevant to slon/slonik. I haven't heard any reasons to consider that wrong. Nobody else has publicly presented any sort of agreement on this, which pretty forcibly establishes that there is not any agreement at this time as to how this ought to be handled. I am certainly not going to patch either stable or experimental releases based on such a lack of agreement.
Dnia 30-09-2005, pią o godzinie 16:03 +0100, Dave Page napisał(a): > Are we ready to roll a beta yet? Any more patches or commits > outstanding? What's with Debian package files? In revision 4476 there are still old files. I've downloaded Debian's source of pgadmin3 1.2.2, and as Raphael's written, it's debian/ files are fixed. However, in svn files are still unfixed. -- Tomasz Rybak <bogomips@post.pl>
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 01 October 2005 00:08 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org; Slony Mailing List > Subject: Re: [pgadmin-hackers] Ready for beta yet? > > Dave Page wrote: > > OK, we'll aim for Tuesday then. > > Yup, I'll give you a 'go'. > > Um, seeing that apparently nothing I posted in the last 4 weeks to > slony-general is fixed appropriately or finally discussed, > and we really > need to roll a beta quite soon, I'm afraid we'll have to fork > the slony > creation scripts. > We already discussed to include the creation scripts into pgadmin > installations to make administrator's life easier, but apparently we > *must* do that to have pgadmin working on slony 1.1. No, that is a very *bad* idea. The Slony team have told us that they don't thing the proposed changes are appropriate, so all that will end up happening is that any users running pgAdmin will get told to come and see us for support, or stop running a non-standard version of Slony. I do not want us to have to deal with any Slony support beyond our own code in pgAdmin (not including the Win32 port of course, but that's a whole other issue). What exactly do we need the admin nodes for? I'm assuming that you're setting up the maintenance DB for the server as the admin node so we can easily find all sets on that server - is that right? Perhaps for older versions (well 1.1) we need to just find sets as we connect to any individual databases, and use your original plan for 1.2 in which we use a separate table as Jan/Chris have suggested? Also, what has Chris K-L done in phpPgAdmin? I thought he was going to use the admin nodes idea as well, but perhaps not... Regards, Dave
Dave Page wrote: >>We already discussed to include the creation scripts into pgadmin >>installations to make administrator's life easier, but apparently we >>*must* do that to have pgadmin working on slony 1.1. > > > No, that is a very *bad* idea. At least my proposal provoked an answer finally... > The Slony team have told us that they > don't thing the proposed changes are appropriate, I wrote a lengthy mail about this timezone stuff. The issue is fixed in slonik, but not in the db. Don't they want other tools to run? Why do they insist on relying on server's display formatting settings, if things can easily be coded to avoid that? > so all that will end > up happening is that any users running pgAdmin will get told to come and > see us for support, or stop running a non-standard version of Slony. I did hope to get feedback what exactly they think happens to non-enabled nodes, or finally what the no_active flag is good for if a node with the flag set to false is assumed to screw up everything. Imagine a standard node (freshly created with slonik, no_active=true) that has no path information to other nodes. Will it interfere? If not, will the existence (not the creation) of path information interfere? AFAICS the interference starts when creating listens, not earlier. > do not want us to have to deal with any Slony support beyond our own > code in pgAdmin We'll be dealing with it anyway. Several tasks are implemented deep down in slonik, not really documented to be executed in a different tool. > > What exactly do we need the admin nodes for? I'm assuming that you're > setting up the maintenance DB for the server as the admin node so we can > easily find all sets on that server - is that right? It's not needed to locate stuff in the current db's cluster, but to perform actions that have to be executed on the local db as well as the remote server. > Perhaps for older > versions (well 1.1) we need to just find sets as we connect to any > individual databases, and use your original plan for 1.2 in which we use > a separate table as Jan/Chris have suggested? While I'm not particularly fond of doing things in 1.2+ different from 1.0-1.1, this is certainly not a real problem. What *is* a problem is scanning all servers and databases to find a suitable connection, this won't work for several reasons: - we might hit a cluster with the same name, which is actually a different one. - This may take a very long time. I have several remote servers registered, which aren't accessible until I connect via VPN. It would take some minutes until all timeouts elapsed. > Also, what has Chris K-L done in phpPgAdmin? I thought he was going to > use the admin nodes idea as well, but perhaps not... He might not have got to the point where he needs multiple connections. Joining a cluster needs it, but this is trivial because the server/db/cluster-to-join is manually selected. Failover does require it (failednode to be called on all nodes). I'd consider it highly error prone if the connect information entry is deferred until failover really has to happen. Failover is a last-resort action, after everything else failed. In that situation human errors tend to happen, and they usually have far more dramatic consequences (Murphy...). The second use-case is monitoring. When working on a cluster, it's desirable to work cluster-centric, i.e. do everything from a single point, instead of jumping from one database to another to locate the provider node or to find out what's happening on a particular node. While omitting the second point is simply (a lot) less user friendly, failover support can't be reliably implemented without persistent connection info.
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 October 2005 11:50 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org; Slony Mailing List; > Christopher Kings-Lynne > Subject: Re: [pgadmin-hackers] Ready for beta yet? > > Dave Page wrote: > > >>We already discussed to include the creation scripts into pgadmin > >>installations to make administrator's life easier, but > apparently we > >>*must* do that to have pgadmin working on slony 1.1. > > > > > > No, that is a very *bad* idea. > > At least my proposal provoked an answer finally... I didn't comment previously because I don't understand the issues fully enough to provide any useful input. I do know that forking parts of Slony other than is probably not a good idea. > > The Slony team have told us that they > > don't thing the proposed changes are appropriate, > > I wrote a lengthy mail about this timezone stuff. The issue > is fixed in > slonik, but not in the db. Don't they want other tools to run? Why do > they insist on relying on server's display formatting settings, if > things can easily be coded to avoid that? I don't know. Perhaps Jan or Christopher can explain so we can understand their line of thinking? > > so all that will end > > up happening is that any users running pgAdmin will get > told to come and > > see us for support, or stop running a non-standard version of Slony. > > > I did hope to get feedback what exactly they think happens to > non-enabled nodes, or finally what the no_active flag is good > for if a > node with the flag set to false is assumed to screw up everything. > > Imagine a standard node (freshly created with slonik, no_active=true) > that has no path information to other nodes. Will it > interfere? If not, > will the existence (not the creation) of path information interfere? > AFAICS the interference starts when creating listens, not earlier. I really don't know the answer to that - again, hopefully Jan or Christopher can help. > > do not want us to have to deal with any Slony support > beyond our own > > code in pgAdmin > > We'll be dealing with it anyway. Several tasks are > implemented deep down > in slonik, not really documented to be executed in a different tool. Yes, but I don't want us to have to take on random problems that might be caused by difference in our versions of the scripts. At the moment at least, pgAdmin is working behind the documented Slony API. If we change that in any way the Slony team would have every right to tell us and any users using our version of things to go an sort out *any* problems for ourselves. > > What exactly do we need the admin nodes for? I'm assuming > that you're > > setting up the maintenance DB for the server as the admin > node so we can > > easily find all sets on that server - is that right? > > It's not needed to locate stuff in the current db's cluster, but to > perform actions that have to be executed on the local db as > well as the > remote server. Why are such actions not performed on the origin node as a matter of course (see below before answering that :-) )? > > Perhaps for older > > versions (well 1.1) we need to just find sets as we connect to any > > individual databases, and use your original plan for 1.2 in > which we use > > a separate table as Jan/Chris have suggested? > > While I'm not particularly fond of doing things in 1.2+ > different from > 1.0-1.1, this is certainly not a real problem. > What *is* a problem is scanning all servers and databases to find a > suitable connection, this won't work for several reasons: > - we might hit a cluster with the same name, which is actually a > different one. > - This may take a very long time. I have several remote servers > registered, which aren't accessible until I connect via VPN. It would > take some minutes until all timeouts elapsed. I'm not suggesting a full search at connect, just that we populate the trees etc only when we do actually connect to an individual database. That should be a relatively trivial query on pg_class/pg_namespace I would think? > > Also, what has Chris K-L done in phpPgAdmin? I thought he > was going to > > use the admin nodes idea as well, but perhaps not... > > He might not have got to the point where he needs multiple > connections. > Joining a cluster needs it, but this is trivial because the > server/db/cluster-to-join is manually selected. Failover does > require it > (failednode to be called on all nodes). > > I'd consider it highly error prone if the connect information > entry is > deferred until failover really has to happen. Failover is a > last-resort > action, after everything else failed. In that situation human errors > tend to happen, and they usually have far more dramatic consequences > (Murphy...). > > The second use-case is monitoring. When working on a cluster, it's > desirable to work cluster-centric, i.e. do everything from a single > point, instead of jumping from one database to another to locate the > provider node or to find out what's happening on a particular node. > > While omitting the second point is simply (a lot) less user friendly, > failover support can't be reliably implemented without persistent > connection info. Which is why you can't use the origin I guess - because you are unlikely to be able to access the origin when you need to failover, but need to be sure that pgAdmin knows about the most recent configuration before doing anything potentially dangerous. Hmmm... Think I see what you mean now (at last)!! /D
Hi Tomasz, Dave and friends, first day to my new job and first day with an access to the net since a long time. Tomasz, if you have some time to produce a merge between what you provided and what I've fixed in official debian I'd appreciate your help now I particularly think to the pgagent part of the package which was not taken in consideration in 1.2.2 and also the i18n relocation. To all french speackers around, I'd also appreciate any help with pga3 translation in french too. However, I plan to work on this until the end of the week if it's not too late. Cheers, Silent Raph. ----Message d'origine---- >Sujet: Re: [pgadmin-hackers] Ready for beta yet? >De: Tomasz Rybak <bogomips@post.pl> >A: Dave Page <dpage@vale-housing.co.uk> >Copie à: blacknoz@club-internet.fr, >Date: Sat, 01 Oct 2005 17:33:54 +0200 > >Dnia 30-09-2005, pi± o godzinie 16:03 +0100, Dave Page napisa³(a): >> Are we ready to roll a beta yet? Any more patches or commits >> outstanding? > >What's with Debian package files? > >In revision 4476 there are still old files. >I've downloaded Debian's source of pgadmin3 1.2.2, and >as Raphael's written, it's debian/ files are fixed. >However, in svn files are still unfixed. > >-- >Tomasz Rybak <bogomips@post.pl> > >
Dave Page wrote: > > I'm running out of time for today (and tomorrow), so I committed a what I have now. - move set not completely tested, because I hit a slony bug. - failover not implemented. - event tracking enhanced Apparently even without my patch the admin nodes won't conflict with events, tomorrow more on this topic. Regards, Andrea
On Mon, Oct 03, 2005 at 12:39:27PM +0100, Dave Page wrote: > > > > -----Original Message----- > > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > > Sent: 03 October 2005 11:50 > > To: Dave Page > > Cc: pgadmin-hackers@postgresql.org; Slony Mailing List; > > Christopher Kings-Lynne > > Subject: Re: [pgadmin-hackers] Ready for beta yet? > > > > Dave Page wrote: > > > > >>We already discussed to include the creation scripts into pgadmin > > >>installations to make administrator's life easier, but > > apparently we > > >>*must* do that to have pgadmin working on slony 1.1. > > > > > > > > > No, that is a very *bad* idea. > > > > At least my proposal provoked an answer finally... > > I didn't comment previously because I don't understand the issues fully > enough to provide any useful input. I do know that forking parts of > Slony other than is probably not a good idea. > > > > The Slony team have told us that they > > > don't thing the proposed changes are appropriate, > > > > I wrote a lengthy mail about this timezone stuff. The issue > > is fixed in > > slonik, but not in the db. Don't they want other tools to run? Why do > > they insist on relying on server's display formatting settings, if > > things can easily be coded to avoid that? > > I don't know. Perhaps Jan or Christopher can explain so we can > understand their line of thinking? > > > > so all that will end > > > up happening is that any users running pgAdmin will get > > told to come and > > > see us for support, or stop running a non-standard version of Slony. > > > > > > I did hope to get feedback what exactly they think happens to > > non-enabled nodes, or finally what the no_active flag is good > > for if a > > node with the flag set to false is assumed to screw up everything. > > > > Imagine a standard node (freshly created with slonik, no_active=true) > > that has no path information to other nodes. Will it > > interfere? If not, > > will the existence (not the creation) of path information interfere? > > AFAICS the interference starts when creating listens, not earlier. > > I really don't know the answer to that - again, hopefully Jan or > Christopher can help. > > > > do not want us to have to deal with any Slony support > > beyond our own > > > code in pgAdmin > > > > We'll be dealing with it anyway. Several tasks are > > implemented deep down > > in slonik, not really documented to be executed in a different tool. > > Yes, but I don't want us to have to take on random problems that might > be caused by difference in our versions of the scripts. At the moment at > least, pgAdmin is working behind the documented Slony API. If we change > that in any way the Slony team would have every right to tell us and any > users using our version of things to go an sort out *any* problems for > ourselves. > > > > What exactly do we need the admin nodes for? I'm assuming > > that you're > > > setting up the maintenance DB for the server as the admin > > node so we can > > > easily find all sets on that server - is that right? > > > > It's not needed to locate stuff in the current db's cluster, but to > > perform actions that have to be executed on the local db as > > well as the > > remote server. > > Why are such actions not performed on the origin node as a matter of > course (see below before answering that :-) )? > > > > Perhaps for older > > > versions (well 1.1) we need to just find sets as we connect to any > > > individual databases, and use your original plan for 1.2 in > > which we use > > > a separate table as Jan/Chris have suggested? > > > > While I'm not particularly fond of doing things in 1.2+ > > different from > > 1.0-1.1, this is certainly not a real problem. > > What *is* a problem is scanning all servers and databases to find a > > suitable connection, this won't work for several reasons: > > - we might hit a cluster with the same name, which is actually a > > different one. > > - This may take a very long time. I have several remote servers > > registered, which aren't accessible until I connect via VPN. It would > > take some minutes until all timeouts elapsed. > > I'm not suggesting a full search at connect, just that we populate the > trees etc only when we do actually connect to an individual database. > That should be a relatively trivial query on pg_class/pg_namespace I > would think? > > > > Also, what has Chris K-L done in phpPgAdmin? I thought he > > was going to > > > use the admin nodes idea as well, but perhaps not... > > > > He might not have got to the point where he needs multiple > > connections. > > Joining a cluster needs it, but this is trivial because the > > server/db/cluster-to-join is manually selected. Failover does > > require it > > (failednode to be called on all nodes). > > > > I'd consider it highly error prone if the connect information > > entry is > > deferred until failover really has to happen. Failover is a > > last-resort > > action, after everything else failed. In that situation human errors > > tend to happen, and they usually have far more dramatic consequences > > (Murphy...). > > > > The second use-case is monitoring. When working on a cluster, it's > > desirable to work cluster-centric, i.e. do everything from a single > > point, instead of jumping from one database to another to locate the > > provider node or to find out what's happening on a particular node. > > > > While omitting the second point is simply (a lot) less user friendly, > > failover support can't be reliably implemented without persistent > > connection info. > > Which is why you can't use the origin I guess - because you are unlikely > to be able to access the origin when you need to failover, but need to > be sure that pgAdmin knows about the most recent configuration before > doing anything potentially dangerous. Hmmm... Think I see what you mean > now (at last)!! The other reason for not using an origin is that there may be more than one table set in the cluster originating on different nodes. No? --elein > > /D > _______________________________________________ > Slony1-general mailing list > Slony1-general@gborg.postgresql.org > http://gborg.postgresql.org/mailman/listinfo/slony1-general >
Dave Page wrote: > >Why are such actions not performed on the origin node as a matter of >course (see below before answering that :-) )? > > Ask Slony's designers :-) Actually, at least storenode() changed its requirements; in 1.0.5, it must be called on the subscriber, in 1.1.1 on the provider. I hope I didn't overlook more of those. > > >>>Perhaps for older >>>versions (well 1.1) we need to just find sets as we connect to any >>>individual databases, and use your original plan for 1.2 in >>> >>> >>which we use >> >> >>>a separate table as Jan/Chris have suggested? >>> >>> >>While I'm not particularly fond of doing things in 1.2+ >>different from >>1.0-1.1, this is certainly not a real problem. >>What *is* a problem is scanning all servers and databases to find a >>suitable connection, this won't work for several reasons: >>- we might hit a cluster with the same name, which is actually a >>different one. >>- This may take a very long time. I have several remote servers >>registered, which aren't accessible until I connect via VPN. It would >>take some minutes until all timeouts elapsed. >> >> > >I'm not suggesting a full search at connect, just that we populate the >trees etc only when we do actually connect to an individual database. > > ??? How can we know whether a non-connected server contains a cluster, and if that cluster's name is not just by chance identical to ours? > >Which is why you can't use the origin I guess - because you are unlikely >to be able to access the origin when you need to failover, but need to >be sure that pgAdmin knows about the most recent configuration before >doing anything potentially dangerous. Hmmm... Think I see what you mean >now (at last)!! > > No, failover must explicitely be executed on all non-failed nodes. In the failover case, you can't rely on the replication network to transfer those commands, thus direct connection is needed. As I already pointed out, I've put quite some stress on my 1.2CVS yesterday. Apparently, the event queue isn't touched by new nodes until a slon process has been running on the new node the first time, thus preventing the new node to hold up the queue cleanup process. This makes perfectly sense, since until a node did its first cry there's no need to feed it, and complain if it doesn't eat. This makes the issue about non-active nodes a storm in a teacup, we simply can go on as it's now. Having listens generated that will never be listened on remains as unaesthetic (and easily fixable), but not a problem. Regards, Andreas
Dnia 03-10-2005, pon o godzinie 18:50 +0200, blacknoz@club-internet.fr napisał(a): > Hi Tomasz, Dave and friends, > > first day to my new job and first day with an access to > the net since a long time. Good luck with new job. > Tomasz, if you have some time to produce a merge between > what you provided and what I've fixed in official debian I'd > appreciate your help now I particularly think to the pgagent part > of the package which was not taken in consideration in 1.2.2 and > also the i18n relocation. > OK. Here are changes I made, applied to revision 4490. They are mostly changes made by you in official Debian package, but I made few additional. For changelog, I put 1.4.0, because as I understand, we're trying to be ready for 1.4 release; I also put you name, as author of these changes. Feel free to put mine, if it's more appropriate. In rules, line 16, instead of _pgsql_inc:="/usr/include/postgresql -I./include" I put calling of pg_config; such behaviour was mentioned in changelog for libpq-dev 8.0.3-13 as more proper now. I also created new variable CPPFLAGS, where I put -I./include taken from _pgsql_inc. Previous situation resulted in warnings from configure script, because instead of putting -I into _pgsql_inc, it was passed to script as parameter, which wasn't sure what to do with that. pgAdmin was being built successfully, but I decided to get rid of this warning. I also had to change a bit calling configure script in line 50, and add CPPFLAGS to it. I also changed directory from ui to i18n line 106 of file rules. Last change I made is adding pgagent and i18n files in pgadmin3.install. Changelog in attachment. One remark. Why there are slony3 and slony3-data package? Both depend on each other, and from my point of view there is no need for them both; maybe it's good idea to merge them. However, I'm not experienced in Debian packages creating, and I don't know why split occurred, so I'll leave these two as they are, without changes. So it's up to you to decide what to do. -- Tomasz Rybak <bogomips@post.pl>
Attachment
blacknoz@club-internet.fr wrote: > > To all french speackers around, I'd also appreciate any help with > pga3 translation in french too. > > However, I plan to work on this until the end of the week if it's not > too late. Of course it's not too late. It's certainly several weeks until we release. Regards, Andreas
I did all on the code that was on my in-mind list (except for those things on the TODO list). Slony-I failover will take more than just some minutes, so this must wait for 1.5/1.6 (which we might release with Slony-I 1.2?) There's only that issue from David Fetter, if it really is one. From my perspective: pgAdmin III 1.4 Beta-1 *GO* ! Regards, Andreas
Hi Tomasz, ----Message d'origine---- >Sujet: Re: [pgadmin-hackers] Ready for beta yet? >De: Tomasz Rybak <bogomips@post.pl> >A: blacknoz@club-internet.fr >Copie à: dpage@vale-housing.co.uk, pgadmin-hackers@postgresql.org >Date: Tue, 04 Oct 2005 21:24:33 +0200 > >Dnia 03-10-2005, pon o godzinie 18:50 +0200, blacknoz@club-internet.fr >napisa³(a): >> Hi Tomasz, Dave and friends, >> >> first day to my new job and first day with an access to >> the net since a long time. > >Good luck with new job. thanks, I'll try to keep the luck with me. :) >> Tomasz, if you have some time to produce a merge between >> what you provided and what I've fixed in official debian I'd >> appreciate your help now I particularly think to the pgagent part >> of the package which was not taken in consideration in 1.2.2 and >> also the i18n relocation. >> > >OK. >Here are changes I made, applied to revision 4490. >They are mostly changes made by you in official Debian package, >but I made few additional. I had a quick look to your changes and it seems quite good, although we must change some of them. Comments follow. >For changelog, I put 1.4.0, because as I understand, we're trying >to be ready for 1.4 release; I also put you name, as author of these >changes. Feel free to put mine, if it's more appropriate. 1.4.0 is ok but the package version should not be "-1". "-1" is reserved for the first upload to official Debian. Unofficial packages should never use version number greater or equal to 1. For unofficial releases I generally use something like -0.1, -0.2,... Take a look to the beginning of the changelog you will see what we did with Andreas Tille before the first upload to Debian. That's a good example (at least a functionnal one). Concerning my name as the author, you should definitely put yours (I'll correct this when providing a version for the svn [surely tomorrow]) That's your work and the least we can do is that you get your name somewhere to thank you for your contribution. >In rules, line 16, instead of >_pgsql_inc:="/usr/include/postgresql -I./include" >I put calling of pg_config; such behaviour was mentioned >in changelog for libpq-dev 8.0.3-13 as more proper now. yeah, alright with this. In fact that's what I ripped from Ubuntu for official 1.2.2. So, this one is definitely ok. >I also created new variable CPPFLAGS, where I put -I./include >taken from _pgsql_inc. >Previous situation resulted in warnings from configure script, >because instead of putting -I into _pgsql_inc, it was passed >to script as parameter, which wasn't sure what to do with that. >pgAdmin was being built successfully, but I decided to get >rid of this warning. >I also had to change a bit calling configure script in line 50, >and add CPPFLAGS to it. Ok, I'll take a look at this. Maybe we can definitely remove that old -I./include after all... >I also changed directory from ui to i18n line 106 of file rules. Perfect. >Last change I made is adding pgagent and i18n files in pgadmin3.install. Ok. We'll need a man page for pgagent in a near future if we want to upload the things as is for Official Debian. I don't know if anybody has began to work on this... Dave ? >Changelog in attachment. thanks for this diff. >One remark. >Why there are slony3 and slony3-data package? >Both depend on each other, and from my point of view there >is no need for them both; maybe it's good idea to merge them. >However, I'm not experienced in Debian packages creating, >and I don't know why split occurred, so I'll leave these two >as they are, without changes. So it's up to you to decide what >to do. I bet you refer to pgadmin3 and pgadmin3-data depending on each other. This was first introduced by Andreas Tille and discussed later with Peter Eisentraut and Noèl Koethe. In pgadmin3 package case, the reason for such a split is mainly due to the size of the documentation we provide. In this pgadmin3-data package we try to put all the nonarch dependent files and actually the PostgreSQL documentation. As it takes quite some disk space it's useful to split this for the following reason: - one non-arch package used by all the Debian archs prevents duplication of files and so save space on the Debian archive - as it saves disk space it also saves bandwidth between mirrors You may say that this not really interesting to do so for a compressed size of approx 1,5 Mo but if you multiply this by a large number of package it may be worth doing it. Last but not least, as pgadmin3-data contains documentation it should be named -doc and not -data, however, this documentation is usefull and/or needed for pgadmin3 to run well so it's not pure documentation and is mandatory to install. That's why we named it -data and not -doc and made the two packages depend exactly on each other. That's why it's like this and I won't change it. :) Thanks for your work, I'll provide an update tomorrow and ask Dave or Andreas (the Pflug one) to commit it. Regards, Raphaël
Dave, can you apply the following patch to the trunk ? This is the patch from Tomasz with blind corrections from my part. (not tested but should be ok, I'll use it to provide 1.4.0 beta1 package) Cheers, Raphaël ----Message d'origine---- >De: blacknoz@club-internet.fr >A: bogomips@post.pl >Copie à: dpage@vale-housing.co.uk, pgadmin-hackers@postgresql.org >Sujet: Re: [pgadmin-hackers] Ready for beta yet? >Date: Tue, 4 Oct 2005 22:46:10 +0200 > > >Hi Tomasz, > >----Message d'origine---- >>Sujet: Re: [pgadmin-hackers] Ready for beta yet? >>De: Tomasz Rybak <bogomips@post.pl> >>A: blacknoz@club-internet.fr >>Copie à: dpage@vale-housing.co.uk, pgadmin-hackers@postgresql.org >>Date: Tue, 04 Oct 2005 21:24:33 +0200 >> >>Dnia 03-10-2005, pon o godzinie 18:50 +0200, blacknoz@club-internet.fr >>napisa³(a): >>> Hi Tomasz, Dave and friends, >>> >>> first day to my new job and first day with an access to >>> the net since a long time. >> >>Good luck with new job. > >thanks, I'll try to keep the luck with me. :) > > >>> Tomasz, if you have some time to produce a merge between >>> what you provided and what I've fixed in official debian I'd >>> appreciate your help now I particularly think to the pgagent part >>> of the package which was not taken in consideration in 1.2.2 and >>> also the i18n relocation. >>> >> >>OK. >>Here are changes I made, applied to revision 4490. >>They are mostly changes made by you in official Debian package, >>but I made few additional. > >I had a quick look to your changes and it seems quite good, >although we must change some of them. Comments follow. > > >>For changelog, I put 1.4.0, because as I understand, we're trying >>to be ready for 1.4 release; I also put you name, as author of these >>changes. Feel free to put mine, if it's more appropriate. > >1.4.0 is ok but the package version should not be "-1". "-1" is >reserved for the first upload to official Debian. Unofficial packages >should never use version number greater or equal to 1. >For unofficial releases I generally use something like -0.1, -0.2,... >Take a look to the beginning of the changelog you will see what we >did with Andreas Tille before the first upload to Debian. That's a good >example (at least a functionnal one). >Concerning my name as the author, you should definitely put yours >(I'll correct this when providing a version for the svn [surely tomorrow]) >That's your work and the least we can do is that you get your name >somewhere to thank you for your contribution. > >>In rules, line 16, instead of >>_pgsql_inc:="/usr/include/postgresql -I./include" >>I put calling of pg_config; such behaviour was mentioned >>in changelog for libpq-dev 8.0.3-13 as more proper now. > >yeah, alright with this. In fact that's what I ripped from Ubuntu >for official 1.2.2. So, this one is definitely ok. > >>I also created new variable CPPFLAGS, where I put -I./include >>taken from _pgsql_inc. >>Previous situation resulted in warnings from configure script, >>because instead of putting -I into _pgsql_inc, it was passed >>to script as parameter, which wasn't sure what to do with that. >>pgAdmin was being built successfully, but I decided to get >>rid of this warning. >>I also had to change a bit calling configure script in line 50, >>and add CPPFLAGS to it. > >Ok, I'll take a look at this. Maybe we can definitely remove that >old -I./include after all... > > >>I also changed directory from ui to i18n line 106 of file rules. > >Perfect. > >>Last change I made is adding pgagent and i18n files in pgadmin3.install. > >Ok. We'll need a man page for pgagent in a near future if we >want to upload the things as is for Official Debian. >I don't know if anybody has began to work on this... Dave ? > >>Changelog in attachment. > >thanks for this diff. > >>One remark. >>Why there are slony3 and slony3-data package? >>Both depend on each other, and from my point of view there >>is no need for them both; maybe it's good idea to merge them. >>However, I'm not experienced in Debian packages creating, >>and I don't know why split occurred, so I'll leave these two >>as they are, without changes. So it's up to you to decide what >>to do. > >I bet you refer to pgadmin3 and pgadmin3-data depending on each >other. This was first introduced by Andreas Tille and discussed later >with Peter Eisentraut and Noèl Koethe. >In pgadmin3 package case, the reason for such a split is mainly due >to the size of the documentation we provide. >In this pgadmin3-data package we try to put all the nonarch dependent >files and actually the PostgreSQL documentation. As it takes quite >some disk space it's useful to split this for the following reason: >- one non-arch package used by all the Debian archs prevents >duplication of files and so save space on the Debian archive >- as it saves disk space it also saves bandwidth between mirrors >You may say that this not really interesting to do so for a compressed >size of approx 1,5 Mo but if you multiply this by a large number of >package it may be worth doing it. >Last but not least, as pgadmin3-data contains documentation it should >be named -doc and not -data, however, this documentation is usefull >and/or needed for pgadmin3 to run well so it's not pure documentation >and is mandatory to install. That's why we named it -data and not -doc >and made the two packages depend exactly on each other. >That's why it's like this and I won't change it. :) > >Thanks for your work, I'll provide an update tomorrow and ask Dave >or Andreas (the Pflug one) to commit it. > >Regards, >Raphaël > > >---------------------------(end of broadcast)--------------------------- >TIP 2: Don't 'kill -9' the postmaster >
Attachment
Thanks Raphaël, Tomasz. Patch applied. Regards Dave > -----Original Message----- > From: blacknoz@club-internet.fr [mailto:blacknoz@club-internet.fr] > Sent: 05 October 2005 17:46 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org; bogomips@post.pl > Subject: Re: Re: [pgadmin-hackers] Ready for beta yet? > > Dave, > > can you apply the following patch to the trunk ? > This is the patch from Tomasz with blind corrections from my part. > (not tested but should be ok, I'll use it to provide 1.4.0 > beta1 package) > > Cheers, > Raphaël > > > ----Message d'origine---- > >De: blacknoz@club-internet.fr > >A: bogomips@post.pl > >Copie à: dpage@vale-housing.co.uk, pgadmin-hackers@postgresql.org > >Sujet: Re: [pgadmin-hackers] Ready for beta yet? > >Date: Tue, 4 Oct 2005 22:46:10 +0200 > > > > > >Hi Tomasz, > > > >----Message d'origine---- > >>Sujet: Re: [pgadmin-hackers] Ready for beta yet? > >>De: Tomasz Rybak <bogomips@post.pl> > >>A: blacknoz@club-internet.fr > >>Copie à: dpage@vale-housing.co.uk, pgadmin-hackers@postgresql.org > >>Date: Tue, 04 Oct 2005 21:24:33 +0200 > >> > >>Dnia 03-10-2005, pon o godzinie 18:50 +0200, > blacknoz@club-internet.fr > >>napisa³(a): > >>> Hi Tomasz, Dave and friends, > >>> > >>> first day to my new job and first day with an access to > >>> the net since a long time. > >> > >>Good luck with new job. > > > >thanks, I'll try to keep the luck with me. :) > > > > > >>> Tomasz, if you have some time to produce a merge between > >>> what you provided and what I've fixed in official debian I'd > >>> appreciate your help now I particularly think to the pgagent part > >>> of the package which was not taken in consideration in 1.2.2 and > >>> also the i18n relocation. > >>> > >> > >>OK. > >>Here are changes I made, applied to revision 4490. > >>They are mostly changes made by you in official Debian package, > >>but I made few additional. > > > >I had a quick look to your changes and it seems quite good, > >although we must change some of them. Comments follow. > > > > > >>For changelog, I put 1.4.0, because as I understand, we're trying > >>to be ready for 1.4 release; I also put you name, as author of these > >>changes. Feel free to put mine, if it's more appropriate. > > > >1.4.0 is ok but the package version should not be "-1". "-1" is > >reserved for the first upload to official Debian. Unofficial packages > >should never use version number greater or equal to 1. > >For unofficial releases I generally use something like -0.1, -0.2,... > >Take a look to the beginning of the changelog you will see what we > >did with Andreas Tille before the first upload to Debian. > That's a good > >example (at least a functionnal one). > >Concerning my name as the author, you should definitely put yours > >(I'll correct this when providing a version for the svn > [surely tomorrow]) > >That's your work and the least we can do is that you get your name > >somewhere to thank you for your contribution. > > > >>In rules, line 16, instead of > >>_pgsql_inc:="/usr/include/postgresql -I./include" > >>I put calling of pg_config; such behaviour was mentioned > >>in changelog for libpq-dev 8.0.3-13 as more proper now. > > > >yeah, alright with this. In fact that's what I ripped from Ubuntu > >for official 1.2.2. So, this one is definitely ok. > > > >>I also created new variable CPPFLAGS, where I put -I./include > >>taken from _pgsql_inc. > >>Previous situation resulted in warnings from configure script, > >>because instead of putting -I into _pgsql_inc, it was passed > >>to script as parameter, which wasn't sure what to do with that. > >>pgAdmin was being built successfully, but I decided to get > >>rid of this warning. > >>I also had to change a bit calling configure script in line 50, > >>and add CPPFLAGS to it. > > > >Ok, I'll take a look at this. Maybe we can definitely remove that > >old -I./include after all... > > > > > >>I also changed directory from ui to i18n line 106 of file rules. > > > >Perfect. > > > >>Last change I made is adding pgagent and i18n files in > pgadmin3.install. > > > >Ok. We'll need a man page for pgagent in a near future if we > >want to upload the things as is for Official Debian. > >I don't know if anybody has began to work on this... Dave ? > > > >>Changelog in attachment. > > > >thanks for this diff. > > > >>One remark. > >>Why there are slony3 and slony3-data package? > >>Both depend on each other, and from my point of view there > >>is no need for them both; maybe it's good idea to merge them. > >>However, I'm not experienced in Debian packages creating, > >>and I don't know why split occurred, so I'll leave these two > >>as they are, without changes. So it's up to you to decide what > >>to do. > > > >I bet you refer to pgadmin3 and pgadmin3-data depending on each > >other. This was first introduced by Andreas Tille and discussed later > >with Peter Eisentraut and Noèl Koethe. > >In pgadmin3 package case, the reason for such a split is mainly due > >to the size of the documentation we provide. > >In this pgadmin3-data package we try to put all the nonarch dependent > >files and actually the PostgreSQL documentation. As it takes quite > >some disk space it's useful to split this for the following reason: > >- one non-arch package used by all the Debian archs prevents > >duplication of files and so save space on the Debian archive > >- as it saves disk space it also saves bandwidth between mirrors > >You may say that this not really interesting to do so for a > compressed > >size of approx 1,5 Mo but if you multiply this by a large number of > >package it may be worth doing it. > >Last but not least, as pgadmin3-data contains documentation it should > >be named -doc and not -data, however, this documentation is usefull > >and/or needed for pgadmin3 to run well so it's not pure documentation > >and is mandatory to install. That's why we named it -data > and not -doc > >and made the two packages depend exactly on each other. > >That's why it's like this and I won't change it. :) > > > >Thanks for your work, I'll provide an update tomorrow and ask Dave > >or Andreas (the Pflug one) to commit it. > > > >Regards, > >Raphaël > > > > > >---------------------------(end of > broadcast)--------------------------- > >TIP 2: Don't 'kill -9' the postmaster > > > >