|
Home > Archive > Slony1 PostgreSQL Replication > August 2005 > 1.0/1.1/1.2 differences, pgAdmin integration
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
1.0/1.1/1.2 differences, pgAdmin integration
|
|
| Andreas Pflug 2005-08-30, 8:29 pm |
| I'm currently finishing slony support in pgadmin (code as of last week
was 1.05 only), and need to catch version dependencies now. Could please
somebody sum up which feature appeared in which version. Extracting this
from the docs would be really time consuming/error prone; at present I
got only 1.2 to test.
Currently I know of these differences:
storenode with third parameter (new in 1.1 or 1.2?)
ddlscript (1.1 or 1.2?)
FYI:
Creating/modifying objects in pgAdmin will be done trough ddlscript if
available.
Finally: I found that droplisten is disabled (will always return -1),
and even if I drop the sl_listen row it will be recreated. Auto-creating
listens from paths is a fine thing for standard situations, but I wonder
if this is a good thing in complicated replication topologies. In
addition, pgAdmin will use a (never active) node as "administrative
node" to store its path information to all nodes, and will never need
listens. Hopefully, a node that never pulls the events from its
providers won't happen to degrade the cluster somehow.
Regards,
Andreas
| |
| Christopher Browne 2005-08-30, 8:29 pm |
| Andreas Pflug wrote:
> I'm currently finishing slony support in pgadmin (code as of last week
> was 1.05 only), and need to catch version dependencies now. Could
> please somebody sum up which feature appeared in which version.
> Extracting this from the docs would be really time consuming/error
> prone; at present I got only 1.2 to test.
>
> Currently I know of these differences:
> storenode with third parameter (new in 1.1 or 1.2?)
Are you talking about SPOOLNODE? That's new in 1.1
There always were the three parameters:
- ID (obviously needed!)
- Comment
- Event Node
> ddlscript (1.1 or 1.2?)
That was available in 1.0.5, if not earlier.
> Finally: I found that droplisten is disabled (will always return -1),
> and even if I drop the sl_listen row it will be recreated.
> Auto-creating listens from paths is a fine thing for standard
> situations, but I wonder if this is a good thing in complicated
> replication topologies. In addition, pgAdmin will use a (never active)
> node as "administrative node" to store its path information to all
> nodes, and will never need listens. Hopefully, a node that never pulls
> the events from its providers won't happen to degrade the cluster
> somehow.
Generating sl_listen automatically was/is a good idea.
The thing that you need to think about reasonably hard is what ought to
be in sl_path.
The typical "simple scenario" involves there being fairly much symmetric
paths between all nodes.
Life gets more complex if you have weird firewalls in your environment
that lead to asymmetries in the paths, where the path from A to C isn't
at all similar to the path from B to C.
It seems to me to be a perfectly fine idea to have a "pseudo node" that
pgAdmin uses for its own purposes to store configuration data. But that
node should NOT be included in the configuration of the cluster proper,
as, if it hasn't got a slon connected, it won't process events, and will
prevent cleanup processes from cleaning out tables as they wait for
events to get to the "pseudo node."
| |
| Dave Page 2005-08-30, 8:29 pm |
| =20
> -----Original Message-----
> From: slony1-general-bounces- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org=20
> [mailto:slony1-general-bounces- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org] On=20
> Behalf Of Christopher Browne
> Sent: 30 August 2005 22:52
> To: Andreas Pflug
> Cc: Slony Mailing List
> Subject: Re: [Slony1-general] 1.0/1.1/1.2 differences,=20
> pgAdmin integration
>=20
> Andreas Pflug wrote:
>=20
> of last week
>=20
> Are you talking about SPOOLNODE? That's new in 1.1
No, it was storenode - I noted it in a todo email to
Magnus/Andreas/Hiroshi some time back:
"4) Update pgAdmin for Slony 1.1. Check API changes - e.g. storenode now
has a 3rd param (Andreas/Dave)"
Regards, Dave.
| |
| Andreas Pflug 2005-08-31, 7:25 am |
| Christopher Browne wrote:
>
>
> Are you talking about SPOOLNODE? That's new in 1.1
>
> There always were the three parameters:
> - ID (obviously needed!)
> - Comment
> - Event Node
I remember having my stuff working on 1.05 with 2 params only.
>
>
> That was available in 1.0.5, if not earlier.
Good. Are there any more differences to mention?
> Generating sl_listen automatically was/is a good idea.
Yup.
>
> The thing that you need to think about reasonably hard is what ought to
> be in sl_path.
Agreed.
> The typical "simple scenario" involves there being fairly much symmetric
> paths between all nodes.
>
> Life gets more complex if you have weird firewalls in your environment
> that lead to asymmetries in the paths, where the path from A to C isn't
> at all similar to the path from B to C.
>
> It seems to me to be a perfectly fine idea to have a "pseudo node" that
> pgAdmin uses for its own purposes to store configuration data. But that
> node should NOT be included in the configuration of the cluster proper,
> as, if it hasn't got a slon connected, it won't process events, and will
> prevent cleanup processes from cleaning out tables as they wait for
> events to get to the "pseudo node."
That wass my concern. Dropping the listens for that node (say: disable
auto generation) would achieve that. Maybe generating listens for
enabled nodes only (or at enable time?) would be help. Why listen for
disabled nodes anyway?
You might remember the discussion I've been starting around beginning of
the year where to store pgadmin's path info. Extending sl_node wasn't a
good idea, so the pseudo node was implemented. Having its path info
replicated with the other slony configuration stuff is quite helpful.
What would you suggest to do now?
Regards,
Andreas
| |
|
|
|
|
|