Re: Slightly OT.

On 6/1/07, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> wrote:
> On Fri, Jun 01, 2007 at 11:08:50PM +0200, Alexander Staubo wrote:
> > That doesn't make any sense. As a database *user* it's my prerogative
> > to criticize the bits that make my life painful.
>
> Sure. And as a user of free software, it is your prerogative to
> propose a way that the software can be modified to make it do what
> you want, and to do the work to so modify it. Does this mean you are
> offering?

It's my prerogative, but not my moral obligation. I have no intention
of becoming a Slony developer. I use Slony because I have no choice,
and I would not have touched it with a bargepole if I did not need to.
(I do contribute to projects that I do enjoy using.) On the other
hand, if my current project goes well, I hope that I will be able to
persuade my partners to set aside some cash to fund improvements to
PostgreSQL and/or Slony.

> > For example, there is clearly an opportunity to implement the
> > appropriate hooks in PostgreSQL that can be used *if they are
> > available*; otherwise, on unpatched/older systems, require the use of
> > the slonik command.
>
> I don't know that that is clear at all.
[snip]

Perhaps not, but all I wrote was there is an *opportunity*, technical
complexities aside, in an effort to provide *constructive* criticism.
I said this based on your previous comment, that "the path [was]
chosen because it allowed the entire thing to fit in user space, which
meant it was possible to install it on an unpatched PostgreSQL", which
implies that patching PostgreSQL is a possibility that may be
considered.

> To begin with, one would
> have to get agreement on what those hooks would be. If you look on
> the pgfoundry site, you'll note that I set up a project there to try
> to get such a list of hooks defined. It went nowhere:
[snip]

For the record, I really appreciate the effort you made. I wasn't
paying attention to pgsql-hackers at the time, so I missed the
somewhat depressing discussion you had with Markus Schiltknecht.

> Moreover, what you are suggesting is
> a _massive_ increase in the complications of the code

That, incidentally, is the kind of thing I want to hear, as opposed to
"you are wrong", which is neither helpful nor polite.

[snip]
> the reason DDL is handled specially. If you don't know what the hard
> parts are, I suggest you go and read the rather detailed original
> concept document that Jan put together for the community prior to
> starting work on the system. But just as a teaser: what do you do if
> your DDL on the local node has succeeded, and you added additional
> data in the same transaction, but the DDL fails for some reason on a
> remote node? Note that this one isn't even one of the actually
> tricky cases.

Could you not (I ask naively) detect the first DDL statement is
submitted in a transaction on the master, then start a transaction on
each slave, then funnel this and all subsequent statements
synchronously to every nodes, then prepare and commit everyone?

Mind you, I profess virtual ignorance of the numerous border cases
involved, so do go ahead and tell me how wrong I am and how silly I am
for suggesting I could have the balls to even consider suggesting
something like this. :)

This suggestion implies transparent DDL replication would be
synchronous, which seems like a decent compromise when you can ensure
that all nodes are committed atomically, and virtually guaranteed to
do so. That would be an improvement on the current behaviour (section
15 of the Slony manual):

"If there is anything broken about the script, or about how it
executes on a particular node, this will cause the slon daemon for
that node to panic and crash"

Alexander.