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
themcan 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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +