Thread: Code comment change
There is some language in a code comment that has been bothering me for several years now. After pointing it out in a conversation off-list recently, I figured it was past time to do something about it. Patch attached. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachment
On Sun, Jun 23, 2019 at 9:21 PM Vik Fearing <vik.fearing@2ndquadrant.com> wrote: > There is some language in a code comment that has been bothering me for > several years now. After pointing it out in a conversation off-list > recently, I figured it was past time to do something about it. > > Patch attached. Pushed. Thanks! -- Thomas Munro https://enterprisedb.com
On 23/06/2019 12:35, Thomas Munro wrote: > On Sun, Jun 23, 2019 at 9:21 PM Vik Fearing <vik.fearing@2ndquadrant.com> wrote: >> There is some language in a code comment that has been bothering me for >> several years now. After pointing it out in a conversation off-list >> recently, I figured it was past time to do something about it. >> >> Patch attached. > > Pushed. Thanks! Thank you! -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Sun, Jun 23, 2019 at 3:36 AM Thomas Munro <thomas.munro@gmail.com> wrote: > Pushed. Thanks! I wonder what the comment is supposed to mean. I think that it's addressing the situation prior to commit 70508ba7aed in 2003, which was the point when the "fast" root concept was introduced. Prior to that commit, there was only what we would now call a true root, and _bt_getroot() had to loop to make sure that it reliably found it without deadlocking, while dealing with concurrent splits. This was necessary because the old design also involved maintaining a pointer to each page's parent in each page, which sounds like a seriously bad approach to me. I think that the whole sentence about "the standard class of race conditions" should go. There is no more dance. Nothing in _bt_getroot() is surprising to me. The other comments explain things comprehensively. -- Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
> On Sun, Jun 23, 2019 at 3:36 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> Pushed. Thanks!
> I wonder what the comment is supposed to mean.
> I think that it's addressing the situation prior to commit 70508ba7aed
> in 2003, which was the point when the "fast" root concept was
> introduced.
Yeah. I did some research into the provenance of that comment when
Thomas pushed the change. It's *old*. The whole para exists verbatim
in Postgres v4r2, src/backend/access/nbtree/nbtpage.c dated 1993-12-10
(in my copy of that tarball). The only change since then has been to
change the whitespace for 4-space tabs.
Even more interesting, the same para also exists verbatim in
v4r2's src/backend/access/nobtree/nobtpage.c, which is dated 1991-10-29
in the same tarball. (If you're wondering, "nobtree" seems to stand
for "no-overwrite btree"; so I suppose it went the way of all flesh
when Stonebraker lost interest in write-once mass storage.) So presumably
this comment dates back to some common ancestor of the mainline btree code
and the no-overwrite code, which must have been even older than the 1991
date.
This is only marginally relevant to what we should do about it today,
but I think it's reasonable to conclude that the current locking
considerations are nearly unrelated to what they were when the comment
was written.
> I think that the whole sentence about "the standard class of race
> conditions" should go. There is no more dance. Nothing in
> _bt_getroot() is surprising to me. The other comments explain things
> comprehensively.
+1
regards, tom lane
On Mon, Jul 1, 2019 at 7:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Even more interesting, the same para also exists verbatim in > v4r2's src/backend/access/nobtree/nobtpage.c, which is dated 1991-10-29 > in the same tarball. (If you're wondering, "nobtree" seems to stand > for "no-overwrite btree"; so I suppose it went the way of all flesh > when Stonebraker lost interest in write-once mass storage.) So presumably > this comment dates back to some common ancestor of the mainline btree code > and the no-overwrite code, which must have been even older than the 1991 > date. "no-overwrite btree" is described here, if you're interested: https://pdfs.semanticscholar.org/a0de/438d5efd96e8af51bc7595aa1c30d0497a57.pdf This is a link to the B-Tree focused paper "An Index Implementation Supporting Fast Recovery for the POSTGRES Storage System". I found that the paper provided me with some interesting historic context. I am pretty sure that the authors were involved in early work on the Postgres B-Tree code. It references Lanin and Shasha, even though the nbtree code that is influenced by L&S first appears in the same 2003 commit of yours that I mentioned. > > I think that the whole sentence about "the standard class of race > > conditions" should go. There is no more dance. Nothing in > > _bt_getroot() is surprising to me. The other comments explain things > > comprehensively. > > +1 I'll take care of it soon. -- Peter Geoghegan