From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synchronization levels in SR |
Date: | 2010-06-02 17:37:59 |
Message-ID: | 4C0696F7.70001@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>
>> It's pretty scary to call a user-defined function at that point in
>> transaction.
>>
>
> Not so much "pretty scary" as "zero chance of being accepted".
> And I do mean zero.
>
I swear, you guys are such buzzkills some days. I was suggesting a
model for building easy prototypes, and advocating a more formal way to
explain, in what could be code form, what someone means when they
suggest a particular quorum model or the like. Maybe all that will ever
be exposed into a production server are the best of the hand-written
implementations, and the scary "try your prototype here" hook only shows
up in debug builds, or never gets written at all. I did comment that I
expected faster built-in implementations to be the primary way these
would be handled.
From what Heikki said, it sounds like the main thing I was didn't
remember is to include some timestamp information to allow rules based
on that information too.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-06-02 17:44:26 | Re: Keepalive for max_standby_delay |
Previous Message | Stephen Frost | 2010-06-02 17:36:52 | Re: Keepalive for max_standby_delay |