| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <rhaas(at)postgresql(dot)org> |
| Cc: | "pgsql-committers(at)postgresql(dot)org" <pgsql-committers(at)postgresql(dot)org> |
| Subject: | Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i |
| Date: | 2017-12-06 20:32:38 |
| Message-ID: | 0C15CC12-F34A-4CC1-B209-9D6C92291F41@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 12/6/17, 1:23 PM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
> Perhaps this could be fixed by modifying the database-wide cases to
> use partitioned tables instead. The individual partitions will not
> have RangeVars specified, so it would cover the case when logging
> should be skipped.
This fixed the problem for me. I've attached a patch.
Nathan
| Attachment | Content-Type | Size |
|---|---|---|
| fix_vacuum_concurrent_drop_test_v1.patch | application/octet-stream | 5.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-12-06 21:31:10 | Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i |
| Previous Message | Robert Haas | 2017-12-06 20:28:12 | Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2017-12-06 20:44:56 | Re: Accessing base table relational names via RelOptInfo |
| Previous Message | Robert Haas | 2017-12-06 20:28:12 | Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i |