On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> I realized a problem with that idea this morning: it might work for
>> reading things, but if anyone attempts to write data you've got big
>> problems. Maybe we could get away with forbidding that, not sure.
> Hm, why is writing a problem? You mean io conversion routines writing data?
> Yes, that will be a problem. I am fine with simply forbidding that, we should
> be able to catch that and provide a sensible error message, since SSI we have
> the support for that.
I think we could do something a little more vigorous than that, like
maybe error out if anyone tries to do anything that would write WAL or
acquire an XID. Of course, then the question becomes: then what? We
probably need to think about what happens after that - we don't want
an error replicating one row in one table to permanently break
replication for the entire system.
>> Sorry. I don't think you're planning to do something evil, but before
>> I thought you said you did NOT want to write the code to extract
>> changes as text or something similar.
> Hm. I might have been a bit ambiguous when saying that I do not want to
> provide everything for that use-case.
> Once we have a callpoint that has a correct catalog snapshot for exactly the
> tuple in question text conversion is damn near trivial. The point where you
> get passed all that information (action, tuple, table, snapshot) is the one I
> think the patch should mainly provide.
This is actually a very interesting list. We could rephrase the
high-level question about the design of this feature as "what is the
best way to make sure that you have these things available?". Action
and tuple are trivial to get, and table isn't too hard either. It's
really the snapshot - and all the downstream information that can only
be obtained via using that snapshot - that is the hard part.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company