From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kurt Overberg <kurt(at)hotdogrecords(dot)com> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Maintenance question / DB size anomaly... |
Date: | 2007-06-20 18:37:46 |
Message-ID: | 28417.1182364666@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Kurt Overberg <kurt(at)hotdogrecords(dot)com> writes:
> Okay, so I did some digging with pg_filedump, and found the following:
> Block 406 ********************************************************
> Item 1 -- Length: 472 Offset: 7720 (0x1e28) Flags: USED
> XMIN: 1489323584 CMIN: 1 XMAX: 0 CMAX|XVAC: 0
> Block Id: 406 linp Index: 1 Attributes: 6 Size: 32
> infomask: 0x0912 (HASVARWIDTH|HASOID|XMIN_COMMITTED|XMAX_INVALID)
This is pretty much what you'd expect for a never-updated tuple...
> mydb=# select * from _my_cluster.sl_log_1 where ctid = '(406,1)';
> log_origin | log_xid | log_tableid | log_actionseq | log_cmdtype |
> log_cmddata
> ------------+---------+-------------+---------------+-------------
> +-------------
> (0 rows)
so I have to conclude that you've got a wraparound problem. What is the
current XID counter? (pg_controldata will give you that, along with a
lot of other junk.) It might also be interesting to take a look at
"ls -l $PGDATA/pg_clog"; the mod times on the files in there would give
us an idea how fast XIDs are being consumed.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2007-06-20 19:25:28 | Re: Performance query about large tables, lots of concurrent access |
Previous Message | Michael Stone | 2007-06-20 18:20:53 | Re: Performance query about large tables, lots of concurrent access |