DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:mime-version:content-type;
	b=fp7a3oiOqam8BmISODC6uOzFtMegE1fUkL92LO+nACm/gMo/mo6FWaWTXNu/Gxndy4
	uehYjETXXqoXepSFA4av7YVdRvhafpJStJjifWF58Xli2/l96TrVjFT3Jy/Rz3TfUQ0t
	HlyDy69VBvph4UQf6LwN8urQ1cV6OLYgTSoAk=
Message-ID: <8ea917510810170325s769b3cf1k49b94a829d7620a0@mail.gmail.com>
Date: Fri, 17 Oct 2008 12:25:37 +0200
From: "Uwe Bartels" <uwe.bartels@gmail.com>
To: pgsql-admin@postgresql.org
Subject: refreshing prepared statements after index rebuild
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_24034_10928226.1224239137943"

------=_Part_24034_10928226.1224239137943
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_24034_10928226.1224239137943
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">Hi,<br><br>we have a corrupt index (size=20GB) and are about to create a new index parallel to the corrupted index.<br>the index is running on a heavyly used online database with oltp character.<br><br>The question is what&#39;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.<br>
<br>- just dropping the corrupt index results in errors returned while executing the existing prepared statements<br>- restart of the postgres server works of course, but ... you know. that&#39;s the last solution.<br>- i cannot currently cycle all jdbc connection pools, and bouncing the app-servers &amp; daemons does heavier damage than cycling the database<br>
<br>Is there a way to centrally refresh the existing prepared statements?<br><br>any hint that results in a soft switch without disturbance of the application is appreciated.<br><br>best regards,<br>Uwe<br></div>

------=_Part_24034_10928226.1224239137943--