On Sun, Mar 27, 2011 at 9:41 PM, Jan Wieck <janwi...@yahoo.com> wrote: > On 3/27/2011 6:21 PM, Robert Haas wrote: >> >> On Sun, Mar 27, 2011 at 3:25 PM, Jan Wieck<janwi...@yahoo.com> wrote: >>> >>> Since we are talking about stable releases, I think just releasing and >>> reacquiring the exclusive lock is enough. We can then try to further >>> improve >>> things for future releases. >> >> That seems unsafe - things can change under you while you don't hold the >> lock... > > The only change relevant in this case would be some concurrent client > extending the relation while we don't hold the lock. A call to > RelationGetNumberOfBlocks() after reacquiring the lock will tell. Safety > reestablished.
I thought that the risk was that someone might write tuples into the blocks that we're thinking of truncating. >> I kind of like the idea of committing the transaction and then >> beginning a new one just to do the truncation. Given the way the >> deadlock detector treats autovacuum, the current coding seems quite >> risky. > > I don't like a 1,000 ms hiccup in my system, regardless of how many > transaction hoops you make it go through. I can't argue with that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
