On 2/7/2007 7:13 AM, José Orlando Pereira wrote:
> On Saturday 03 February 2007, Bruce Momjian wrote:
>> Jan Wieck wrote:
>> > I don't have any such paper and the proof of concept will be the
>> > implementation of the system. I do however see enough resistance against
>> > this proposal to withdraw the commit timestamp at this time. The new
>> > replication system will therefore require the installation of a patched,
>> > non-standard PostgreSQL version, compiled from sources cluster wide in
>> > order to be used. I am aware that this will dramatically reduce it's
>> > popularity but it is impossible to develop this essential feature as an
>> > external module.
>> >
>> > I thank everyone for their attention.
>>
>> Going and working on it on your own doesn't seem like the proper
>> solution. I don't see people objecting to adding it, but they want it
>> work, which I am sure you want too. You have to show how it will work
>> and convince others of that, and then you have a higher chance it will
>> work, and be in the PostgreSQL codebase.
>
> Hi,
>
> Would it be possible to solve the problem using the GORDA on-commit hook?
>
> Jan would be able reliably obtain a commit timestamp with the desired
> semantics and store it in a regular table within transaction boundaries.
I am not sure, I would have to look at what exactly that hook provides.
The key to a Lamport timestamp is that it is advancing it commit order
(plus some other things ... of course). If the hook can guarantee that
the calls are made always in commit order, serialized without any race
condition possible, it would probably be suitable.
Jan
>
> PostgreSQL would not have to commit to a specific timestamp semantics and the
> patch is quite small.
>
> Regards,
>
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
