On Wed, Jun 17, 2020 at 12:45 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Writing hint bits and marking index tuples as killed do not write WAL > > unless checksums are enabled. > > And your point is? I thought enabling checksums was considered > good practice these days.
I don't want to have an argument about what typical or best practices are; I wasn't trying to make any point about that one way or the other. I'm just saying that the operations you listed don't necessarily all write WAL. In an event, even if they did, the larger point is that standbys work like that, too, so it's not unprecedented or illogical to think of such things. > >> You're right that these are the same things that we already forbid on a > >> standby, for the same reason, so maybe it won't be as hard to identify > >> them as I feared. I wonder whether we should envision this as "demote > >> primary to standby" rather than an independent feature. > > > See my comments on the nearby pg_demote thread. I think we want both. > > Well, if pg_demote can be done for X amount of effort, and largely > gets the job done, while this requires 10X or 100X the effort and > introduces 10X or 100X as many bugs, I'm not especially convinced > that we want both. Sure: if two features duplicate each other, and one of them is way more work and way more buggy, then it's silly to have both, and we should just accept the easy, bug-free one. However, as I said in the other email to which I referred you, I currently believe that these two features actually don't duplicate each other and that using them both together would be quite beneficial. Also, even if they did, I don't know where you are getting the idea that this feature will be 10X or 100X more work and more buggy than the other one. I have looked at this code prior to it being posted, but I haven't looked at the other code at all; I am guessing that you have looked at neither. I would be happy if you did, because it is often the case that architectural issues that escape other people are apparent to you upon examination, and it's always nice to know about those earlier rather than later so that one can decide to (a) give up or (b) fix them. But I see no point in speculating in the abstract that such issues may exist and that they may be more severe in one case than the other. My own guess is that, properly implemented, they are within 2-3X of each in one direction or the other, not 10-100X. It is almost unbelievable to me that the pg_demote patch could be 100X simpler than this one; if it were, I'd be practically certain it was a 5-minute hack job unworthy of any serious consideration. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
