Remove TODO.detail files that contained useless or very old information.

Update TODO accordingly.

doc/TODO.detail/fsync

-From pgsql-hackers-owner+M908@postgresql.org Sun Nov 19 14:27:43 2000
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
-	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id OAA10885
-	for <pgman@candle.pha.pa.us>; Sun, 19 Nov 2000 14:27:42 -0500 (EST)
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
-	by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eAJJSMs83653;
-	Sun, 19 Nov 2000 14:28:22 -0500 (EST)
-	(envelope-from pgsql-hackers-owner+M908@postgresql.org)
-Received: from candle.pha.pa.us (candle.navpoint.com [162.33.245.46] (may be forged))
-	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eAJJQns83565
-	for <pgsql-hackers@postgreSQL.org>; Sun, 19 Nov 2000 14:26:49 -0500 (EST)
-	(envelope-from pgman@candle.pha.pa.us)
-Received: (from pgman@localhost)
-	by candle.pha.pa.us (8.9.0/8.9.0) id OAA06790;
-	Sun, 19 Nov 2000 14:23:06 -0500 (EST)
-From: Bruce Momjian <pgman@candle.pha.pa.us>
-Message-Id: <200011191923.OAA06790@candle.pha.pa.us>
-Subject: Re: [HACKERS] WAL fsync scheduling
-In-Reply-To: <002101c0525e$2d964480$b97a30d0@sectorbase.com> "from Vadim Mikheev
-	at Nov 19, 2000 11:23:19 am"
-To: Vadim Mikheev <vmikheev@sectorbase.com>
-Date: Sun, 19 Nov 2000 14:23:06 -0500 (EST)
-CC: Tom Samplonius <tom@sdf.com>, Alfred@candle.pha.pa.us,
-        Perlstein <bright@wintelcom.net>, Larry@candle.pha.pa.us,
-        Rosenman <ler@lerctr.org>,
-        PostgreSQL-development <pgsql-hackers@postgresql.org>
-X-Mailer: ELM [version 2.4ME+ PL77 (25)]
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Type: text/plain; charset=US-ASCII
-Precedence: bulk
-Sender: pgsql-hackers-owner@postgresql.org
-Status: OR
-
-[ Charset ISO-8859-1 unsupported, converting... ]
-> > There are two parts to transaction commit.  The first is writing all
-> > dirty buffers or log changes to the kernel, and second is fsync of the
->    ^^^^^^^^^^^^
-> Backend doesn't write any dirty buffer to the kernel at commit time.
-
-Yes, I suspected that.
-
-> 
-> > log file.
-> 
-> The first part is writing commit record into WAL buffers in shmem.
-> This is what XLogInsert does.  After that XLogFlush is called to ensure
-> that  entire commit record is on disk. XLogFlush does *both* write() and
-> fsync() (single slock is used for both writing and fsyncing) if it needs to
-> do it at all.
-
-Yes, I realize there are new steps in WAL.
-
-> 
-> > I suggest having a per-backend shared memory byte that has the following
-> > values:
-> > 
-> > START_LOG_WRITE
-> > WAIT_ON_FSYNC
-> > NOT_IN_COMMIT
-> > backend_number_doing_fsync
-> > 
-> > I suggest that when each backend starts a commit, it sets its byte to
-> > START_LOG_WRITE. 
->   ^^^^^^^^^^^^^^^^^^^^^^^
-> Isn't START_COMMIT more meaningful?
-
-Yes.
-
-> 
-> > When it gets ready to fsync, it checks all backends. 
->    ^^^^^^^^^^^^^^^^^^^^^^^^^^
-> What do you mean by this? The moment just after XLogInsert?
-
-Just before it calls fsync().
-
-> 
-> > If all are NOT_IN_COMMIT, it does fsync and continues.
-> 
-> 1st edition:
-> > If one or more are in START_LOG_WRITE, it waits until no one is in
-> > START_LOG_WRITE.  It then checks all WAIT_ON_FSYNC, and if it is the
-> > lowest backend in WAIT_ON_FSYNC, marks all others with its backend
-> > number, and does fsync.  It then clears all backends with its number to
-> > NOT_IN_COMMIT.  Other backend will see they are not the lowest
-> > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
-> > so they can then continue, knowing their data was synced.
-> 
-> 2nd edition:
-> > I have another idea.  If a backend gets to the point that it needs
-> > fsync, and there is another backend in START_LOG_WRITE, it can go to an
-> > interuptable sleep, knowing another backend will perform the fsync and
-> > wake it up.  Therefore, there is no busy-wait or timed sleep.
-> > 
-> > Of course, a backend must set its status to WAIT_ON_FSYNC to avoid a
-> > race condition.
-> 
-> The 2nd edition is much better. But I'm not sure do we really need in
-> these per-backend bytes in shmem. Why not just have some counters?
-> We can use a semaphore to wake-up all waiters at once.
-
-Yes, that is much better and clearer.  My idea was just to say, "if no
-one is entering commit phase, do the commit.  If someone else is coming,
-sleep and wait for them to do the fsync and wake me up with a singal."  
-
-> 
-> > This allows a single backend not to sleep, and allows multiple backends
-> > to bunch up only when they are all about to commit.
-> > 
-> > The reason backend numbers are written is so other backends entering the
-> > commit code will not interfere with the backends performing fsync.
-> 
-> Being waked-up backend can check what's written/fsynced by calling XLogFlush.
-
-Seems that may not be needed anymore with a counter.  The only issue is
-that other backends may enter commit while fsync() is happening.  The
-process that did the fsync must be sure to wake up only the backends
-that were waiting for it, and not other backends that may be also be
-doing fsync as a group while the first fsync was happening.  I leave
-those details to people more experienced.  :-)
-
-I am just glad people liked my idea.
-
--- 
-  Bruce Momjian                        |  http://candle.pha.pa.us
-  pgman@candle.pha.pa.us               |  (610) 853-3000
-  +  If your life is a hard drive,     |  830 Blythe Avenue
-  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
-

doc/TODO.detail/persistent

-From owner-pgsql-hackers@hub.org Mon May 11 11:31:09 1998
-Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
-	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA03006
-	for <maillist@candle.pha.pa.us>; Mon, 11 May 1998 11:31:07 -0400 (EDT)
-Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.17 $) with ESMTP id LAA01663 for <maillist@candle.pha.pa.us>; Mon, 11 May 1998 11:24:42 -0400 (EDT)
-Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id LAA21841; Mon, 11 May 1998 11:15:25 -0400 (EDT)
-Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 11 May 1998 11:15:12 +0000 (EDT)
-Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id LAA21683 for pgsql-hackers-outgoing; Mon, 11 May 1998 11:15:09 -0400 (EDT)
-Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA21451 for <hackers@postgreSQL.org>; Mon, 11 May 1998 11:15:03 -0400 (EDT)
-Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
-	by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA24915;
-	Mon, 11 May 1998 11:14:43 -0400 (EDT)
-To: Brett McCormick <brett@work.chicken.org>
-cc: hackers@postgreSQL.org
-Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] 
-In-reply-to: Your message of Mon, 11 May 1998 07:57:23 -0700 (PDT) 
-             <13655.4384.345723.466046@abraxas.scene.com> 
-Date: Mon, 11 May 1998 11:14:43 -0400
-Message-ID: <24913.894899683@sss.pgh.pa.us>
-From: Tom Lane <tgl@sss.pgh.pa.us>
-Sender: owner-pgsql-hackers@hub.org
-Precedence: bulk
-Status: RO
-
-Brett McCormick <brett@work.chicken.org> writes:
-> same way that the current network socket is passed -- through an execv
-> argument.  hopefully, however, the non-execv()ing fork will be in 6.4.
-
-Um, you missed the point, Brett.  David was hoping to transfer a client
-connection from the postmaster to an *already existing* backend process.
-Fork, with or without exec, solves the problem for a backend that's
-started after the postmaster has accepted the client socket.
-
-This does lead to a different line of thought, however.  Pre-started
-backends would have access to the "master" connection socket on which
-the postmaster listens for client connections, right?  Suppose that we
-fire the postmaster as postmaster, and demote it to being simply a
-manufacturer of new backend processes as old ones get used up.  Have
-one of the idle backend processes be the one doing the accept() on the
-master socket.  Once it has a client connection, it performs the
-authentication handshake and then starts serving the client (or just
-quits if authentication fails).  Meanwhile the next idle backend process
-has executed accept() on the master socket and is waiting for the next
-client; and shortly the postmaster/factory/whateverwecallitnow notices
-that it needs to start another backend to add to the idle-backend pool.
-
-This'd probably need some interlocking among the backends.  I have no
-idea whether it'd be safe to have all the idle backends trying to
-do accept() on the master socket simultaneously, but it sounds risky.
-Better to use a mutex so that only one gets to do it while the others
-sleep.
-
-			regards, tom lane
-
-
-From owner-pgsql-hackers@hub.org Mon May 11 11:35:55 1998
-Received: from hub.org (hub.org [209.47.148.200])
-	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA03043
-	for <maillist@candle.pha.pa.us>; Mon, 11 May 1998 11:35:53 -0400 (EDT)
-Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id LAA23494; Mon, 11 May 1998 11:27:10 -0400 (EDT)
-Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 11 May 1998 11:27:02 +0000 (EDT)
-Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id LAA23473 for pgsql-hackers-outgoing; Mon, 11 May 1998 11:27:01 -0400 (EDT)
-Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA23462 for <hackers@postgreSQL.org>; Mon, 11 May 1998 11:26:56 -0400 (EDT)
-Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
-	by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA25006;
-	Mon, 11 May 1998 11:26:44 -0400 (EDT)
-To: Brett McCormick <brett@work.chicken.org>
-cc: hackers@postgreSQL.org
-Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] 
-In-reply-to: Your message of Mon, 11 May 1998 07:57:23 -0700 (PDT) 
-             <13655.4384.345723.466046@abraxas.scene.com> 
-Date: Mon, 11 May 1998 11:26:44 -0400
-Message-ID: <25004.894900404@sss.pgh.pa.us>
-From: Tom Lane <tgl@sss.pgh.pa.us>
-Sender: owner-pgsql-hackers@hub.org
-Precedence: bulk
-Status: RO
-
-Meanwhile, *I* missed the point about Brett's second comment :-(
-
-Brett McCormick <brett@work.chicken.org> writes:
-> There will have to be some sort of arg parsing in any case,
-> considering that you can pass configurable arguments to the backend..
-
-If we do the sort of change David and I were just discussing, then the
-pre-spawned backend would become responsible for parsing and dealing
-with the PGOPTIONS portion of the client's connection request message.
-That's just part of shifting the authentication handshake code from
-postmaster to backend, so it shouldn't be too hard.
-
-BUT: the whole point is to be able to initialize the backend before it
-is connected to a client.  How much of the expensive backend startup
-work depends on having the client connection options available?
-Any work that needs to know the options will have to wait until after
-the client connects.  If that means most of the startup work can't
-happen in advance anyway, then we're out of luck; a pre-started backend
-won't save enough time to be worth the effort.  (Unless we are willing
-to eliminate or redefine the troublesome options...)
-
-			regards, tom lane
-
-

doc/TODO.detail/pool

@@ -1319,3 +1319,105 @@ DDI: +64(4)916-7201    MOB: +64(21)635-694    OFFICE: +64(4)499-2267
 ---------------------------(end of broadcast)---------------------------
 TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
 
+From owner-pgsql-hackers@hub.org Mon May 11 11:31:09 1998
+Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
+	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA03006
+	for <maillist@candle.pha.pa.us>; Mon, 11 May 1998 11:31:07 -0400 (EDT)
+Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.17 $) with ESMTP id LAA01663 for <maillist@candle.pha.pa.us>; Mon, 11 May 1998 11:24:42 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id LAA21841; Mon, 11 May 1998 11:15:25 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 11 May 1998 11:15:12 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id LAA21683 for pgsql-hackers-outgoing; Mon, 11 May 1998 11:15:09 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA21451 for <hackers@postgreSQL.org>; Mon, 11 May 1998 11:15:03 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
+	by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA24915;
+	Mon, 11 May 1998 11:14:43 -0400 (EDT)
+To: Brett McCormick <brett@work.chicken.org>
+cc: hackers@postgreSQL.org
+Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] 
+In-reply-to: Your message of Mon, 11 May 1998 07:57:23 -0700 (PDT) 
+             <13655.4384.345723.466046@abraxas.scene.com> 
+Date: Mon, 11 May 1998 11:14:43 -0400
+Message-ID: <24913.894899683@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: RO
+
+Brett McCormick <brett@work.chicken.org> writes:
+> same way that the current network socket is passed -- through an execv
+> argument.  hopefully, however, the non-execv()ing fork will be in 6.4.
+
+Um, you missed the point, Brett.  David was hoping to transfer a client
+connection from the postmaster to an *already existing* backend process.
+Fork, with or without exec, solves the problem for a backend that's
+started after the postmaster has accepted the client socket.
+
+This does lead to a different line of thought, however.  Pre-started
+backends would have access to the "master" connection socket on which
+the postmaster listens for client connections, right?  Suppose that we
+fire the postmaster as postmaster, and demote it to being simply a
+manufacturer of new backend processes as old ones get used up.  Have
+one of the idle backend processes be the one doing the accept() on the
+master socket.  Once it has a client connection, it performs the
+authentication handshake and then starts serving the client (or just
+quits if authentication fails).  Meanwhile the next idle backend process
+has executed accept() on the master socket and is waiting for the next
+client; and shortly the postmaster/factory/whateverwecallitnow notices
+that it needs to start another backend to add to the idle-backend pool.
+
+This'd probably need some interlocking among the backends.  I have no
+idea whether it'd be safe to have all the idle backends trying to
+do accept() on the master socket simultaneously, but it sounds risky.
+Better to use a mutex so that only one gets to do it while the others
+sleep.
+
+			regards, tom lane
+
+
+From owner-pgsql-hackers@hub.org Mon May 11 11:35:55 1998
+Received: from hub.org (hub.org [209.47.148.200])
+	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA03043
+	for <maillist@candle.pha.pa.us>; Mon, 11 May 1998 11:35:53 -0400 (EDT)
+Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id LAA23494; Mon, 11 May 1998 11:27:10 -0400 (EDT)
+Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 11 May 1998 11:27:02 +0000 (EDT)
+Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id LAA23473 for pgsql-hackers-outgoing; Mon, 11 May 1998 11:27:01 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA23462 for <hackers@postgreSQL.org>; Mon, 11 May 1998 11:26:56 -0400 (EDT)
+Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
+	by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA25006;
+	Mon, 11 May 1998 11:26:44 -0400 (EDT)
+To: Brett McCormick <brett@work.chicken.org>
+cc: hackers@postgreSQL.org
+Subject: Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] 
+In-reply-to: Your message of Mon, 11 May 1998 07:57:23 -0700 (PDT) 
+             <13655.4384.345723.466046@abraxas.scene.com> 
+Date: Mon, 11 May 1998 11:26:44 -0400
+Message-ID: <25004.894900404@sss.pgh.pa.us>
+From: Tom Lane <tgl@sss.pgh.pa.us>
+Sender: owner-pgsql-hackers@hub.org
+Precedence: bulk
+Status: RO
+
+Meanwhile, *I* missed the point about Brett's second comment :-(
+
+Brett McCormick <brett@work.chicken.org> writes:
+> There will have to be some sort of arg parsing in any case,
+> considering that you can pass configurable arguments to the backend..
+
+If we do the sort of change David and I were just discussing, then the
+pre-spawned backend would become responsible for parsing and dealing
+with the PGOPTIONS portion of the client's connection request message.
+That's just part of shifting the authentication handshake code from
+postmaster to backend, so it shouldn't be too hard.
+
+BUT: the whole point is to be able to initialize the backend before it
+is connected to a client.  How much of the expensive backend startup
+work depends on having the client connection options available?
+Any work that needs to know the options will have to wait until after
+the client connects.  If that means most of the startup work can't
+happen in advance anyway, then we're out of luck; a pre-started backend
+won't save enough time to be worth the effort.  (Unless we are willing
+to eliminate or redefine the troublesome options...)
+
+			regards, tom lane
+
+