Re: query slow; strace output worrisome
От | Craig Ringer |
---|---|
Тема | Re: query slow; strace output worrisome |
Дата | |
Msg-id | 4BBAC419.7030605@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: query slow; strace output worrisome (Brian Cox <brian.cox@ca.com>) |
Список | pgsql-performance |
Brian Cox wrote: > On 04/05/2010 09:53 PM, Craig Ringer [craig@postnewspapers.com.au] wrote: >> Anything in `dmesg' (command) or /var/log/syslog ? > nothing out of the ordinary. Brian I'm wondering if the issue is with strace rather than Pg. That is to say, that strace is trying to print: creat("/path/to/file", 0x2, 037777777777) = 1025220608 ... but to get "/path/to/file" it's calling umovestr() which is returning an I/O error, perhaps due to some kind of security framework like AppArmor or SELinux in place on your system. Yep, umovestr() is in util.c:857 in the strace 4.5.18 sources. It looks like it might read from the target's memory via /proc or using ptrace depending on build configuration. Either are obvious targets for security framework limitations. So what you're probably seeing is actually strace being prevented from getting some information out of the postgres backend's memory by system security policy. As for what Pg is doing: creat() returns -1 on error and a file descriptor otherwise, so the return value appears to indicate success. I'm kind of wondering what the Pg backend is actually _doing_ though - if it was using sort temp files you'd expect open()/write()/read()/close() not just creat() calls. -- Craig Ringer
В списке pgsql-performance по дате отправления: