From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: shared memory stats: high level design decisions: consistency, dropping |
Date: | 2021-03-20 00:21:52 |
Message-ID: | 20210320002152.tkktwqp6aq7oq5y3@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-03-20 01:16:31 +0100, Hannu Krosing wrote:
> > But now we could instead schedule stats to be removed at commit
> time. That's not trivial of course, as we'd need to handle cases where
> the commit fails after the commit record, but before processing the
> dropped stats.
>
> We likely can not remove them at commit time, but only after the
> oldest open snapshot moves parts that commit ?
I don't see why? A dropped table is dropped, and cannot be accessed
anymore. Snapshots don't play a role here - the underlying data is gone
(minus a placeholder file to avoid reusing the oid, until the next
commit). If you run a vacuum on some unrelated table in the same
database, the stats for a dropped table will already be removed long
before there's no relation that could theoretically open the table.
Note that table level locking would prevent a table from being dropped
if a long-running transaction has already accessed it.
> Would an approach where we keep stats in a structure logically similar
> to MVCC we use for normal tables be completely unfeasible ?
Yes, pretty unfeasible. Stats should work on standbys too...
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-20 00:25:43 | Re: [HACKERS] Custom compression methods |
Previous Message | David Steele | 2021-03-20 00:16:59 | Re: [HACKERS] Custom compression methods |