Re: [HACKERS] SSL over Unix-domain sockets

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] SSL over Unix-domain sockets
Date: 2008-01-18 08:37:00
Message-ID: Pine.GSO.4.64.0801180212500.26712@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Thu, 17 Jan 2008, Tom Lane wrote:

> BTW, is a symlink's atime changed by accessing it?

It seems so in the cases I've tried or researched, but it's complicated.
After burning through a bunch of time looking into this I wanted to drop
some notes so nobody else has to wander down the specific dead-ends I just
followed.

I figured I'd just run some experiments to figure this out for my Linux
system, but that didn't go so well. The process of running anything that
shows the atime:

ls -l --time=atime <file>
ls -lu <file>
stat <file>

actually updates the atime to right now along the way. I hacked up
something with perl that directly calls lstat() and it did the same thing.

Mystified, I found this thread suggesting the same thing is true on Mac OS
X: http://lists.apple.com/archives/darwin-kernel/2006/Dec/msg00054.html

The point made in there is that how symlinks are encoded varies not just
from OS to OS but from filesystem to filesystem, and that encoding changes
how things like atime work. On Linux with ext2, I found this note:

"Symbolic links are also filesystem objects with inodes. They deserve
special mention because the data for them is stored within the inode
itself if the symlink is less than 60 bytes long. It uses the fields
which would normally be used to store the pointers to data blocks."

So what I think is happening is: the process of doing anything at all
with a Linux symlink references the inode that has the link. That updates
the atime on that inode. But since there's no actual data underneath that
lookup in cases where the link is less than 60 bytes, the inode atime is
the link atime, so that just updated the link's atime to right now as
well. I have no idea how any tmp cleaner could ever find a short symlink
it can delete if I'm understanding this correctly.

I left behind the link I was just playing with and I'll see if I can get
tmpwatch to eat it tomorrow, that seems like the most appropriate test
here.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2008-01-18 09:17:13 Re: Simple thing to make pg_autovacuum more useful
Previous Message Magnus Hagander 2008-01-18 08:23:26 Re: Simple thing to make pg_autovacuum more useful

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2008-01-18 10:22:41 Re: [HACKERS] SSL over Unix-domain sockets
Previous Message Stefan Schwarzer 2008-01-18 06:00:52 Re: Forgot to dump old data before re-installing machine