Re: [WIP] The relminxid addition, try 3 - Mailing list pgsql-patches
From | Alvaro Herrera |
---|---|
Subject | Re: [WIP] The relminxid addition, try 3 |
Date | |
Msg-id | 20060525231426.GP13700@surnet.cl Whole thread Raw |
In response to | [WIP] The relminxid addition, try 3 (Alvaro Herrera <alvherre@commandprompt.com>) |
Responses |
Re: [WIP] The relminxid addition, try 3
|
List | pgsql-patches |
Alvaro Herrera wrote: Hi, > Here is a reworked relminxid patch. I added XLOG operations for heap > unfreeze and database unfreeze. The latter happens when someone > connects to a frozen database. The former happens when a LockRelation() > is called on a frozen relation, and the lock is stronger than > AccessShare. I've been further reworking this patch. It is basically as discussed: tables are unfrozen when LockRelation() is called, databases are unfrozen when they are connected to. Those operations are performed using heap_inplace_update, so we no longer need to take particular steps to XLog them. There are two new columns in pg_class (relminxid and relvacuumxid). Both of them can be set to FrozenTransactionId. The minimum of each is used to determine database-wide datminxid and datvacuumxid. Those can also be to FrozenXid. (Note that it seems to be problematic that all databases have FrozenXids; however, this can only happen in a standalone backend, when you VACUUM FREEZE a database and all other databases are already frozen. So we can truncate to CurrentTransactionId without problem.) However there's a big problem once again but I don't know how to fix it. I don't know why this didn't show up before. Consider the following scenario: - pg_attribute is frozen - pg_class is frozen CREATE TABLE foo (a int); for some unknown reason, an inval message involving relation foo seems to be emitted. heap_unfreeze(pg_class) CommandCounterIncrement() heap_unfreeze(pg_attribute) CommandCounterIncrement() ... insert the pg_attribute rows ... During one of those CommandCounterIncrement calls, the "foo" relation receives an invalidation message and the system tries to rebuild the RelationDesc. But at this point the pg_attribute rows are not there yet, so the rebuild fails because it can't find them: $ runpg 10relminxid client Bienvenido a psql 8.2devel, la terminal interactiva de PostgreSQL. Digite: \copyright para ver los términos de distribución \h para ayuda de comandos SQL \? para ayuda de comandos psql \g o or termine con punto y coma para ejecutar una consulta \q para salir alvherre=# vacuum freeze ; alvherre=# \q $ runpg 10relminxid client Bienvenido a psql 8.2devel, la terminal interactiva de PostgreSQL. Digite: \copyright para ver los términos de distribución \h para ayuda de comandos SQL \? para ayuda de comandos psql \g o or termine con punto y coma para ejecutar una consulta \q para salir alvherre=# create table hmmmm (a int); NOTICE: unfreezing pg_type NOTICE: unfreezing pg_depend NOTICE: unfreezing pg_shdepend NOTICE: unfreezing pg_attribute ERROR: catalog is missing 1 attribute(s) for relid 16409 Strangely this doesn't happen if I create the table right away at the same connection that did the VACUUM FREEZE. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Attachment
pgsql-patches by date: