| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | 82820676(at)qq(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16102: Table can't be drop on PostgreSQL 10.09 if the table was created from PostgreSQL 10.10 |
| Date: | 2019-11-08 15:06:38 |
| Message-ID: | 982.1573225598@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Have anyone meet table can't be drop on PostgreSQL 10.09 if the table was
> created from PostgreSQL 10.10?
Certainly possible, seeing that the 10.10 release notes mention
additional dependency rules for partitioned tables:
* Install dependencies to prevent dropping partition key columns
> 2) Remove v10.10 and use v10.09 start with same storage (our downgrade test
> on K8s, storage are decouple with application )
It is not, never has been, and never will be supported to try to run
a cluster with an older server version after it's been modified by
a newer one. We have enough trouble ensuring forwards compatibility.
Having said that, the 10.10 bug fix should only have made a difference in
cases where a table's partition key columns involve non-built-in types,
which isn't the case in your example. I wonder whether this is pilot
error, e.g. you created and dropped the pgbench_accounts table in some
other schema than "public", but there's still one in "public".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2019-11-08 15:47:53 | Re: EXPLAIN ANALYZE not displaying recheck condition |
| Previous Message | Magnus Hagander | 2019-11-08 12:20:35 | Re: [PATCH] 32x32 and 48x48 favicons |