I'm seeing this in my PGSQL logs, is this something to be concerned
about? I know the file system it sits on is reliable and the DB appears
to run with fine, additionally the log indicates it's a debug message. I
did some google searches and didn't find much.

When I examine the file system file by these names to not exist.

Thanks,
Wayne

----------------------------------------------------------------------
2012-07-19 21:05:42.840 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/45365979_fsm" but retrying: No such file or directory
2012-07-20 06:25:43.899 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/45413298_fsm" but retrying: No such file or directory
2012-07-20 11:20:44.755 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/45438221_fsm" but retrying: No such file or directory
2012-07-20 15:40:45.974 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/45460199_fsm" but retrying: No such file or directory
2012-07-22 12:35:43.882 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/45687933_fsm" but retrying: No such file or directory
2012-07-25 03:35:42.933 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/46007387_fsm" but retrying: No such file or directory
2012-07-25 06:30:45.354 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/46022167_fsm" but retrying: No such file or directory
2012-07-26 06:48:13.595 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/46145719_fsm" but retrying: No such file or directory
2012-07-28 17:58:40.774 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/46445945_fsm" but retrying: No such file or directory
2012-08-01 09:38:42.234 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/46890581_fsm" but retrying: No such file or directory
2012-08-05 01:07:43.659 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/47334522_fsm" but retrying: No such file or directory
2012-08-07 01:27:43.605 GMT 8966 4fd07ba5.2306 @: DEBUG: could not
fsync
file "base/16711/47579627_fsm" but retrying: No such file or directory

--
Sent via pgsql-sql mailing list (pgsql-sql (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Wayne Cuddy <lists-pgsql (AT) useunix (DOT) net> writes:
If it only complains once per file name, this is expected behavior when
somebody drops a table just before the checkpoint mechanism tries to
fsync it. (If the failure were to repeat, then it might be something
more interesting.) It does seem a bit odd that only fsm files are being
complained of, though.

What PG version is that exactly?

regards, tom lane

--
Sent via pgsql-sql mailing list (pgsql-sql (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

On Wed, Aug 08, 2012 at 12:23:22PM -0400, Tom Lane wrote:
It's 9.0.4. I'm frequently truncating tables but not dropping them.

--
Sent via pgsql-sql mailing list (pgsql-sql (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Wayne Cuddy <lists-pgsql (AT) useunix (DOT) net> writes:
Under the hood, TRUNCATE creates a new empty table and then drops the
old one after commit. So that sounds consistent. It's still a bit odd
that all the messages are about FSM files, but maybe that has something
to do with sequence-of-operations in the DROP. Anyway, nothing to see
here AFAICT.

regards, tom lane

--
Sent via pgsql-sql mailing list (pgsql-sql (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Ok, I'll keep an eye on it but I'm not so worried now.

Thanks Tom.


On Wed, Aug 08, 2012 at 12:57:01PM -0400, Tom Lane wrote:
--
Sent via pgsql-sql mailing list (pgsql-sql (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql