Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby and VACUUM FULL

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby and VACUUM FULL
Date: 2010-02-03 17:05:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-03 17:07:09
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Robert HaasDate: 2010-02-03 17:04:06
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group