diff --git a/doc/TODO b/doc/TODO index 91a8f554b9..bf54323515 100644 --- a/doc/TODO +++ b/doc/TODO @@ -136,6 +136,7 @@ CLIENTS * Update reltuples from COPY command * fix array handling for ECPG * add pg_dump option to dump type names as standard ANSI types +* make pg_dump dump in oid order, so dependencies are resolved * allow psql \d to show primary and foreign keys * allow psql \d to show temporary table schema diff --git a/doc/TODO.detail/lock b/doc/TODO.detail/lock new file mode 100644 index 0000000000..2346680622 --- /dev/null +++ b/doc/TODO.detail/lock @@ -0,0 +1,147 @@ +From owner-pgsql-hackers@hub.org Sat Dec 18 17:22:09 1999 +Received: from hub.org (hub.org [216.126.84.1]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA10300 + for ; Sat, 18 Dec 1999 18:21:57 -0500 (EST) +Received: from localhost (majordom@localhost) + by hub.org (8.9.3/8.9.3) with SMTP id SAA74681; + Sat, 18 Dec 1999 18:17:56 -0500 (EST) + (envelope-from owner-pgsql-hackers) +Received: by hub.org (bulk_mailer v1.5); Sat, 18 Dec 1999 18:17:33 -0500 +Received: (from majordom@localhost) + by hub.org (8.9.3/8.9.3) id SAA74549 + for pgsql-hackers-outgoing; Sat, 18 Dec 1999 18:16:38 -0500 (EST) + (envelope-from owner-pgsql-hackers@postgreSQL.org) +Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72]) + by hub.org (8.9.3/8.9.3) with ESMTP id SAA74401 + for ; Sat, 18 Dec 1999 18:15:20 -0500 (EST) + (envelope-from brook@biology.nmsu.edu) +Received: (from brook@localhost) + by biology.nmsu.edu (8.8.8/8.8.8) id QAA03433; + Sat, 18 Dec 1999 16:14:50 -0700 (MST) +Date: Sat, 18 Dec 1999 16:14:50 -0700 (MST) +Message-Id: <199912182314.QAA03433@biology.nmsu.edu> +X-Authentication-Warning: biology.nmsu.edu: brook set sender to brook@biology.nmsu.edu using -f +From: Brook Milligan +To: pgman@candle.pha.pa.us +CC: peter_e@gmx.net, pgsql-hackers@postgreSQL.org +In-reply-to: <199912182026.PAA05926@candle.pha.pa.us> (message from Bruce + Momjian on Sat, 18 Dec 1999 15:26:15 -0500 (EST)) +Subject: Re: [HACKERS] Re: [PATCHES] Lock +References: <199912182026.PAA05926@candle.pha.pa.us> +Sender: owner-pgsql-hackers@postgreSQL.org +Status: OR + + > > * Allow LOCK TABLE tab1, tab2, tab3 so all tables locked in unison + + Let me add to this. One problem is that my description would sometimes + lock the tables in different orders, and that is a recipe for deadlock. + + If you have to release earlier locks to wait on a later lock, once you + get the later lock, you must release it and then start from the + beginning, locking them in order again. If you don't, the system could + report a deadlock at random times, which would be very bad. + +I'll add something, too. :) I think this derived from a suggestion I +made long ago. My idea was that when multiple tables need locking, a +deadlock can occur in the process of doing them one at a time. My +suggested solution was based on an analogy with the way ethernet +packets work. + +- go through the list locking tables along the way. + +- if a lock cannot be obtained within some time, release some (all?) locks, + and try again after some random time. + +- keep trying (and releasing as needed) until some other timeout + passes, and then punt. + +My thought was that if colliding locks are occuring, some sequence of +relinquishing locks (not necessarily all of them with each trial), +waiting, and reasserting them should work around the collisions. +Introducing random components to this might reduce the overall waiting +time, but I suppose a careful analysis of this needs to be done. +Perhaps just releasing all of the locks, waiting a random time, and +trying again is enough. + +Somehow there has to be a mechanism for atomically asserting locks on +more than one table. + +Cheers, +Brook + +************ + +From owner-pgsql-patches@hub.org Sat Dec 18 22:51:06 1999 +Received: from renoir.op.net (root@renoir.op.net [207.29.195.4]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id XAA18409 + for ; Sat, 18 Dec 1999 23:51:05 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id XAA27570 for ; Sat, 18 Dec 1999 23:49:19 -0500 (EST) +Received: from hub.org (hub.org [216.126.84.1]) + by hub.org (8.9.3/8.9.3) with ESMTP id XAA52323; + Sat, 18 Dec 1999 23:45:32 -0500 (EST) + (envelope-from owner-pgsql-patches@hub.org) +Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sat, 18 Dec 1999 23:44:37 +0000 (EST) +Received: (from majordom@localhost) + by hub.org (8.9.3/8.9.3) id XAA52107 + for pgsql-patches-outgoing; Sat, 18 Dec 1999 23:43:37 -0500 (EST) + (envelope-from owner-pgsql-patches@postgreSQL.org) +Received: from fw.wintelcom.net (bright@ns1.wintelcom.net [209.1.153.20]) + by hub.org (8.9.3/8.9.3) with ESMTP id XAA52012 + for ; Sat, 18 Dec 1999 23:42:44 -0500 (EST) + (envelope-from bright@wintelcom.net) +Received: from localhost (bright@localhost) + by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id VAA19594; + Sat, 18 Dec 1999 21:12:09 -0800 (PST) +Date: Sat, 18 Dec 1999 21:12:09 -0800 (PST) +From: Alfred Perlstein +To: Bruce Momjian +cc: Peter Eisentraut , patches@postgreSQL.org +Subject: Re: [PATCHES] Lock +In-Reply-To: <199912181828.NAA01486@candle.pha.pa.us> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +Sender: owner-pgsql-patches@postgreSQL.org +Precedence: bulk +Status: OR + +On Sat, 18 Dec 1999, Bruce Momjian wrote: + +> [Charset ISO-8859-1 unsupported, filtering to ASCII...] +> > I was looking at this +> > +> > * Allow LOCK TABLE tab1, tab2, tab3 so all tables locked in unison +> > +> > but I'm not sure if my solution is really what was wanted, because it +> > doesn't actually guarantee an all-or-nothing lock, it just locks each +> > table in order. Thus it's more like a syntax simplification and reduces +> > overhead. +> > +> +> It took a few minutes, but I remember the use for this. If you are +> going to hang waiting to lock tab3, you don't want to lock tab1 and tab2 +> while you are waiting for tab3 lock. The user wanted all tables to lock +> in one operation without holding locks while waiting to complete all +> locking. +> +> Can you do the locks, and if one fails, not hang, but unlock the +> previous tables, go lock/hang on the failure, and go back and lock the +> others? Seems it would have to be some kind of lock/fail/unlock/wait +> loop. +> +> Does this make sense? It did to me. + +Guys, have a look at: + +http://www.freebsd.org/~terry/iml.txt +http://jazz.external.hp.com/training/sqltables/c5s17.html + +It's a way to do locking with deadlock detection, and without loosing +your place in line for locks, very nifty imo. + +-Alfred + + +************ + + diff --git a/doc/src/FAQ.html b/doc/src/FAQ.html index bbee79245f..c29d4c0dff 100644 --- a/doc/src/FAQ.html +++ b/doc/src/FAQ.html @@ -7,7 +7,7 @@ Frequently Asked Questions (FAQ) for PostgreSQL

-Last updated: Tue Mar 21 16:09:11 EST 2000 +Last updated: Thu Jun 1 13:57:15 EDT 2000

Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)