Re: Repeated PredicateLockRelation calls during seqscan
От
Kevin Grittner
Тема
Re: Repeated PredicateLockRelation calls during
seqscan
Дата
Msg-id
4E022198020000250003EAC0@gw.wicourts.gov
Ответ на
Список
Дерево обсуждения
Repeated PredicateLockRelation calls during seqscan Dan Ports <drkp@csail.mit.edu>
Re: Repeated PredicateLockRelation calls during seqscan Tom Lane <tgl@sss.pgh.pa.us>
Re: Repeated PredicateLockRelation calls during
seqscan "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Repeated PredicateLockRelation calls during seqscan Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: Repeated PredicateLockRelation calls during
seqscan "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: Repeated PredicateLockRelation calls during seqscan Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: Repeated PredicateLockRelation calls during seqscan Dan Ports <drkp@csail.mit.edu>
Re: Repeated PredicateLockRelation calls during
seqscan "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Dan Ports wrote: > Note that this hadn't been a reasonable option until last week > when we added the check for non-MVCC snapshots, since there are > lots of things that use heap scans but SeqScan is the only > (currently-existing) one we want to lock. That is the sort of thing that I tended to notice going through the backtraces from heap access I mentioned in another post, and is most likely the reason the call landed where it did. The MVCC snapshot tests are then a game-changer. It would be nice to find a way not to acquire the relation lock if the node is never used, though. > I am rather uneasy about making changes here unless we can be > absolutely certain they're right... Yeah.... -Kevin
В списке pgsql-hackers по дате отправления