On 2/7/2007 2:15 PM, Richard Troy wrote:
Jan Wieck wrote:
> Are we still discussing if the Postgres backend may provide support for
> a commit timestamp, that follows the rules for Lamport timestamps in a
> multi-node cluster?

...I thought you said in this thread that you haven't and weren't going to
work on any kind of logical proof of it's correctness, saw no value in
prototyping your way to a clear (convincing) argument, and were
withdrawing the proposal [...]

I said I don't have any such documents. I was asked to continue this discussion in order to find people willing to help discover potential problems. I am prepared to continue this development isolated, although I wouldn't like to.

The PostgreSQL developers community used to be good at throwing out ideas, brainstorming about the possibilities, adding more to them and coming up with very unique and flexible solutions. I am a little disappointed that much of that got lost over the years and please forgive me if I sound a little grumpy over that. The statement to withdraw the proposal was certainly premature - consider it not withdrawn at this time. However, comparing what used to be our process to what I see today, I must say that something like TOAST would never have happened. It was the result of a global brainstorming, that I simply translated into C code. Many details and features of the implementation are purely mine, but the really big sparks, that got it to what it is, I'm not claiming for myself. Most importantly, "give me proof of concept before we can talk about changing backend code" was not part of the process at all. We were pretty eager to change things back then, when we needed to get better in almost every way possible ... are we so good at replication that we need to be conservative in that respect now? We are certainly good at some things and have to be conservative with respect to them, but replication in my not so very humble opinion isn't one of them.

I do understand that we have a codebase used in production these days. And because of that we have to maintain code and syntax stability to a degree, we didn't have back in the glory days of introducing EXCEPT and INTERCEPT (who's first incarnation was committed to the code base while completely destroying my entire work of fixing the rewriter). Maybe we need to introduce something entirely different, like the concept of an experimental feature. Something that we add to the code but that is explicitly flagged as not final, not stable, not guaranteed to stay or work in this or any other form. This requires that the feature has very limited interference with other parts of the system, like (or especially like) the query parser. If it turns out to be a problem in x.y.0, it will be backed out and gone in x.y.1. Or in a different way, like we create an experimental CVS branch off of every major release. That way, developers can easier share experimental code and if things settle there, they will be considered to be adopted into HEAD.

Like Markus, I would like to see the various replication efforts merged as
best they can be because even if the majority of users don't use a little
bit of everything, surely the more interesting cases would like to and the
entire community is better served if the various "solutions" are in

No doubt about that and I was the one organizing the Afilias sponsored meeting in Toronto back then, where my reversed Postgres-R idea was taken apart because it won't scale due to the gigantic amount of synchronized group communication it would require. Again, it might be that experimental features will cause more of the efforts to converge by using the same base as a compromise instead of having each and every support feature being designed completely independent.

I still have a hard time understanding why someone would object to adding a feature, however useless it might seem to them, as long as it doesn't cost them anything. Admitted, any feature causes maintenance costs on the side of the PostgreSQL development community (mainly those, who actually contribute and maintain the code - fortunately that is a finite number - everyone please ask themselves if they are part of that). But aside from that, would anyone, who is questioning the commit timestamp as I proposed it, likewise vehemently object to yet another procedural language, or adding another log tuning switch? I don't think so. As long as it doesn't cost you unless you turn it on, why would you even care if it serves my purpose or not? The thing that kicked off this emotional spin was that multimaster replication is what so many people want, but nobody has a universal solution for. Everyone wants to see "their" problem solved "as well", or the solution isn't good. Tell you what, I can live with my problem solved even if it doesn't solve yours. Can you tell me what I have to modify in order to solve your problem as well, or are you asking me to not implement anything unless "I" find a way to solve everyones problems in one, big, universal solution?


# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to