| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, michael(at)paquier(dot)xyz, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Autovacuum vs vac_update_datfrozenxid() vs ? |
| Date: | 2020-04-02 05:03:31 |
| Message-ID: | 20200402050331.GA3379102@rfd.leadboat.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 23, 2020 at 04:50:36PM -0700, Andres Freund wrote:
> I think there's also another (even larger?) race in
> vac_update_datfrozenxid(): Unless I miss something, two backends can
> concurrently run through the scan in vac_update_datfrozenxid() for two
> different tables in the same database, both can check that they need to
> update the pg_database row, and then one of them can overwrite the
> results of the other. And the one that updates last might actually be
> the one with an older horizon. This is possible since there is no 'per
> database' locking in heap_vacuum_rel().
Right. This thread has a fix:
https://www.postgresql.org/message-id/flat/20190218073103.GA1434723%40rfd.leadboat.com
The CF entry blocking it is starting to see some activity. (Your discovery
involving lastSaneFrozenXid would need a separate fix.)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-04-02 05:19:15 | Re: [BUG] non archived WAL removed during production crash recovery |
| Previous Message | Andrey Lepikhov | 2020-04-02 04:50:58 | Re: NOT IN subquery optimization |