| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: Shaky coding for vacuuming partitioned relations |
| Date: | 2017-09-25 16:47:05 |
| Message-ID: | 3DD93508-8419-4006-B7C9-D3E85B5AC2EA@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/24/17, 10:12 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
> Attached is a proposal of patch.
The patch seems reasonable to me, and I haven't encountered any issues in
my tests, even after applying the vacuum-multiple-relations patch on top
of it.
+ * Take a lock here for the relation lookup. If ANALYZE or VACUUM spawn
+ * multiple transactions, the lock taken here will be gone once the
+ * current transaction running commits, which could cause the relation
+ * to be gone, or the RangeVar might not refer to the OID looked up here.
I think this could be slightly misleading. Perhaps it would be more
accurate to say that the lock will be gone any time vacuum() creates a new
transaction (either in vacuum_rel() or when use_own_xacts is true).
Nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Hernandez | 2017-09-25 16:48:05 | Re: Built-in plugin for logical decoding output |
| Previous Message | Petr Jelinek | 2017-09-25 16:39:47 | Re: Built-in plugin for logical decoding output |