From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Robert Haas' <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Temporary tables prevent autovacuum, leading to XID wraparound |
Date: | 2018-01-26 05:33:51 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F8A69E3@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
> I think we should consider having backends try to remove their temporary
> schema on startup; then, if a temp table in a backend is old enough that
> it's due for vacuum for wraparound, have autovacuum kill the connection.
> The former is necessary to prevent sessions from being killed on account
> of temp tables they "inherited" from a backend that didn't exit cleanly.
That seems to be the only reasonable solution. One might feel it annoying to emit WAL during connection establishment to delete the temp schema, but even now the client authentication can emit WAL for hot pruning while scanning pg_database, pg_authid, etc. Thanks.
> The in-place update idea won't work for a couple of reasons. First, a
> command shouldn't see the results of modifications made earlier in the same
> command. Second, using cursors, it's possible to have more than one
> distinct snapshot open against a temporary table at the same time.
You're right. And if the transaction rolls back, it needs to see the old tuples, which requires undo log.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-26 05:43:47 | Re: Redefining inet_net_ntop |
Previous Message | Tsunakawa, Takayuki | 2018-01-26 05:22:29 | RE: Temporary tables prevent autovacuum, leading to XID wraparound |