From: | JanWieck(at)t-online(dot)de (Jan Wieck) |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alfred Perlstein <bright(at)wintelcom(dot)net>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vaccuum allows read access? |
Date: | 2000-07-22 11:20:32 |
Message-ID: | 200007221120.NAA08555@hot.jw.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > In the current sources, analyze allows read-access. I don't think
> > vacuum allows any other access because the rows are moving in the file.
>
> VACUUM *must* have exclusive lock.
>
> ANALYZE actually is only a reader (AccessShareLock) and does not lock
> out either reading or writing in current sources.
Some related issue though.
On the phone we discussed about the btree splitpage problems
and you said that the current btree implementation is
optimized for concurrent read and insert access, not so for
concurrent deletes.
This might get to be a problem with the overwriting storage
manager. If it wants to reuse space of outdated tuples in
the main heap, it needs to delete index tuples as well. Isn't
that in conflict with the btree design?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-07-22 12:50:45 | Re: Hello PL/Python |
Previous Message | Jan Wieck | 2000-07-22 09:28:25 | Re: TOAST & vacuum |