Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Yeah, that seems like the best answer.
>
> > Seems like this patch fixes it.
>
> Um, not for tables that don't have toast tables ...
Right, this seems better.
Note that it needs to open the toast table and grab AccessShare to get
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Yeah, that seems like the best answer.
> Seems like this patch fixes it.
Um, not for tables that don't have toast tables ...
> How far back should be backpatched?
Not at all; it's not a bug fix.
regards, tom lane
--
Sent v
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I wonder if we can get away with simply renaming the new toast table and
> > index after the data has been copied.
>
> Yeah, that seems like the best answer.
Seems like this patch fixes it.
How far back should be backpatched? Giv
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> My first attempt at a fix, which was simply swapping relfilenode for the
> TOAST tables (and its indexes) after the data has been copied, does not
> work, apparently because the TOAST pointers have the toast table ID
> embedded.
Ouch. Right.
> I wonde
Tom Lane wrote:
> I wrote:
> > Hmm, we could probably fix that if we made the cluster operation swap
> > the physical storage of the two toast tables, rather than swapping the
> > tables altogether. I agree it's not critical but it could be confusing.
>
> On second thought, I think it *could* lea
Tom Lane wrote:
> On second thought, I think it *could* lead to a visible failure.
> Suppose the OID counter wraps around and the OID that had been used for
> the temporary CLUSTER table gets assigned to a new table. If that table
> needs a toast table, it'll try to create one using the name that
I wrote:
> Hmm, we could probably fix that if we made the cluster operation swap
> the physical storage of the two toast tables, rather than swapping the
> tables altogether. I agree it's not critical but it could be confusing.
On second thought, I think it *could* lead to a visible failure.
Supp
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> BTW only now I notice that CLUSTER leaves the toast table name in bad
> shape: if you create a table with OID X its TOAST table is named
> pg_toast_X. If you then cluster this table, a new transient table gets
> created with OID Y; the TOAST table for Y
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Note that this patch allows a toast table to be vacuumed by the user:
> > I don't have a problem with that, but if anyone thinks this is not a
> > good idea, please speak up.
>
> The permissions on pg_toast will prevent anyone but a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Note that this patch allows a toast table to be vacuumed by the user:
> I don't have a problem with that, but if anyone thinks this is not a
> good idea, please speak up.
The permissions on pg_toast will prevent anyone but a superuser from
doing that an
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > There's two things I'm not happy about in this patch:
>
> > 1. it uses a List to keep the mapping of heap<->toast Oids. This is
> > needed to be able to fetch the main rel's pg_autovacuum entry to process
> > the toast table. This
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> There's two things I'm not happy about in this patch:
> 1. it uses a List to keep the mapping of heap<->toast Oids. This is
> needed to be able to fetch the main rel's pg_autovacuum entry to process
> the toast table. This incurs in O(n^2) behavior.
Hi,
Here's a patch to make autovacuum process TOAST tables separately from
main tables.
The most important change is that when called from autovac, vacuum does
not process the TOAST table at all. It will only do so when the stats
for the TOAST table say that it needs vacuuming. (A user-invoked
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think there is some special code in tqual.c that skips some checks
> assuming that the toast table is vacuumed at the same time as the main
> heap.
I don't believe there is any such connection. We do use a special
snapshot for toast tables, but it's
Gregory Stark wrote:
> When autovacuum vacuums a table it always vacuums the toast table as well. Is
> there any particular reason to consider the two together? I think this may
> just be a holdover from the interactive command which considers them together
> because the toast table is supposed to
When autovacuum vacuums a table it always vacuums the toast table as well. Is
there any particular reason to consider the two together? I think this may
just be a holdover from the interactive command which considers them together
because the toast table is supposed to be invisible to users.
But
16 matches
Mail list logo
