On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > On 2021-Jan-13, James Coleman wrote: > > > On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier <mich...@paquier.xyz> > > wrote: > > > > > > On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote: > > > > I looked into this again, and I didn't like what I had added to > > > > maintenance.sgml at all. It seems out of place where I put it; and I > > > > couldn't find any great spots. Going back to your original proposal, > > > > what about something like this? It's just one more para in the "notes" > > > > section in CREATE INDEX and REINDEX pages, without any additions to the > > > > VACUUM pages. > > > > > > +1. > > > > I think one more para in the notes is good. But shouldn't we still > > clarify the issue is specific to CONCURRENTLY? > > How is it specific to concurrent builds? What we're documenting here is > the behavior of vacuum, and that one is identical in both regular builds > and concurrent builds (since vacuum has to avoid removing rows from > under either of them). The only reason concurrent builds are > interesting is because they take longer. > > What was specific to concurrent builds was the fact that you can't have > more than one at a time, and that one is what was added in 58ebe967f.
Ah, right. I've mixed those up at least once on this thread already. > > Also that it's not just the table being indexed seems fairly significant. > > This is true. So I propose > > Like any long-running transaction, <command>REINDEX</command> can > affect which tuples can be removed by concurrent <command>VACUUM</command> > on any table. That sounds good to me. James
