Re: Proposal: Log inability to lock pages during vacuum
От | Jim Nasby |
---|---|
Тема | Re: Proposal: Log inability to lock pages during vacuum |
Дата | |
Msg-id | 54931104.3020507@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Proposal: Log inability to lock pages during vacuum (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Proposal: Log inability to lock pages during vacuum
|
Список | pgsql-hackers |
On 12/18/14, 7:56 AM, Robert Haas wrote: > On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> LOG: automatic vacuum of table "postgres.public.foo": index scans: 0 >> pages: 0 removed, 7256 remain, 0 pinned >> tuples: 79415 removed, 513156 remain, 0 are dead but not yet >> removable >> buffer usage: 14532 hits, 6 misses, 6241 dirtied >> avg read rate: 0.003 MB/s, avg write rate: 3.413 MB/s >> system usage: CPU 0.00s/0.30u sec elapsed 14.28 sec >> >> I.e. this just says how many pages were pinned, without saying what was done >> about them. That's not very meaningful to an average DBA, but that's true >> for many of the numbers printed in vacuum verbose. > > That message is extremely confusing, to my eyes. If you want to say > "pages: 0 removed, 7256 remain, 0 skipped due to pins", that would > work for me, but just say "0 pinned" is totally wrong, because vacuum > pinned every page in the table. We have to decide on a tradeoff here. Either we end up with two different log messages (depending on scan_all) that requiretwo different translations, or we end up with a generic message that isn't as clear. The best option I can think of for the later is something like "failed initial lock attempt". That's the only thing thatwill be true in all cases. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: