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
This was posted under the wrong subject.. Please ignore, will repost.
On Wed, Aug 08, 2012 at 11:41:01AM -0400, Wayne Cuddy wrote:
> 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, add
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
Wayne Cuddy 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 e
On Wed, Aug 08, 2012 at 12:23:22PM -0400, Tom Lane wrote:
> Wayne Cuddy 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 mess
Wayne Cuddy 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 somethin
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 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
> >> some