Re: Plans for solving the VACUUM problem
От | Bruce Momjian |
---|---|
Тема | Re: Plans for solving the VACUUM problem |
Дата | |
Msg-id | 200105191212.f4JCCSc15349@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Plans for solving the VACUUM problem (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
> > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Hey, I have an idea. Can we do subtransactions as separate transactions > > > (as Tom mentioned), and put the subtransaction id's in the WAL, so they > > > an be safely committed/rolledback as a group? > > > > It's not quite that easy: all the subtransactions have to commit at > > *the same time* from the point of view of other xacts, or you have > > consistency problems. So there'd need to be more xact-commit mechanism > > than there is now. Snapshots are also interesting; we couldn't use a > > single xact ID per backend to show the open-transaction state. > > Yes, I knew that was going to come up that you have to add a lock to the > pg_log that is only in affect when someone is commiting a transaction > with subtransactions. Normal transactions get read/sharedlock, while > subtransaction needs exclusive/writelock. I was wrong here. Multiple backends can write to pg_log at the same time, even subtraction ones. It is just that no backend can read from pg_log during a subtransaction commit. Acctually, they can if the are reading a transaction status that is less than the minium active transaction id, see GetXmaxRecent(). Doesn't seem too bad. -- 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, Pennsylvania19026
В списке pgsql-hackers по дате отправления: