On Wednesday, June 20, 2012 07:50:37 PM Robert Haas wrote: > On Wed, Jun 20, 2012 at 1:40 PM, Andres Freund <and...@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. I would go for all of them ;). The read only transaction warnings will probably result in the best error messages.
> 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. Interesting problem, yes. My first reaction was to just to warn and log and throw the transaction away... But thats not likely to work very well on the apply side... I don't think its a particularly likely problem though. An io function doing that would probably fail in lots of other situations (HS, read only transactions, permission problems). > >> 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. For others, a sensible entry point into this discussion before switching subthreads probably is in http://archives.postgresql.org/message- id/201206192023.20589.and...@2ndquadrant.com The table isn't as easy as you might think as the wal record only contains the relfilenode. Unless you want to log more its basically solved by solving the snapshot issue. And yes, agreeing on how to do that is the thing we need to solve next. Patch 07 (add enough information to wal) and this are the first ones that should get committed imo. And be ready for that obviously. Just noticed that I failed to properly add Patch 07 to the commitfest. I have done so now, hope thats ok. Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
