Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Perhaps what we could do is take the relfrozenxid from the old relation
> and copy it over, if it's later than FreezeXid?
It certainly doesn't seem to make any sense to allow the rel's
relfrozenxid to go backwards. Indeed this coding lets it end up les
Tom Lane wrote:
> regression=# cluster foo_pkey on foo;
> CLUSTER
> regression=# select relname, relkind, relfrozenxid from pg_class order by oid
> desc limit 6;
> relname| relkind | relfrozenxid
> ---+-+--
> pg_toast_707231_index | i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm ... that would be strange. Off-the-cuff idea: we introduced code to
> advance relfrozenxid in CLUSTER, TRUNCATE and table-rewriting forms of
> ALTER TABLE. Perhaps the problem is that we're neglecting to update it
> for the toast table there. AFAIR
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>> Hmm ... that would be strange. Off-the-cuff idea: we introduced code to
>> advance relfrozenxid in CLUSTER, TRUNCATE and table-rewriting forms of
>> ALTER TABLE. Perhaps the problem is that we're neglecting to update it
>> for the toast table the
Alvaro Herrera wrote:
Tom Lane wrote:
Andrew - Supernews <[EMAIL PROTECTED]> writes:
On 2008-01-07, Tom Lane <[EMAIL PROTECTED]> wrote:
The real question that Josh's report brings up to me is why the heck was
there an orphaned temp table? Especially if it was only a toast table
and not the li
Tom Lane wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
> > On 2008-01-07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> The real question that Josh's report brings up to me is why the heck was
> >> there an orphaned temp table? Especially if it was only a toast table
> >> and not the linked "
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2008-01-07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The real question that Josh's report brings up to me is why the heck was
>> there an orphaned temp table? Especially if it was only a toast table
>> and not the linked "regular" temp table? Some
On 2008-01-07, Tom Lane <[EMAIL PROTECTED]> wrote:
> The real question that Josh's report brings up to me is why the heck was
> there an orphaned temp table? Especially if it was only a toast table
> and not the linked "regular" temp table? Something happened there that
> should not have.
The re
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> After a fresh start of postgres, there should be no temp tables, so would a
> work around to this at least be at postmaster start to (for a lack of a
> better pseudo code ) DROP SCHEMA pg_temp* CASCADE; before coming up in
> interactive mode?
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 10:37:18 -0800
Darcy Buskermolen <[EMAIL PROTECTED]> wrote:
> > 1. I had to manually vacuum because we had already hid xidStoplimit.
> >
> > 2. Postgres has been restarted multiple times and it made zero
> > difference.
> >
> > E.g;
On Monday 07 January 2008 09:10:24 Joshua D. Drake wrote:
> On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
>
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > > Ah -- interesting. This is a known issue, but we haven't found a
> > > > solution yet.
> > >
> > > Is there bug number?
> >
> > I assume it is th
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
>> On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
>> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>>
>>> I assume it is this TODO item:
>>>
>>> o Prevent long-lived temporary tables from causing frozen-xid
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>> I assume it is this TODO item:
>>
>> o Prevent long-lived temporary tables from causing frozen-xid
>> advancement starvation
>>
>> T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 11:58:29 -0500 (EST)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > Ah -- interesting. This is a known issue, but we haven't found a
> > > solution yet.
> > >
> >
> > Is there bug number?
>
> I assume it is this TODO item:
>
>
Joshua D. Drake wrote:
> > >> SELECT oid::regclass FROM pg_class WHERE
> > >> reltoastrelid='pg_toast.pg_toast_49013869'::regclass;
> > >>
> > >> oid | pg_temp_24.tmp_isp_blk_chk
> > >>
> > >> The hack to get this cleaned up was to connect about 2 dozen times
> > >> (to get to slot 24) with psql vi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 7 Jan 2008 09:18:24 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> >> SELECT oid::regclass FROM pg_class WHERE
> >> reltoastrelid='pg_toast.pg_toast_49013869'::regclass;
> >>
> >> oid | pg_temp_24.tmp_isp_blk_chk
Joshua D. Drake wrote:
>> SELECT oid::regclass FROM pg_class WHERE
>> reltoastrelid='pg_toast.pg_toast_49013869'::regclass;
>>
>> oid | pg_temp_24.tmp_isp_blk_chk
>>
>> The hack to get this cleaned up was to connect about 2 dozen times (to
>> get to slot 24) with psql via different sessions and cr
Joshua D. Drake wrote:
Ping?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I spent the better part of this evening tracking down a problem with a
high velocity database. The database had entered the point of no return
by invoking xidStopLimit.
This by itself isn't a problem because yo
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I spent the better part of this evening tracking down a problem with a
high velocity database. The database had entered the point of no return
by invoking xidStopLimit.
8.2.4
Joshua D. Drake
19 matches
Mail list logo
