Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YIUw3-0001Es-Oj for pgsql-performance@arkaria.postgresql.org; Tue, 03 Feb 2015 04:17:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YIUw3-0003i4-1q for pgsql-performance@arkaria.postgresql.org; Tue, 03 Feb 2015 04:17:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YIUw0-0003ht-Td for pgsql-performance@postgresql.org; Tue, 03 Feb 2015 04:17:56 +0000 Received: from mail-by2on0691.outbound.protection.outlook.com ([2a01:111:f400:fc0c::691] helo=na01-by2-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YIUvq-0007FF-8H for pgsql-performance@postgresql.org; Tue, 03 Feb 2015 04:17:55 +0000 Received: from decina.attlocal.net (2602:306:ce8b:3460:2d00:5520:5566:dda2) by BY1PR11MB0344.namprd11.prod.outlook.com (25.160.206.16) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 3 Feb 2015 04:17:38 +0000 Message-ID: <54D04BDC.1040206@BlueTreble.com> Date: Mon, 2 Feb 2015 22:17:32 -0600 From: Jim Nasby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Slava Mudry CC: "pgsql-performance@postgresql.org" Subject: Re: why pg_class.relfrozenxid needs to be updated for frozen tables (where all rows have xmin=2)? References: <54CC2FBA.1040506@BlueTreble.com> <54D0260F.40508@BlueTreble.com> <54D029E0.7000800@BlueTreble.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2602:306:ce8b:3460:2d00:5520:5566:dda2] X-ClientProxiedBy: BLUPR11CA0040.namprd11.prod.outlook.com (10.141.240.50) To BY1PR11MB0344.namprd11.prod.outlook.com (25.160.206.16) Authentication-Results: postgresql.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR11MB0344; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BY1PR11MB0344; X-Forefront-PRVS: 0476D4AB88 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(51704005)(24454002)(479174004)(33656002)(92566002)(76176999)(50986999)(87976001)(53416004)(54356999)(86362001)(50466002)(42186005)(83506001)(46102003)(19580405001)(87266999)(23676002)(40100003)(2420400003)(15975445007)(122386002)(77156002)(93886004)(110136001)(65816999)(1411001)(47776003)(19580395003)(2950100001)(80316001)(36756003)(62966003)(3826002)(85282002)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR11MB0344; H:decina.attlocal.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR11MB0344; X-OriginatorOrg: bluetreble.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2015 04:17:38.7570 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB0344 X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 2/2/15 9:37 PM, Slava Mudry wrote: > > On Mon, Feb 2, 2015 at 5:52 PM, Jim Nasby > wrote: > > On 2/2/15 7:36 PM, Jim Nasby wrote: > > > Currently the fact that it needs to go back to old tables > and FTS them > every 2B transactions (or rely on autovacuum for this) and > you can't do > anything about it (like permanently freeze the tables) seems > like a big > scalability issue. Does it not? > > > Unfortunately it's not terribly easy to fix this. The problem is > if we > try to play games here, we must have a 100% reliable method for > changing > relfrozenxid as soon as someone inserts a new tuple in the > relation. It > might be possible to tie this into the visibility map, but no > one has > looked at this yet. > > Perhaps you'd be willing to investigate this, or sponsor the work? > > I'll see what I can do. Will talk to folks at pgDay in a month. > > > Oh, there is another possibility that's been discussed: read-only > tables. If we had the ability to mark a table read-only, then a > VACUUM FREEZE on such a table would be able to set that table's > relfrozenxid to FrozenTransactionId and prevent any further attempts > at vacuuming. This might be easier than trying to do something > automatic. > > I think if we could log "last update/delete/insert" timestamp for a > table - we could use that to freeze tables that are not changed. A timestamp wouldn't work; you need to have an exact XID. Even if it did work you still have the same problem: there's a huge, hairy race condition between what vacuum is trying to do and any DML. > I also wonder how pg_database.datfrozenxid is set? Is it equal to the > oldest pg_class.relfrozenxid for that database? Correct. > I ask because I am willing to give a try and update relfrozenxid for the > tables that are never updated and frozen. Currently we are looking at > 8-hour downtime to vacuum the whole db in single-user mode. High > availability is more important that data loss in my case. [I still don't > want to lose data, but it won't be the end of world if it happens]. Why are you trying to go into single user mode? There's no reason to do that. Forcing relfrozenxid to 2 might work, but you're certainly playing with fire. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance