| From: | Adam Brusselback <adambrusselback(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Oleg Bartunov <obartunov(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Custom compression methods |
| Date: | 2017-11-06 01:00:14 |
| Message-ID: | CAMjNa7cPynatwNDm9JQn2eJRu7Y5ARcw09Nbg5q8O_DfiY6=ww@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> If there's no data compressed
> using the compression method you dropped, everything is cool -
> otherwise everything is broken and there's no way to recover.
> The only obvious alternative is to disallow DROP altogether (or make it
> not really DROP).
Wouldn't whatever was using the compression method have something
marking which method was used? If so, couldn't we just scan if there is
any data using it, and if so disallow the drop, or possibly an option to allow
the drop and rewrite the table either uncompressed, or with the default
compression method?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2017-11-06 01:02:58 | Re: Restricting maximum keep segments by repslots |
| Previous Message | Tsunakawa, Takayuki | 2017-11-06 00:36:16 | Re: Statement-level rollback |