Greg Smith wrote: > Attached is a tar file with some test case demo scripts that demonstrate > the worst of the problems here IMHO.
Thanks for that! We've been discussing this for ages, so it's nice to have a concrete example. > I don't want to belittle that work because it's been important to make > HS a useful standalone feature, but I feel like that's all triage rather > than looking for the most robust fix possible. Ideally the standby would stash away the old pages or tuples somewhere so that it can still access them even after replaying the WAL records that remove them from the main storage. I realize that's not going to happen any time soon because it's hard to do, but that would really be the most robust fix possible. > I don't know how difficult the keepalive feature was expected to be, and > there's certainly plenty of potential landmines in this whole xid export > idea. One such landmine is that the keepalives need to flow from client to server while the WAL records are flowing from server to client. We'll have to crack that problem for synchronous replication too, but I think that alone is a big enough problem to make this 9.1 material. > How to handle situations where the standby goes away for a while, > such as a network outage, so that it doesn't block the master from ever > cleaning up dead tuples is a concern. Yeah, that's another issue that needs to be dealt with. You'd probably need some kind of a configurable escape valve in the master, to let it ignore a standby's snapshot once it gets too old. > But I do know that the current Hot Standby implementation is going to be > frustrating to configure correctly for people. Perhaps others who are not as deep into the code as I am will have a better view on this, but I seriously don't think that's such a big issue. I think the max_standby_delay setting is quite intuitive and easy to explain. Sure, it would better if there was no tradeoff between killing queries and stalling recovery, but I don't think it'll be that hard to understand the tradeoff. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers