From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is VACUUM still crash-safe? |
Date: | 2000-12-12 04:13:57 |
Message-ID: | 3A35A605.DE7A8BD6@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > VACUUM of a toast table crashed immediately after the movement
> > of a tuple(and before inserting corresponding index tuples).
> > Unfortunately the movement of a tuple is directly committed in
> > already committed state but corresponding index tuples aren't
> > inserted.
>
> Ah, *now* I see what you're talking about. You're right, the TOAST
> table has to be vacuumed under a separate transaction number.
>
> I still don't like releasing the lock on the master table though.
> VACUUM cheats on the commit already, could it start a new transaction
> number without releasing the lock?
>
It is also preferable that we could replace current intermediate
*commit*
of vacuum by real commit(without releaseing the lock).
IIRC,Vadim and I talked about it a little once before.
We could avoid releasing the lock at commit time but probably
the next StartTransaction() has to change xid-s of LockTable
entries. I'm not sure if it's sufficient or not. For example
We could hardly keep row-level lock. We could acquire the lock
on a row which is already committed.
Regards.
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-12-12 04:18:41 | Re: (one more time) Patches with vacuum fixes available . |
Previous Message | Tom Lane | 2000-12-12 04:13:10 | Re: SourceForge & Postgres |