I wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2019-05-01 10:06:03 -0700, Andres Freund wrote: >>> I'm not sure this is the right short-term answer. Why isn't it, for now, >>> sufficient to do what I suggested with RelationSetNewRelfilenode() not >>> doing the CommandCounterIncrement(), and reindex_index() then doing the >>> SetReindexProcessing() before a CommandCounterIncrement()? That's like >>> ~10 line code change, and a few more with comments.
> That looks like a hack to me... > The main thing I'm worried about right now is that I realized that > our recovery from errors in this area is completely hosed, cf > https://www.postgresql.org/message-id/4541.1556736...@sss.pgh.pa.us OK, so per the other thread, it seems like the error recovery problem isn't going to affect this directly. However, I still don't like this proposal much; the reason being that it's a rather fundamental change in the API of RelationSetNewRelfilenode. This will certainly break any external callers of that function --- and silently, too. Admittedly, there might not be any outside callers, but I don't really like that assumption for something we're going to have to back-patch. The solution I'm thinking of should have much more localized effects, basically just in reindex_index and RelationSetNewRelfilenode, which is why I like it better. regards, tom lane
