> I think > we need a detailed design document for how this is all going to work. > We need to not only handle the master properly but also handle the > slave properly. Consider, for example, the case where the slave > begins to replay the transaction, reaches a restartpoint after > replaying some of the new pages, and then crashes. If the subsequent > restart from the restartpoint blows away the main relation fork, we're > hosed. I fear we're plunging into implementation details without > having a good overall design in mind first.
As I said in my first post, I'm basing the patch on the post: http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php So I assumed the design was ok (except for the "stray file around on a standby" case, which has been discussed earlier on this thread). If there are things to be discussed/analyzed (I guess the restart point thing is one of those) we can do it... but I thought that the whole design was somehow in place Leonardo -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
