Skip site navigation (1) Skip section navigation (2)

Word-smithing doc changes

From: Greg Stark <stark(at)mit(dot)edu>
To: "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>
Subject: Word-smithing doc changes
Date: 2011-06-26 01:01:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I think this commit was ill-advised:;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372

     In a concurrent index build, the index is actually entered into the
     system catalogs in one transaction, then the two table scans occur in a
-    second and third transaction.
+    second and third transaction.  All active transactions at the time the
+    second table scan starts, not just ones that already involve the table,
+    have the potential to block the concurrent index creation until they
+    finish.  When checking for transactions that could still use the original
+    index, concurrent index creation advances through potentially interfering
+    older transactions one at a time, obtaining shared locks on their virtual
+    transaction identifiers to wait for them to complete.

Seems way to implementation-specific and detailed for a user to make
heads or tails of. Except in the sections talking about locking
internals we don't talk about "shared locks on virtual transactions
identifiers" we just talk about waiting for a transaction to complete.
And looping over the transactions one by one is purely an
implementation detail and uninteresting to users. Also it uses
ill-defined terms like "active transactions", "potentially interfering
older transactions", and  "original index" -- from the user's point of
view there's only one index and it just isn't completely built yet.

Are we not yet in string-freeze though? I'll go ahead and edit it if
people don't mind. I'm curious to see the original complaint though.



pgsql-hackers by date

Next:From: Jeff DavisDate: 2011-06-26 07:18:52
Subject: Range Types and length function
Previous:From: Greg StarkDate: 2011-06-26 00:26:20
Subject: Re: spinlock contention

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group