From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: [DOC] Document concurrent index builds waiting on each other |
Date: | 2021-01-13 18:42:17 |
Message-ID: | CAAaqYe-0xO2HbkyHeMYikkArkWtQCidb-5F-cAyrYPk_DkUBZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2021-01-13 19:44:50 | Re: Add docs stub for recovery.conf |
Previous Message | Tom Lane | 2021-01-13 18:20:46 | Re: pg_preadv() and pg_pwritev() |