On 6/3/2010 5:58 PM, Greg Stark wrote:
> On Thu, Jun 3, 2010 at 8:50 PM, Jan Wieck <JanWieck@yahoo.com> wrote:
>>> I'm puzzled how you would define this value. How do you add 7 inserts,
>>> 7 deletes, and 7 updates? Is that 21 rows modified?
>>
>> I actually have a hard time understanding why people are so opposed to a
>> 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?
>
> The post you were responding to was regarding the meaninglessness of
> the "number of records" attribute you wanted. Your response is a non
> sequitor.
I never proposed a "number of records" attribute. I proposed a sum of
the row counts in the statistics collector. That row count would be a
mix of insert, update, delete and toast operations. It's not an exact
indicator of anything, but a good enough hint of how much data may come
down the pipe if I were to select all replication data belonging to that
transaction.
>
> I think the commit order of transactions would be a good thing to
> expose though I've asked repeatedly what kind of interface you need
> and never gotten answers to all the questions.
In the original email that started this whole thread I wrote:
> Exposing the data will be done via a set returning function. The SRF
> takes two arguments. The maximum number of rows to return and the last
> serial number processed by the reader. The advantage of such SRF is that
> the result can be used in a query that right away delivers audit or
> replication log information in transaction commit order. The SRF can
> return an empty set if no further transactions have committed since, or
> an error if data segments needed to answer the request have already been
> purged.
Did that not answer your question?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin