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 I
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:
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 less
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 create temp
-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
The hack
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
-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:
o Prevent
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
The problem is that
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
advancement
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 this TODO item:
-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; PostgreSQL
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
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 regular
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? Something
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 regular temp
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
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 there.
-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 you just vacuum right? Well we
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
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
20 matches
Mail list logo
