| From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
|---|---|
| To: | Alexandra Nitzschke <an(at)clickware(dot)de> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Bug (#3484) - Missing pg_clog/0AE6 |
| Date: | 2008-02-18 15:19:37 |
| Message-ID: | 47B9A209.9090406@sun.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-02-18 15:29:44 | Re: BUG #3965: UNIQUE constraint fails on long column values |
| Previous Message | Pawel Kasperek | 2008-02-18 15:08:13 | BUG #3966: problem with implicit cast array parameter |