| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Sketch of a fix for that truncation data corruption issue |
| Date: | 2018-12-11 06:15:51 |
| Message-ID: | 20181211061551.4wbxeoafqjmjbirq@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-12-11 07:09:34 +0100, Laurenz Albe wrote:
> Tom Lane wrote:
> > We got another report today [1] that seems to be due to the problem
> > we've seen before with failed vacuum truncations leaving corrupt state
> > on-disk [2]. Reflecting on that some more, [...]
>
> This may seem heretical, but I'll say it anyway.
>
> Why don't we do away with vacuum truncation for good?
> Is that a feature that does anybody any good?
> To me it has always seemed to be more a wart than a feature, like
> someone just thought it was low hanging fruit without considering
> all the implications.
There's a lot of workloads that I've seen that'd regress. And probably a
lot more that we don't know about. I don't see how we could go there.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ibrar Ahmed | 2018-12-11 06:24:33 | Re: Interesting paper: Contention-Aware Lock Scheduling |
| Previous Message | Laurenz Albe | 2018-12-11 06:09:34 | Re: Sketch of a fix for that truncation data corruption issue |