Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
| От | Kevin Grittner |
|---|---|
| Тема | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Дата | |
| Msg-id | CACjxUsOkMWZYFchAfjD1R4J40X5RYJ-YLo8xLPVmcHkBLSGspg@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 1:01 PM, Andres Freund <andres@anarazel.de> wrote:
> The relevant part is the HeapTupleSatisfiesMVCC check, we're using
> SatisfiesToast for toast lookups.
>
> FWIW, I just tried to reproduce this with old_snapshot_threshold = 0 -
> but ran into the problem that I couldn't get it to vacuum anything away
> (neither main nor toast rel). That appears to be
> if (old_snapshot_threshold == 0)
> {
> if (TransactionIdPrecedes(latest_xmin, MyPgXact->xmin)
> && TransactionIdFollows(latest_xmin, xlimit))
> xlimit = latest_xmin;
> because latest_xmin always is equal to MyPgXact->xmin, which is actually
> kinda unsurprising?
Sure -- the STO feature *never* advances the point for early
pruning past the earliest still-active transaction ID. If it did
we would have all sorts of weird problems.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: