On 6/3/2010 5:58 PM, Greg Stark wrote:
On Thu, Jun 3, 2010 at 8:50 PM, Jan Wieck <janwi...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
