| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, 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:05:00 |
| Message-ID: | 1361.1560636300@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Sat, Jun 15, 2019 at 02:11:41PM -0700, Peter Geoghegan wrote:
>> I agree that this isn't terribly significant in general. Your proposed
>> wording seems better than what we have now, but a reference to INCLUDE
>> indexes also seems like a good idea. They are the only type of index
>> that could possibly have the issue with page deletion/VACUUM becoming
>> confused.
> If true, that's important to mention, yes.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleksii Kliukin | 2019-06-15 22:12:21 | Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock |
| Previous Message | Noah Misch | 2019-06-15 21:42:50 | Re: Draft back-branch release notes are up for review |