"Roberts, Adam" <[EMAIL PROTECTED]> writes:
> So, my main question is, is it reasonable to say that a trans id
> wraparound failure could create a situation in which you could
> use/manipulate user data tables if you refer to the data tables directly
> but if you tried to use a util (such as pgdump
Tom,
Thanks so much for your reply. In fact we were not vacuuming this
particular db at all! While we have other postgres db's on this same
host, this was a "recently" added db and it was never added to the
individual db list to be vacuumed. We have since modified the cronjob
to perform a "vacuum
"Roberts, Adam" <[EMAIL PROTECTED]> writes:
> The following is a link to the last post we had with this same problem:
> http://openacs.org/forums/message-view?message_id=185837
Given the comment about 500M pg_clog, I would venture that you aren't
doing adequate vacuuming and have therefore run int
We thought that this might be an AOLserver problem, however, through our
investigation and comments from posts to the OpenACS board, we believe
this is an error with PostgresSQL.
We are hoping that someone might have some ideas or any experience with
this. Thanks!!
Are you vacuuming? How of
Some time ago (May 2004), we were making changes to a Postgresql server
to allow a host to connect (pg_hba.conf). When we restarted the server,
and restarted the AOLserver process, there was only one table left. All
the ACS tables were gone.
As we were troubleshooting the problem, we found the la
