On 02/05/2019 10:37, Heikki Linnakangas wrote:
> (resending, previous attempt didn't make it to pgsql-hackers)
>
> On 29/04/2019 16:16, Anastasia Lubennikova wrote:
>> In previous emails, I have sent two patches with test and bugfix (see
>> attached).
>> After Heikki shared his concerns, I've rechecked the algorithm and
>> haven't found any potential error.
>> So, if other hackers are agreed with my reasoning, the suggested fix is
>> sufficient and can be committed.
>
> I still believe there is a problem with grandparent splits with this.
> I'll try to construct a test case later this week, unless you manage to
> create one before that.
Here you go. If you apply the two patches from
https://www.postgresql.org/message-id/5d48ce28-34cf-9b03-5d42-dbd5457926bf%40postgrespro.ru,
and run the attached script, it will print out something like this:
postgres=# \i grandparent.sql
DROP TABLE
CREATE TABLE
INSERT 0 150000
CREATE INDEX
psql:grandparent.sql:27: NOTICE: working on 10000
psql:grandparent.sql:27: NOTICE: working on 20000
psql:grandparent.sql:27: NOTICE: working on 30000
psql:grandparent.sql:27: NOTICE: working on 40000
psql:grandparent.sql:27: NOTICE: working on 50000
psql:grandparent.sql:27: NOTICE: working on 60000
psql:grandparent.sql:27: NOTICE: working on 70000
psql:grandparent.sql:27: NOTICE: working on 80000
psql:grandparent.sql:27: NOTICE: working on 90000
psql:grandparent.sql:27: NOTICE: working on 100000
psql:grandparent.sql:27: NOTICE: working on 110000
psql:grandparent.sql:27: NOTICE: failed for 114034
psql:grandparent.sql:27: NOTICE: working on 120000
DO
That "failed for 114034" should not happen.
Fortunately, that's not too hard to fix. We just need to arrange things
so that the "retry_from_parent" flag also gets set for the grandparent,
when the grandparent is split. Like in the attached patch.
- Heikki