Robert Haas <robertmh...@gmail.com> writes:
>> Of course, there's no much point in an index that's easily corrupted, so
>> I understand the desire to implement WAL too -- I'm just pointing out
>> that concurrency could have been developed independently.
> Anything's possible with enough work, but having good support in -core
> makes it easier and -core has usually been receptive to requests for
> such things - for example, I think Tom put in quite a bit of work to
> getting the right hooks in to enable libpqtypes.
Well, in fact, that's an exceedingly apt and instructive comparison.
The hooks that went into libpq resulted from several iterations of
design against a real, live, working application for those hooks.
The proposed rmgr patch is apparently suffering from no such handicap
as having been proven to satisfy the needs of real code :-(
There are other recent examples of proposed hooks that in fact
failed to be useful because of some oversight or other, and it was
not until we insisted on seeing a live use of the hooks that this
became apparent. (IIRC, one or both of the planner-related hooks
that are new in 8.4 had such issues.)
I generally agree that pluggable rmgr support would be a good idea,
but I would much rather put off making the hooks until we have a live
application for them to prove that they are useful and usable. If
we make a hook now sans test case, then what happens if we discover
later that it's not quite right? We'd have to figure out whether there's
a need for backwards-compatible behavior, and we will have a hard time
knowing whether there are any live uses of the hook in the field.
So my take on this is to wait. If it were actually needed by the hot
standby code then of course the above argument would be wrong, but
what I gather from the discussion is that it's not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
