Tom Lane wrote:
Andy Osborne <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
>
But with no way to reproduce it it's hard to pin blame.
Sad but true :-(
You didn't happen to make a physical copy of the news table before
dropping it, did you? It'd be interesting to examine the remains.
Sad
Andy Osborne <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> FATAL 2: open of /u0/pgdata/pg_clog/0726 failed: No such file or directory
>> What range of file names do you actually see in pg_clog?
> Currently to 00D6. I don't know what it was last night.
Not any greater, for sure. (FYI, e
Tom Lane wrote:
Andy Osborne <[EMAIL PROTECTED]> writes:
One of our databases crashed yesterday with a bug that looks
a lot like the non superuser vacuum issue that 7.2.3 was
intended to fix, although we do our vacuum with a user that
has usesuper=t in pg_user so I guess it's not that simple.
Andy Osborne <[EMAIL PROTECTED]> writes:
> One of our databases crashed yesterday with a bug that looks
> a lot like the non superuser vacuum issue that 7.2.3 was
> intended to fix, although we do our vacuum with a user that
> has usesuper=t in pg_user so I guess it's not that simple.
> FATAL 2:
All,
One of our databases crashed yesterday with a bug that looks
a lot like the non superuser vacuum issue that 7.2.3 was
intended to fix, although we do our vacuum with a user that
has usesuper=t in pg_user so I guess it's not that simple.
From the logs:
DEBUG: pq_recvbuf: unexpected EOF on c
