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 по дате отправления: