On 10-11-26 05:56 PM, Jan Wieck wrote:
> The system where slonik (or an alternative to it) is running does NOT
> have to be any of the DB servers or systems, where even slon is running.
> It can be the sysadmin's laptop for all that matters.

I'm going to hold off debating that till another time.

>
> Anyhow, I don't think the language is that important at this point in
> the discussion. Way more important is the question how much we would
> like slonik to actually "know".
>
> If I had to write slonik again it would on startup connect to each node,
> that it has an admin-conninfo for, and read the whole cluster
> configuration from its sl_* tables. It would update that information
> before executing any command.
>
> This way it would "know" which sets exist, which nodes are subscribed to
> them (and up to what level, like in-progress). It would know that a
> certain node isn't the origin of a certain set "yet".
>

Can we come up with a more specific list of when slonik should *know* 
things, what it should know and how it would use that information?

* Filling in defaults like the next available table_id and the set 
origin to subscribe set is one example

* Providing protection against breaking things by preventing a user from 
issuing the wrong command while an action is in progress is another (ie 
unsubscribe while a subscribe is in progress).  This might be in the 
form of rejecting the command or it might involve cancelling the 
in-progress command. - Determining in progress state in a distributed 
asynchronous system can be a challenge.

If we are revisiting these things we also should think about if slony 
commands should be propogated through sl_event or applied directly on 
each node by slonik - and if so do we need 2pc to make this work 
reliably, and is this that a good idea.



> Of course, this sort of safety could also be achieved by just extending
> the current slonik code.
>
> In any case, I do think we need to make slonik smarter. I just don't
> know if C is still the right language to do it in.
>

Once we know what exactly what we want slonik to do we will be in a 
better position to have that discussion.


>
> Jan
>