Re: [DOC] Document concurrent index builds waiting on each other - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [DOC] Document concurrent index builds waiting on each other
Date
Msg-id 20210113211604.GA16584@alvherre.pgsql
Whole thread Raw
In response to Re: [DOC] Document concurrent index builds waiting on each other  (James Coleman <jtc331@gmail.com>)
Responses Re: [DOC] Document concurrent index builds waiting on each other
List pgsql-hackers
On 2021-Jan-13, James Coleman wrote:

> On Wed, Jan 13, 2021 at 4:05 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > On 2021-Jan-13, James Coleman wrote:
> >
> > > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > > > 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.
> >
> > Great, pushed with one more wording tweak: "REINDEX on any table can
> > affect ... on any other table".  To pg12 and up.
> 
> Looks like what got committed is "REINDEX on a table" not "on any",
> but I'm not sure that matters too much.

Ouch.  The difference seems slight enough that it doesn't matter; is it
ungrammatical?

Either way I'm gonna close this CF entry now, finally.  Thank you for
your patience!

-- 
Álvaro Herrera       Valdivia, Chile
"I can't go to a restaurant and order food because I keep looking at the
fonts on the menu.  Five minutes later I realize that it's also talking
about food" (Donald Knuth)



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [DOC] Document concurrent index builds waiting on each other
Next
From: Stephen Frost
Date:
Subject: Re: automatic analyze: readahead - add "IO read time" log message