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 tables. Once we hit slot 24, the probably instantly went away
> > >> and the database returned to normal state.
> >
> > 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 long-lived temporary tables from causing frozen-xid
advancement starvation
The problem is that autovacuum cannot vacuum them to set frozen xids;
only the session that created them can do that.
http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php
but am confused how the fix worked. Have all of these backends been
active for 1 billion transactions?
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
