On 04/16/2014 01:30 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> >>> You can see the current multixact value in pg_controldata output. Keep >>> timestamped values of that somewhere (a table?) so that you can measure >>> consumption rate. I don't think we provide SQL-level access to those >>> values. >> >> Bleh. Do we provide SQL-level access in 9.4? If not, I think that's a >> requirement before release. > > Yeah, good idea. Want to propose a patch?
Yeah, lemme dig into this. I really think we need it for 9.4, feature frozen or not. >>>> Also: how do I check the multixact age of a table? There doesn't seem >>>> to be any data for this ... >>> >>> pg_class.relminmxid is the oldest multixact value that might be present >>> in a table. >> >> On every database I've tested, age(relminmxid) returns int_max. So this >> is apparently broken. > > Hmm, are you sure it's INT_MAX and not 4244967297? Heikki reported > that: http://www.postgresql.org/message-id/52401aea.9000...@vmware.com > The absolute value is not important; I think that's mostly harmless. I > don't think applying age() to a multixact value is meaningful, though; > that's only good for Xids. Yeah, I'm sure: josh=# select relname, age(relminmxid) from pg_class; relname | age -----------------------------------------+------------ pg_statistic | 2147483647 pg_type | 2147483647 random | 2147483647 dblink_pkey_results | 2147483647 pg_toast_17395 | 2147483647 ... So if age() doesn't mean anything, then how are users to know when the need to freeze? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
