Re: could not truncate directory "pg_subtrans": apparent wraparound
| От | Mikko Partio |
|---|---|
| Тема | Re: could not truncate directory "pg_subtrans": apparent wraparound |
| Дата | |
| Msg-id | AANLkTilSLidcJIl8feLS9bMFoGdpq0noOffO21o8RTyo@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: could not truncate directory "pg_subtrans": apparent wraparound (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: could not truncate directory "pg_subtrans": apparent
wraparound
|
| Список | pgsql-admin |
On Sun, May 23, 2010 at 9:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Mikko Partio <mpartio@gmail.com> writes:> got the following line at postgresql log:
> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> directory "pg_subtrans": apparent wraparound> PostgreSQL 9.0beta1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)Where did this beta1 installation come from --- was it freshly initdb'd
> 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit
under 9.0, or did you use pg_upgrade on a pre-existing database that had
been around for awhile? It strikes me that the recently identified bug
in pg_upgrade about not fixing the datfrozenxid of template0 might
possibly explain this. You'd need to have upgraded an installation that
was at least a couple billion transactions old to hit that bug.
It was freshly initdb'd with beta1 binaries, the contents were loded from a pg_dump file. The number of transactions is very small, we're talking about thousands (not billions). This database is the master of a hot standby installation, if that matters.
Regards
Mikko
В списке pgsql-admin по дате отправления: