Brian Cox wrote:
> On 04/05/2010 09:53 PM, Craig Ringer [craig@xxxxxxxxxxxxxxxxxxxxx] 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
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
