Re: Slightly OT.

From: "Alexander Staubo" <alex(at)purefiction(dot)net>
To: "Andrew Sullivan" <ajs(at)crankycanuck(dot)ca>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Slightly OT.
Date: 2007-06-01 23:30:53
Message-ID: 88daf38c0706011630w1de6fe9al65819389bb7f9f0f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/2/07, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> wrote:
> On Sat, Jun 02, 2007 at 12:05:20AM +0200, Alexander Staubo wrote:
> > All you would require is a simple boolean flag to enable or disable
> > automatic DDL propagation, surely.
>
> You know, it is just possible that some of the responses you are
> getting in this thread have to do with the glib way you say "just a
> simple flag", waving away all the corner cases and difficult parts.

Or maybe I'm focused on the end-user experience and trying to mentally
fit the technology to that idea rather than the other way around. Too
much software is designed by developers, and too little software is
designed for users.

I don't mean to be glib at all -- the person was asking, in effect,
"but this hypothetical feature X would break case Y", to which I
suggested a flag to turn X on or off. PostgreSQL has plenty of flags
that turn features on and off. Whether or not the hypothetical feature
is hard to implement, or should be implemented, is an orthogonal
concern.

> What do you do, for instance, when your automatic DDL wedges the
> replication system after data-replicating events have come in?

There needs to be a point of synchronization when a DDL transaction
appears that blocks further write transactions from running. As far as
I can tell, the slaves themselves can continue to receive pending
events, but perhaps not. As far as I can tell, table locking on the
master ensures that concurrent, not-yet-committed transactions started
*before* the DDL transaction will block the DDL itself, but I'm sure
there's a gap here that could lead to craziness; it seems to me that
you could detect it reliably and throw an error when it happens.

I admit I am at a disadvantage here. I never intended to enter into a
full-fledged discussion about implementation details, but you teased
me, dammit. I clearly don't have enough knowledge about the way Slony
works, but that does not disqualify me from suggesting that the
current behaviour is unfriendly. Certainly there are technical and
historic facts that explain this behaviour, but I see nothing wrong
with challenging those notions in the name of helping the situation,
at least according to my own aesthetics.

Last I checked, nobody was actually terribly *happy* about having to
pipe schema changes through slonik. Of course, as far as I can see
(especially with regard to this thread), nobody seems to mind all that
much, either, but then again people put up with a lot of crap before
we had, say, sliced bread or psql tab completion.

> [...] before brushing off
> the current design as some sort of nasty thoughtless attempt to make
> your life more difficult on the part of those who have worked on the
> system.

I'm not that paranoid. :)

Alexander.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2007-06-01 23:35:27 Re: One last Slony question (was Re: Slightly OT.)
Previous Message Ron Johnson 2007-06-01 23:15:40 One last Slony question (was Re: Slightly OT.)