The corresponding relminxid patch; try 1
От | Alvaro Herrera |
---|---|
Тема | The corresponding relminxid patch; try 1 |
Дата | |
Msg-id | 20060611222022.GB15211@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Non-transactional pg_class, try 2 (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: The corresponding relminxid patch; try 1
|
Список | pgsql-patches |
Hi, This is the relminxid patch corresponding to the pg_ntclass patch I just posted. Obviously, the relminxid and relvacuumxid fields are in pg_ntclass (not pg_class like in the previous incarnations of this patch). This makes the whole business much saner and now I don't need to insert bogus CommandCounterIncrement calls. Regression tests pass. The thing that bothers me most about this is that it turns LockRelation into an operation that needs to heap_fetch() from pg_ntclass in some cases, and possibly update it. I think we should consider some sort of "non-transactional shared cache" for storing RELKIND_NON_TRANSACTIONAL catalog entries. Eventually it may help the sequences stuff as well, if we implement sequences using that kind of catalog. The documentation changes may be a bit off in this patch, since I didn't worry about merging it with the pg_ntclass patch. But it's easy to correct and I'll do it before committing it. My intention is to wait two or three days after committing the pg_ntclass patch, and then commit this one, unless I hear objections before that.
Вложения
В списке pgsql-patches по дате отправления: