Re: Proposal: Commit timestamp

I find the term "logical proof of it's correctness" too restrictive. It
sounds like some formal academic process that really doesn't work well
for us.

What I did want to hear is a layout of how the system would work, and an
exchange of ideas until almost everyone was happy.

Also, I saw the trigger patch with no explaination of why it was
important or who would use it --- that also isn't going to fly well.

So, to add something, the community needs to hear how it is going to
help users, because every code addition has cost, and we don't want to
add things unless it has general utility. If someone can't explain the
utility of an addition, I question whether the person has fully thought
through were they are going.

As far as adding a language, no, we would not just add any language. We
would judge whether the language has usefulness to our users. I think
APL would be cool, but I am not sure it is usable, so there is a hurdle
even there.

As far as TOAST, there is no question in my mind that TOAST development
would happen the same way today as it did when we did it in 2001 --- we
have a problem, how can we fix it.

---------------------------------------------------------------------------

Jan Wieck wrote:
> 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
> > harmony.
>
> 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?
>
>
> Jan
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #================================================== JanWieck(at)Yahoo(dot)com #
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +