| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: REINDEX CONCURRENTLY unexpectedly fails |
| Date: | 2020-01-14 08:47:09 |
| Message-ID: | 20200114084709.GI1515@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi Heikki,
On Thu, Jan 09, 2020 at 12:06:19PM +0900, Michael Paquier wrote:
> As the patch has been heavily modified, I am switching it back to
> "Needs Review" for now and I'd like to discuss more about the lock
> upgrade risks, particularly if it is considered worth the effort for
> temporary relations. Thoughts are welcome.
You are registered as a reviewer for this patch:
https://commitfest.postgresql.org/26/2358/
Are you planning to look at it? Do you have some thoughts to share
about what I wrote previously?
Discarding the lock upgrade considerations is possible. Another
approach would be, instead of ignoring CONCURRENTLY for temporary
tables, to fail if the operation is run, and ignore these when a
dabatase-wide reindex concurrently happens. This was not liked much
at the beginning of the thread though.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-01-14 08:55:05 | Re: libpq parameter parsing problem |
| Previous Message | Julien Rouhaud | 2020-01-14 07:57:36 | Re: Oracle To Community Postgresql Migration |