Re: Exposing the Xact commit order to the user - Mailing list pgsql-hackers

On Thu, Jun 3, 2010 at 6:29 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Jan Wieck wrote:
>> On 6/3/2010 4:04 PM, Bruce Momjian wrote:
>> > If you want to fork Postgres and add it, go ahead, but if the community
>> > has to maintain the code and document it, we care.
>>
>> That comment was rather unprofessional. I think the rest of us still try
>> to find the best solution for the problem, not kill the discussion. You
>> may want to rejoin that effort.
>>
>> I care about an efficient, low overhead way to get a certain
>> information, that is otherwise extremely difficult, expensive and
>> version dependent to get.
>>
>> I care about cleaning up more of the mistakes, made in the original
>> development of Slony. Namely using hacks and kluges to implement
>> details, not supported by a current version of PostgreSQL. Londiste and
>> Slony made a good leap on that with the txid data type. Slony made
>> another step like that with 2.0, switching to the (for that very purpose
>> developed and contributed) native trigger configuration instead of
>> hacking system catalogs. This would be another step in that direction
>> and we would be able to unify Londiste's and Slony's transport mechanism
>> and eliminating the tick/sync kluge.
>>
>> Care to explain what exactly you care about?
>
> Here is what I was replying to:
>
>> >> I actually have a hard time understanding why people are so opposed t$
>> > >> feature that has zero impact at all unless a DBA actually turns in ON.
>> >> What is the problem with exposing the commit order of transactions?
>
> Jan's comment is why should others care what he wants because it has
> zero impact?  I am saying the community cares because we have to
> maintain the code.  I stand by my comment.
>
> I remember a dismissive comment by Jan when 'session_replication_role'
> was added, and a similar strong comment from me at that time as well.
> It seems we are doing this again.

I think it's entirely legitimate and proper for us to make a decision
about whether this feature is worth including in core PostgreSQL.  We
are obviously not in the business of adding random features solely for
the benefit of third-party applications.  That having been said, there
are several reasons why I believe that this particular feature is an
excellent candidate for inclusion in core.

1. It solves a problem for which there is no easy workaround.
Rereading all the WAL to extract the commit records is not an easy
workaround, nor is what Slony and Londiste are doing now.

2. It is usable by multiple projects, not just one.  It may well have
applications beyond replication (e.g. distributed transactions), but
at a very minimum it is usable by and useful to multiple replication
solutions.

3. It has a clear specification which can be easily understood even by
people who do not fully understand how replication solutions will make
use of it, which makes code maintenance much less burdensome.
Obviously, Jan's original email on this topic was just a sketch, but I
find it to be pretty clear.

4. We have an existing precedent of being willing to add limited
support into core to allow replication solutions to do their thing
(session_replication_role, ALTER TABLE ... ENABLE REPLICA TRIGGER,
etc).  Even though we now have built-in replication via HS and SR,
there is still a BIG use case for Slony, Londiste, and other add-on
tools.  Making those tools more successful and performant is good for
PostgreSQL.

5. It does not involve highly invasive changes to the core code.

6. It can be turned off for users who don't want it.

I find the skeptical attitude on this thread altogether unwarranted.
Jan made his case and, at least IMHO, presented it pretty clearly.  He
then answered, multiple times, numerous questions which were already
addressed in the original email, as well as various others.  I think
we should be very careful about assuming that we understand
replication and its needs better than someone who has spent many years
developing one of the major PostgreSQL replication solutions.
Independent of Jan's qualifications, there are clearly several people
on this thread who understand why this is useful and valuable,
including me.  I am obviously not in a position to insist that we
accept this feature (assuming Jan produces a patch rather than getting
discouraged and giving up) but I would like us to think very, very
carefully before rejecting it, and not to do so unless we have a DARN
good reason.  Most patches add code, and therefore require code
maintenance - that is not, by itself, a reason to reject them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company