pg.ddx.io pgsql-admin@postgresql.org mailing list archivehelp / color / mirror / Atom feed
refreshing prepared statements after index rebuild 2+ messages / 2 participants [nested] [flat]
* refreshing prepared statements after index rebuild @ 2008-10-17 10:25 Uwe Bartels <uwe.bartels@gmail.com> 0 siblings, 1 reply; 2+ messages in thread From: Uwe Bartels @ 2008-10-17 10:25 UTC (permalink / raw) To: pgsql-admin Hi, we have a corrupt index (size=20GB) and are about to create a new index parallel to the corrupted index. the index is running on a heavyly used online database with oltp character. The question is what's the softest way to switch to the new index. there are several application servers, webapplications and other daemons which use prepared statements on the table associated with that index. - just dropping the corrupt index results in errors returned while executing the existing prepared statements - restart of the postgres server works of course, but ... you know. that's the last solution. - i cannot currently cycle all jdbc connection pools, and bouncing the app-servers & daemons does heavier damage than cycling the database Is there a way to centrally refresh the existing prepared statements? any hint that results in a soft switch without disturbance of the application is appreciated. best regards, Uwe ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: refreshing prepared statements after index rebuild @ 2008-10-17 12:10 Tom Lane <tgl@sss.pgh.pa.us> parent: Uwe Bartels <uwe.bartels@gmail.com> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2008-10-17 12:10 UTC (permalink / raw) To: Uwe Bartels <uwe.bartels@gmail.com>; +Cc: pgsql-admin "Uwe Bartels" <uwe.bartels@gmail.com> writes: > - just dropping the corrupt index results in errors returned while executing > the existing prepared statements If you were running 8.3 it would Just Work, so I take it you're not. > - restart of the postgres server works of course, but ... you know. that's > the last solution. > - i cannot currently cycle all jdbc connection pools, and bouncing the > app-servers & daemons does heavier damage than cycling the database I'm afraid those are your only options :-( --- pre 8.3, there's no way short of starting fresh sessions to get rid of cached plans for prepared statements. regards, tom lane ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2008-10-17 12:10 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2008-10-17 10:25 refreshing prepared statements after index rebuild Uwe Bartels <uwe.bartels@gmail.com> 2008-10-17 12:10 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox