Temporary table has become problematically persistent

2020-05-04 Thread Ricky Ramirez
Hello,

We have run into a strange situation with our database. A temporary table
was created some time ago and that session has since died. However, the
temporary table stuck around. It's been around long enough that postgres
stopped accepting writes to prevent transaction ID wraparound. Problem is,
it's a temporary table and the session that it's associated with is gone,
so we cannot vacuum it nor even drop the table. We even restarted postgres
and the temporary table was still there!

The table shows up in pg_class as a temporary table with zero tuples. The
table replicated over to other hosts. We were able to promote a replica and
then single user mode the replica and drop the offending table. I still
have the original broken database available for debugging. Can I provide
any additional debugging information?

Thanks,

Ricky


Re: Temporary table has become problematically persistent

2020-05-04 Thread Ricky Ramirez
Forgive me for forgetting the basics PG 11.2 on Ubuntu Bionic, amd64. No
extensions enabled.

On Mon, May 4, 2020 at 4:54 PM Tom Lane  wrote:

> Ricky Ramirez  writes:
> > We have run into a strange situation with our database. A temporary table
> > was created some time ago and that session has since died. However, the
> > temporary table stuck around. It's been around long enough that postgres
> > stopped accepting writes to prevent transaction ID wraparound. Problem
> is,
> > it's a temporary table and the session that it's associated with is gone,
> > so we cannot vacuum it nor even drop the table. We even restarted
> postgres
> > and the temporary table was still there!
>
> Hm, what PG version is this?  I thought we'd fixed that hazard quite some
> while back.
>
> regards, tom lane
>


Re: Temporary table has become problematically persistent

2020-05-05 Thread Ricky Ramirez
We couldn't drop the table in the normal setup because of the wraparound
protection measures. Specifically: "ERROR:  database is not accepting
commands to avoid wraparound data loss in database"

We also tried vacuuming the table. The vacuum didn't generate an error (the
wraparound warning was printed), but nothing appeared to change from that.
Vacuuming the full database would have taken prohibitively long so we never
completed that operation.

On Mon, May 4, 2020 at 6:17 PM Jerry Sievers  wrote:

> Ricky Ramirez  writes:
>
> > Hello,
> >
> > We have run into a strange situation with our database. A temporary
> > table was created some time ago and that session has since died.
> > However, the temporary table stuck around. It's been around long
> > enough that postgres stopped accepting writes to prevent
> > transaction ID wraparound. Problem is, it's a temporary table and the
> > session that it's associated with is gone, so we cannot vacuum it nor
> > even drop the table. We even restarted postgres and the temporary
> > table was still there!
>
> What happened when you tried to drop the temp table?
>
> >
> > The table shows up in pg_class as a temporary table with zero tuples.
> > The table replicated over to other hosts. We were able to promote a
> > replica and then single user mode the replica and drop the offending
> > table. I still have the original broken database available for
> > debugging. Can I provide any additional debugging information?
> >
> > Thanks,
> >
> > Ricky
> >
> >
>
> --
> Jerry Sievers
> Postgres DBA/Development Consulting
> e: postgres.consult...@comcast.net
>