Thread: fsync debug messages in pgsql logs
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
Wayne Cuddy <lists-pgsql@useunix.net> writes:
> 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.
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
On Wed, Aug 08, 2012 at 12:23:22PM -0400, Tom Lane wrote: > Wayne Cuddy <lists-pgsql@useunix.net> writes: > > 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. > > 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 It's 9.0.4. I'm frequently truncating tables but not dropping them.
Wayne Cuddy <lists-pgsql@useunix.net> writes:
> On Wed, Aug 08, 2012 at 12:23:22PM -0400, Tom Lane wrote:
>> 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?
> It's 9.0.4. I'm frequently truncating tables but not dropping them.
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
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: > Wayne Cuddy <lists-pgsql@useunix.net> writes: > > On Wed, Aug 08, 2012 at 12:23:22PM -0400, Tom Lane wrote: > >> 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? > > > It's 9.0.4. I'm frequently truncating tables but not dropping them. > > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-sql