Re: Too rigorous assert in reorderbuffer.c
От | Arseny Sher |
---|---|
Тема | Re: Too rigorous assert in reorderbuffer.c |
Дата | |
Msg-id | 87lfr8wa5p.fsf@ars-thinkpad обсуждение исходный текст |
Ответ на | Re: Too rigorous assert in reorderbuffer.c (Arseny Sher <a.sher@postgrespro.ru>) |
Список | pgsql-hackers |
Arseny Sher <a.sher@postgrespro.ru> writes: > I'm sorry to bother you with this again, but due to new test our > internal buildfarm revealed that ajacent assert on cmin is also lie. You > see, we can't assume cmin is stable because the same key (relnode, tid) > might refer to completely different tuples if tuple was inserted by > aborted subxact, immeditaly reclaimed and then space occupied by another > one. Fix is attached. > > Technically this might mean a user-facing bug, because we only pick the > first cmin which means we might get visibility wrong, allowing to see > some version too early (i.e real cmin of tuple is y, but decoding thinks > it is x, and x < y). However, I couldn't quickly make up an example > where this would actually lead to bad consequences. I tried to create > such extra visible row in pg_attribute, but that's ok because loop in > RelationBuildTupleDesc spins exactly natts times and ignores what is > left unscanned. It is also ok with pg_class, because apparently > ScanPgRelation also fishes out the (right) first tuple and doesn't check > for duplicates appearing later in the scan. Maybe I just haven't tried > hard enough though. This issue still exists, it would be nice to fix it... -- Arseny Sher Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: