Обсуждение: archive logs recovery
I have a situation where the database needs to be restarted periodically. Will this affect recovery of a database using a base online backup that took place earlier than the restart. i.e
- Take a base online backup
- Later shutdown and restart
- Perform a recovery using the base backup and the archive logs
"Sriram Dandapani" <sdandapani@counterpane.com> writes: > I have a situation where the database needs to be restarted > periodically. Will this affect recovery of a database using a base > online backup that took place earlier than the restart. No. But why do you need to shut down the database? Most people around here seem to want 24x7 operation ... regards, tom lane
I have a very high traffic db with lots of table partitions. The only reliable way to drop the partitioned tables is to prevent any insert/select on the parent table , otherwise, the drop table locks out the inserts, and strangely enough, the drop table command goes into a wait state. During shutdown and restart, I switch the pg_hba.conf to disallow client access for a brief period when the tables are dropped. -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Thursday, August 31, 2006 1:20 PM To: Sriram Dandapani Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] archive logs recovery "Sriram Dandapani" <sdandapani@counterpane.com> writes: > I have a situation where the database needs to be restarted > periodically. Will this affect recovery of a database using a base > online backup that took place earlier than the restart. No. But why do you need to shut down the database? Most people around here seem to want 24x7 operation ... regards, tom lane
"Sriram Dandapani" <sdandapani@counterpane.com> writes: > I have a very high traffic db with lots of table partitions. The only > reliable way to drop the partitioned tables is to prevent any > insert/select on the parent table , otherwise, the drop table locks out > the inserts, and strangely enough, the drop table command goes into a > wait state. During shutdown and restart, I switch the pg_hba.conf to > disallow client access for a brief period when the tables are dropped. You do know you can change pg_hba.conf without a restart? As for the drop going into a wait state, you might want to look around for client code that's sitting idle with an open transaction. The drop should not block for longer than whatever is your longest transaction touching that table. regards, tom lane
The issue is that the drop table immediately puts the jdbc insert into a wait state and goes into a wait state itself. -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Thursday, August 31, 2006 1:37 PM To: Sriram Dandapani Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] archive logs recovery "Sriram Dandapani" <sdandapani@counterpane.com> writes: > I have a very high traffic db with lots of table partitions. The only > reliable way to drop the partitioned tables is to prevent any > insert/select on the parent table , otherwise, the drop table locks out > the inserts, and strangely enough, the drop table command goes into a > wait state. During shutdown and restart, I switch the pg_hba.conf to > disallow client access for a brief period when the tables are dropped. You do know you can change pg_hba.conf without a restart? As for the drop going into a wait state, you might want to look around for client code that's sitting idle with an open transaction. The drop should not block for longer than whatever is your longest transaction touching that table. regards, tom lane
Also, the dynamic pg_hba changes work only for new connections that are being established via jdbc. Existing connections seem to able to make connections. -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Thursday, August 31, 2006 1:37 PM To: Sriram Dandapani Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] archive logs recovery "Sriram Dandapani" <sdandapani@counterpane.com> writes: > I have a very high traffic db with lots of table partitions. The only > reliable way to drop the partitioned tables is to prevent any > insert/select on the parent table , otherwise, the drop table locks out > the inserts, and strangely enough, the drop table command goes into a > wait state. During shutdown and restart, I switch the pg_hba.conf to > disallow client access for a brief period when the tables are dropped. You do know you can change pg_hba.conf without a restart? As for the drop going into a wait state, you might want to look around for client code that's sitting idle with an open transaction. The drop should not block for longer than whatever is your longest transaction touching that table. regards, tom lane
On 8/31/06, Sriram Dandapani <sdandapani@counterpane.com> wrote:
What about changing the permissions on the tables using the GRANT/REVOKE? That way you can stop access to the tables you are working with without having to change the pg_hba.conf or restarting the database.
==================================================================
Aaron Bono
Aranya Software Technologies, Inc.
http://www.aranya.com
http://codeelixir.com
==================================================================
Also, the dynamic pg_hba changes work only for new connections that are
being established via jdbc. Existing connections seem to able to make
connections.
==================================================================
Aaron Bono
Aranya Software Technologies, Inc.
http://www.aranya.com
http://codeelixir.com
==================================================================