| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [HACKERS] WIP: Covering + unique indexes. |
| Date: | 2018-01-21 11:22:15 |
| Message-ID: | 7FEB0867-F4F2-4F18-8AA9-7BAA0BB32868@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 21 янв. 2018 г., в 3:36, Peter Geoghegan <pg(at)bowt(dot)ie> написал(а):
>
> On Wed, Jan 17, 2018 at 12:45 AM, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>> Unfortunately, amcheck_next does not work currently on HEAD (there are problems with AllocSetContextCreate() signature), but I've tested bt_index_check() before, during and after pgbench, on primary and on slave. Also, I've checked bt_index_parent_check() on master.
>
> I fixed that recently. It should be fine now.
Oh, sorry, missed that I'm using patched stale amcheck_next. Thanks!
Affirmative, amcheck_next works fine.
I run pgbench against several covering indexes. Checking before load, during and after, both on master and slave.
I do not observe any errors besides infrequent "canceling statement due to conflict with recovery", which is not a sign of any malfunction.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2018-01-21 11:42:13 | Re: [HACKERS] Supporting huge pages on Windows |
| Previous Message | Dean Rasheed | 2018-01-21 11:10:11 | Re: MCV lists for highly skewed distributions |