Re: Bug (#3484) - Missing pg_clog/0AE6
От | Zdenek Kotala |
---|---|
Тема | Re: Bug (#3484) - Missing pg_clog/0AE6 |
Дата | |
Msg-id | 47B9A209.9090406@sun.com обсуждение исходный текст |
Ответ на | Bug (#3484) - Missing pg_clog/0AE6 (Alexandra Nitzschke <an@clickware.de>) |
Список | pgsql-bugs |
Alexandra Nitzschke napsal(a): <snip> > > We went on with analyzing: > - the table was created at 2008/01/03 17:56h > - the nightly dump started at 2008/01/03 22:00h > - it tried to copy the table 'adresse_080103' at 22:00:08 > - the dump crashed at 22:32:10 ( because of the error we reported > 2007/12/14; we repaired the database not till 2008/01/11 ) > > The stat of the database file returns this: > File: "/postgres/database/data/base/23144/211593798" > Size: 1835008 Blocks: 3592 IO Block: 4096 reguläre Datei > Device: 811h/2065d Inode: 18121638 Links: 1 > Access: (0600/-rw-------) Uid: ( 1001/postgres) Gid: ( 2/ daemon) > Access: 2008-02-15 18:19:44.000000000 +0100 > Modify: 2008-01-03 22:00:34.000000000 +0100 > Change: 2008-01-03 22:00:34.000000000 +0100 > > We are wondering, that the pg_dump seems to have modified the file. > <snip> > > Could you please answer, if the pg_dump modifies the access timestamp in > some cases? > Just a idea that pg_dump invoked checkpoint but I don't expect that table data spent four hour in a buffer cache. Especially in case when max checkpoint_timeout is one hour. Zdenek
В списке pgsql-bugs по дате отправления: