Thread: Ready for beta yet?

Ready for beta yet?

From
"Dave Page"
Date:
Are we ready to roll a beta yet? Any more patches or commits
outstanding?

Regards, Dave

Re: Ready for beta yet?

From
Andreas Pflug
Date:
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


Re: Ready for beta yet?

From
Diego Gil
Date:
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
>
>


Re: Ready for beta yet?

From
"Dave Page"
Date:
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
>
>


Re: Ready for beta yet?

From
"Dave Page"
Date:
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


Re: Ready for beta yet?

From
Andreas Pflug
Date:
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

Re: [Slony1-general] Ready for beta yet?

From
Andreas Pflug
Date:
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

Re: [Slony1-general] Re: Ready for beta yet?

From
cbbrowne@ca.afilias.info
Date:
> 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.


Re: Ready for beta yet?

From
Tomasz Rybak
Date:
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>


Re: Ready for beta yet?

From
"Dave Page"
Date:

> -----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

Re: Ready for beta yet?

From
Andreas Pflug
Date:
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.

Re: Ready for beta yet?

From
"Dave Page"
Date:

> -----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

Re: Ready for beta yet?

From
blacknoz@club-internet.fr
Date:
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>
>
>


Re: Ready for beta yet?

From
Andreas Pflug
Date:
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

Re: [Slony1-general] RE: Ready for beta yet?

From
elein
Date:
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
>

Re: Ready for beta yet?

From
Andreas Pflug
Date:
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


Re: Ready for beta yet?

From
Tomasz Rybak
Date:
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

Re: Ready for beta yet?

From
Andreas Pflug
Date:
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

Re: Ready for beta yet?

From
Andreas Pflug
Date:
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

Re: Ready for beta yet?

From
blacknoz@club-internet.fr
Date:
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


Re: Ready for beta yet?

From
blacknoz@club-internet.fr
Date:
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

Re: Ready for beta yet?

From
"Dave Page"
Date:
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
> >
>
>