-----Original Message-----
From: "elein"<elein at varlena.com>
Sent: 03/10/05 19:18:55
To: "Dave Page"<dpage at vale-housing.co.uk>
Cc: "Andreas Pflug"<pgadmin at pse-consulting.de>, "pgadmin-hackers at postgresql.org"<pgadmin-hackers at postgresql.org>, "Slony Mailing List"<slony1-general at gborg.postgresql.org>
Subject: Re: [Slony1-general] RE: [pgadmin-hackers] Ready for beta yet?

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

Yes, but I don't think that's a problem as (in pgAdmin's case at least) we can just connect to the origin of each individual set, regardless of the topology.

Regards, Dave

-----Unmodified Original Message-----
On Mon, Oct 03, 2005 at 12:39:27PM +0100, Dave Page wrote:
>  
> 
> > -----Original Message-----
> > From: Andreas Pflug [mailto:pgadmin at pse-consulting.de] 
> > Sent: 03 October 2005 11:50
> > To: Dave Page
> > Cc: pgadmin-hackers at 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 at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>