Re: [PROPOSAL] Drop orphan temp tables in single-mode

From: Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
Subject: Re: [PROPOSAL] Drop orphan temp tables in single-mode
Date: 2019-03-07 18:49:33
Message-ID: CAKNkYnz-7EuuQyk33HSvQui64+bhD-H9MrNDvA1d2RDRtfWM7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Thu, Mar 7, 2019 at 10:24 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > So if we think we can invent a "MAGICALLY FIX MY DATABASE" command,
> > let's do that. But please let's not turn a well defined command
> > like VACUUM into something that you don't quite know what it will do.

I see your point. Another approach would be to let user know what prevents
VACUUM to fix the wraparound in single mode, mainly that there are orphan
temp tables . But it might be too verbose if PostgreSQL will print warning for
every orphan temp table.

> Really, I'd like to redesign the way this whole system works. Instead
> of forcing a full-system shutdown, we should just refuse to assign any
> more XIDs, disable the vacuum cost delay machinery, and let autovacuum
> go nuts until the problem is corrected. Forcing people to run vacuum
> to run one vacuum at a time is not nice, and not having background
> processes like the bgwriter or checkpointer while you're doing it
> isn't good either, and there's no good reason to disallow SELECT
> queries while we're recovering the system either. Actually, even
> before we get to the point where we currently force a shutdown, we
> ought to just give up on vacuum cost delay, either all at once or
> perhaps incrementally, when we see that we're getting into trouble.
> But all of that is work for another time.

I think it would be very neat feature!

--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2019-03-07 19:04:30 Re: insensitive collations
Previous Message Robert Haas 2019-03-07 18:36:06 Re: Binary upgrade from <12 to 12 creates toast table for partitioned tables