| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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 23:49:25 |
| Message-ID: | 1342637.1610581765@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
James Coleman <jtc331(at)gmail(dot)com> writes:
> On Wed, Jan 13, 2021 at 5:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> [ raised eyebrow ] Surely REINDEX and VACUUM can't run on the same
>> table at the same time.
> + Like any long-running transaction, <command>CREATE INDEX</command> on a
> + table can affect which tuples can be removed by concurrent
> + <command>VACUUM</command> on any other table.
> The "on a table" is the table on which the REINDEX/CREATE INDEX is
> occurring. The "any other table" is where VACUUM might run.
I still think it'd be just as clear without the auxiliary clauses,
say
+ Like any long-running transaction, <command>CREATE INDEX</command>
+ can affect which tuples can be removed by concurrent
+ <command>VACUUM</command> operations.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-01-14 00:24:12 | Re: vacuum_cost_page_miss default value and modern hardware |
| Previous Message | Peter Geoghegan | 2021-01-13 23:47:52 | Re: Yet another fast GiST build |