Hot Standby and VACUUM FULL
in [PgSql]
|
Prev: Add on_perl_init and proper destruction to plperl UPDATE v3[PATCH]
Next: [HACKERS] Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]
From: Tom Lane on 3 Feb 2010 11:50 I wrote: > * We can not change the toast rel OID of a shared catalog -- there's no > way to propagate that into the other copies of pg_class. So we need to > rejigger the logic for heap rewriting a little bit. Toast rel swapping > has to be handled by swapping their relfilenodes not their OIDs. This > is no big deal as far as cluster.c itself is concerned, but the tricky > part is that when we write new toasted values into the new toast rel, > the TOAST pointers going into the new heap have to be written with the > original toast-table OID value not the one that the transient target > toast rel has got. This is doable but it would uglify the TOAST API a > bit I think. I've been playing around with different alternatives for solving the problem of toast-pointer OIDs, but I keep coming back to the above as being the least invasive and most robust answer. There are two basic ways that we could do it: pass the OID to use to the toast logic, which would require adding a parameter to heap_insert and a number of other places; or add a field to struct Relation that says "when inserting a TOAST pointer in this relation, use this OID as the toast-table OID value in the pointer, even if that's different from what the table's OID appears to be". The latter seems like less of a notational change, so I'm leaning to that, but wanted to see if anyone prefers the other. We could avoid this hackery if there were a way for Relation structs to point at either the old or the new physical relation (relfilenode); then we'd not need the transient "new heap" relation during CLUSTER/VF, which would be good for reducing catalog churn. I've concluded that that's too large a change to undertake for 9.0, but it might be interesting to try in the future. So I'd prefer that what we do for now touch as little code as possible so as to be easy to revert; hence I'm not wanting to change heap_insert's signature. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 3 Feb 2010 12:05 Tom Lane wrote: > I've been playing around with different alternatives for solving the > problem of toast-pointer OIDs, but I keep coming back to the above as > being the least invasive and most robust answer. There are two basic > ways that we could do it: pass the OID to use to the toast logic, which > would require adding a parameter to heap_insert and a number of other > places; or add a field to struct Relation that says "when inserting a > TOAST pointer in this relation, use this OID as the toast-table OID > value in the pointer, even if that's different from what the table's OID > appears to be". The latter seems like less of a notational change, so > I'm leaning to that, but wanted to see if anyone prefers the other. > > We could avoid this hackery if there were a way for Relation structs to > point at either the old or the new physical relation (relfilenode); > then we'd not need the transient "new heap" relation during CLUSTER/VF, > which would be good for reducing catalog churn. I've concluded that > that's too large a change to undertake for 9.0, but it might be > interesting to try in the future. So I'd prefer that what we do for > now touch as little code as possible so as to be easy to revert; hence > I'm not wanting to change heap_insert's signature. I don't think any of this affects pg_migrator, but if it does, please let me know. When I hear TOAST and OID used in the same sentence, my ears perk up. :-) -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 3 Feb 2010 12:10
On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote: > I've concluded that that's too large a change to undertake for 9.0 The purpose of this was to make the big changes in 9.0. If we aren't going to do that it seems like we shouldn't bother at all. So why not flip back to the easier approach of make something work for HS only and then do everything you want to do in the next release? The burst radius of the half-way changes you are proposing seems high in comparison. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |