Exposing the Xact commit order to the user
in [PgSql]
|
Prev: [HACKERS] Exposing the Xact commit order to the user
Next: [HACKERS] Synchronization levels in SR
From: Jan Wieck on 3 Jun 2010 19:49 On 6/3/2010 6:24 PM, Kevin Grittner wrote: > Apologies for not looking back to the start of the thread before > that last post. It was all laid out right at the start. No need to apologize. Happens. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 3 Jun 2010 19:52 On 6/3/2010 7:11 PM, Alvaro Herrera wrote: > Excerpts from Chris Browne's message of jue jun 03 16:21:35 -0400 2010: > >> What this offers is *SOME* idea of how much updating work a particular >> transaction did. It's a bit worse than you suggest: >> >> - If replication triggers have captured tuples, those would get >> counted. >> >> - TOAST updates might lead to extra updates being counted. >> >> But back to where you started, I'd anticipate 7 inserts, 7 deletes, >> and 7 updates being counted as something around 21 updates. >> >> And if that included 5 TOAST changes, it might bump up to 26. >> >> If there were replication triggers in place, that might bump the count >> up to 45 (which I chose arbitrarily). > > Why not send separate numbers of tuple inserts/updates/deletes, which we > already have from pgstats? > We only have them for the entire database. The purpose of this is just a guesstimate about what data volume to expect if I were to select all log from a particular transaction. This datum isn't critical, just handy for the overall feature to be useful. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 3 Jun 2010 21:42 Bruce Momjian wrote: > > 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. FYI, I talked to Jan on the phone and we have resolved this issue. :-) -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 4 Jun 2010 12:52 Excerpts from Jan Wieck's message of jue jun 03 19:52:19 -0400 2010: > On 6/3/2010 7:11 PM, Alvaro Herrera wrote: > > Why not send separate numbers of tuple inserts/updates/deletes, which we > > already have from pgstats? > > We only have them for the entire database. The purpose of this is just a > guesstimate about what data volume to expect if I were to select all log > from a particular transaction. But we already have per table counters. Couldn't we aggregate them per transaction as well, if this feature is enabled? I'm guessing that this is going to have some uses besides Slony; vague measurements could turn out to be unusable for some of these. -- Álvaro Herrera <alvherre(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 4 Jun 2010 16:02
On 6/4/2010 10:44 AM, Greg Stark wrote: > On Fri, Jun 4, 2010 at 2:32 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> I find the skeptical attitude on this thread altogether unwarranted. >> Jan made his case and, at least IMHO, presented it pretty clearly. > > Just to be clear I think the idea of exposing commit order is a > no-brainer. The specific interface is what I was questioning. > > A function which takes a starting xid and a number of transactions to > return seems very tied to one particular application. I could easily > see other systems such as a multi-master system instead only wanting > to compare two transactions to find out which committed first. Or > non-replication applications where you have an LSN and want to know > whether a given transaction had committed by that time. Read the proposal again. I mean the original mail that started this tread. The function does NOT take an xid as argument. Being able to compare two xid's against each other with respect to their commit order is eventually useful. The serial number of the data set, returned by the SRF as proposed, would perfectly satisfy that need. But not the way you envision for multimaster. Multimaster would ask "did xid X from server A commit before or after xid Y from server B?" That is a question completely outside the scope of this proposal. Please keep it real. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |