pinker <pinker@onet.eu> writes:
> I'm doing simple tests with lsof on data catalog with bash script:
> #!/bin/bash
> for i in {0..2000}
> do
> psql -U postgres -c '*BEGIN; select pg_sleep(30); COMMIT*'&
> done
> and i measure number of open files and what files are affected by specific
> command.
> Lsof has shown me that the only file that was open during this test was:
> data/base/13328/2601, which is pg_catalog table pg_am.
> Why postgres opens a table that stores information about relation (index)
> access methods, while none index evidently is in use?
I'd put this in the category of "nothing to see here, move along".
The call of pg_sleep() is going to require looking in pg_proc, which
will be an indexed lookup, which will require opening pg_proc indexes,
which will require looking in pg_am. Your notion that no indexes are
in use is wrong on its face.
Now in most situations, unless you'd just started the database,
all the necessary pages would already be in shared buffers so that
there would be no need for any actual file access. However, we always
scan pg_am using a seqscan, which is ok because there are so few entries
(and necessary because otherwise we'd have an infinite recursion problem).
Seqscan startup includes probing to see how many pages the table contains,
which is going to require an lseek, which requires an open file. So I
think that probably explains why you see that file opened and no others.
There are other scenarios where file access would occur, of course, but
this seems like a plausible explanation.
regards, tom lane
