[HACKERS] pg_rewarm status
Trying to follow the threads and other references - but I can't determine where this patch ended up. (http://www.postgresql.org/message-id/ca+tgmobrrrxco+t6gcqrw_djw+uf9zedwf9bejnu+rb5teb...@mail.gmail.com) I'm trying to experiment with some new hardware - and the functionality to add specific tables/indexes into cache ahead of time will benefit me greatly. I found a page describing how to apply the patch to 9.2.4 (jumping through some hoops - http://issues.collectionspace.org/browse/UCJEPS-432) and was hoping to get a version to apply to 9.3.X Can anyone advise me on how I might get this 'applied' to a 9.3.X source code base or any other options to denote specific relations that I'd like to get directly into shared_buffers? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] AutoVacuum Behaviour Question
Bruce Momjian wrote: No, it isn't. Please add a TODO item about it: * Prevent long-lived temp tables from causing frozen-Xid advancement starvation Can somebody explain this one to me? because of our auditing technique, we have many LONG lived temp tables.(one per pooled connection)...so as long as the pool isn't disturbed, these temp tables can exist for a long time (weeksmonths?) (previous thread about our use of temp tables and autovacuum/xid issues) http://archives.postgresql.org/pgsql-general/2007-01/msg00690.php http://archives.postgresql.org/pgsql-general/2007-01/msg00691.php
Re: [HACKERS] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Tom Lane [EMAIL PROTECTED] wrote: Really? Wow, *that's* an interesting thought. Is it likely that that temp table could contain many-hour-old data? Certainly...our connection pool used by jboss can have connections to postgres persisting for multiple days. (We're still looking for a way to tell it to recycle these occasionally). As each 'user' of our web based app performs some action, they acquire one of the connection pool connections and set their user_id in the temporary table used by that connection (we use that for our audit triggers) Once they are 'done' with the connection, the connection is just released back to the pool but not actually closed...so the temp table still contains the data from a previous iteration. - TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV.
