On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Oct 24, 2017 at 1:26 PM, Ivan Kartyshov > <i.kartyshov@postgrespro.ru> wrote: >> Hello. I made some bugfixes and rewrite the patch. > > I don't think it's a good idea to deliberately leave the state of the > standby different from the state of the master on the theory that it > won't matter. I feel like that's something that's likely to come back > to bite us.
I agree with Robert. What happen if we intentionally don't apply the truncation WAL and switched over? If we insert a tuple on the new master server to a block that has been truncated on the old master, the WAL apply on the new standby will fail? I guess there are such corner cases causing failures of WAL replay after switch-over.
Yes, that looks dangerous. One approach to cope that could be teaching heap redo function to handle such these situations. But I expect this approach to be criticized for bad design. And I understand fairness of this criticism.
However, from user prospective of view, current behavior of hot_standby_feedback is just broken, because it both increases bloat and doesn't guarantee that read-only query on standby wouldn't be cancelled because of vacuum. Therefore, we should be looking for solution: if one approach isn't good enough, then we should look for another approach.
I can propose following alternative approach: teach read-only queries on hot standby to tolerate concurrent relation truncation. Therefore, when non-existent heap page is accessed on hot standby, we can know that it was deleted by concurrent truncation and should be assumed to be empty. Any thoughts?
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
