Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Дата | |
| Msg-id | CA+TgmobCZGouJU=z5e2HYDRNYhD24HpwOsS11K3YZUUyoX6Lwg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: [HACKERS] Re: pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
|
| Список | pgsql-committers |
On Thu, Jun 16, 2016 at 12:54 PM, Andres Freund <andres@anarazel.de> wrote: >> The root of my confusion is: if we prune a tuple, we'll bump the page >> LSN, so any session that is still referencing that tuple will error >> out as soon as it touches the page on which that tuple used to exist. > > Right. On the main table. But we don't peform that check on the toast > table/pages. So if we prune toast tuples, which are still referenced by > (unvacuumed) main relation, we can get into trouble. OK, if it's true that we don't perform that check on the TOAST table, then I agree there's a potential problem there. I don't immediately know where in the code to look to check that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: