From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | The corresponding relminxid patch; try 1 |
Date: | 2006-06-11 22:20:22 |
Message-ID: | 20060611222022.GB15211@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers 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.
Attachment | Content-Type | Size |
---|---|---|
relminxid-ntclass-1.patch | text/plain | 93.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Zoltan Boszormenyi | 2006-06-11 22:38:50 | Extended SERIAL parsing |
Previous Message | Alvaro Herrera | 2006-06-11 21:58:03 | Re: Non-transactional pg_class, try 2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-12 00:03:22 | Re: Non-transactional pg_class, try 2 |
Previous Message | Alvaro Herrera | 2006-06-11 21:58:03 | Re: Non-transactional pg_class, try 2 |