| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Draft back-branch release notes are up for review |
| Date: | 2019-06-15 22:12:50 |
| Message-ID: | CAH2-Wz=w+byD80jb3R5hGFB9artrgn84FtSTW8z41wX6-XwX8A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jun 15, 2019 at 3:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thanks for the input, guys. What do you think of
>
> Avoid writing an invalid empty btree index page in the unlikely case
> that a failure occurs while processing INCLUDEd columns during a page
> split (Peter Geoghegan)
>
> The invalid page would not affect normal index operations, but it
> might cause failures in subsequent VACUUMs. If that has happened to
> one of your indexes, recover by reindexing the index.
That seems perfect.
Thanks
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2019-06-15 22:14:28 | Re: Draft back-branch release notes are up for review |
| Previous Message | Oleksii Kliukin | 2019-06-15 22:12:21 | Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock |