On 11/26/2010 3:30 PM, Steve Singer wrote:
> On 10-11-26 03:16 PM, Jan Wieck wrote:
>>  On 11/17/2010 5:06 PM, Christopher Browne wrote:
>>>  A thing that several of us have been ruminating over for a while is the
>>>  problem that people get confused about how you submit Slonik scripts,
>>>  you may have some actions that require waits.
>>
>>  One major problem with automatic waiting for events is that it is
>>  extremely context sensitive to wait at all.
>>
>>  One cannot wait inside of a TRY block. The events aren't committed yet,
>>  so they cannot propagate.
>>
>>  One needs to be careful not to wait if the current path configuration is
>>  incomplete. You should for example never wait for the FIRST store path
>>  ... you'd wait forever.
>>
>>  This all basically exposes that slonik has insufficient knowledge about
>>  the overall cluster configuration and healthiness. It basically fires
>>  off "commands" blindly. I've long been thinking that slonik itself needs
>>  a major overhaul. My recent experiences with the Mozilla Rhino
>>  JavaScript engine (Steve and I developed a cluster test framework using
>>  it) makes me think that actually creating a complete new slonik from
>>  scratch won't be too bad of an idea.
>
> What would you want to change in slonik (from the users point of view)
> if you were doing that?
>
> When I was developing tests for the framework I spent countless hours
> debugging tests were the problem ended up being a missing or an extra
> wait for (or one against the wrong node). Expecting the average DBA to
> figure this stuff out isn't nice.   Slonik should be able to figure out
> if paths exist to the required nodes and other dependencies on the
> configuration.  I think slonik should check as many things as we can
> make and give the user useful error messages instead of 'waiting for ever'
>
> I agree with Vick that a Java dependency for slony would be a bad idea.

Would it really be such a bad idea?

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.

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

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.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin