Re: Indexes getting corrupted.

Поиск
Список
Период
Сортировка
От Bruno G. Albuquerque
Тема Re: Indexes getting corrupted.
Дата
Msg-id 42A9C2F7.50306@dba.com.br
обсуждение исходный текст
Ответ на Re: Indexes getting corrupted.  (Scott Marlowe <smarlowe@g2switchworks.com>)
Ответы Re: Indexes getting corrupted.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin


Scott Marlowe wrote:

>>I am having a weird problem here. I have the automated process to
>>install PostgreSQL (8.0.1) on Windows 2000 machines. Besides installing
>>the database server itself, my process does the following:
>>
>>1 - Runs initdb to created the database I will be using.
>>2 - Runs a SQL script that creates the entire database and populates
>>some of the tables.
>>3 - Runs another script that populates other tables (using COPY).
>>
>>What happens is that, sometimes, after the entire process run, I end up
>>with a database with virtually all indexes corrupt! Try to use the
>>indexes for anything results in "index is not a btree" error. This
>>happens randomly and I can get it fixed sometimes by simply erasin
>>everything and starting over.
>
>
> Note that such behaviour is normally associated with bad hardware (RAM,
> hard drive, controller, CPU, you name it...)  But since the windows port
> is pretty new, you may have found some corner case.

I think I figured it out. The problem is related to rebooting the
machine. Here are the results of my testing:

- Stopping the service before rebooting (log file contents)

[...]
2005-06-10 11:44:40 LOG:  received fast shutdown request
2005-06-10 11:44:40 LOG:  shutting down
2005-06-10 11:44:40 LOG:  database system is shut down
2005-06-10 11:44:41 LOG:  logger shutting down

- After rebooting:

2005-06-10 11:47:25 LOG:  database system was shut down at 2005-06-10
11:44:40 Horário padrão CAIXA -3
2005-06-10 11:47:25 LOG:  checkpoint record is at 0/16D35A8
2005-06-10 11:47:25 LOG:  redo record is at 0/16D35A8; undo record is at
0/0; shutdown TRUE
2005-06-10 11:47:25 LOG:  next transaction ID: 1487; next OID: 64574
2005-06-10 11:47:26 LOG:  database system is ready

- Rebooting the machine without stopping the service:

[...]
2005-06-10 11:39:30 LOG:  received fast shutdown request

- After rebooting:

2005-06-10 11:41:46 LOG:  database system was interrupted at 2005-06-10
11:37:22 Horário padrão CAIXA -3
2005-06-10 11:41:46 LOG:  checkpoint record is at 0/AC30F0
2005-06-10 11:41:46 LOG:  redo record is at 0/AC30F0; undo record is at
0/0; shutdown TRUE
2005-06-10 11:41:46 LOG:  next transaction ID: 546; next OID: 17230
2005-06-10 11:41:46 LOG:  database system was not properly shut down;
automatic recovery in progress
2005-06-10 11:41:47 LOG:  redo starts at 0/AC3130
2005-06-10 11:42:09 LOG:  record with zero length at 0/16C8698
2005-06-10 11:42:09 LOG:  redo done at 0/16C8668
2005-06-10 11:42:15 LOG:  database system is ready
2005-06-10 11:42:38 ERROR:  index "pk_cubtb021_localidade" is not a btree
2005-06-10 11:43:08 ERROR:  index "pk_cubtb021_localidade" is not a btree
2005-06-10 11:43:09 ERROR:  index "pk_cubtb038_ocupacao" is not a btree

The btree errors are the ones I am getting when running the client
application that connets to this database.

So, it seems that 2 things are happening:

1 - For some reason, the system seems to be killing the postgresql
processes before it has a chance to clean up.

2 - When it tries to recover from this, it ends up messing up the
indexes for some reason.

Any pointers? Is there anything I can do for Windows to actually wait
for the postgresql processes to clean up?

> Do you have a "pre-packaged" test case that induces failures most of the
> time or something like that?

As pointed above, it seems the problem is related to shuting down the
machine.

> Are these machines all basically make/model/brand/chipset etc... of
> machines?  Then it might be a buggy driver or something.

Nope. Completelly different. But all running Windows 2000 or XP and
running PostgreSQL 8.0.1.

-Bruno

**********************************************************************
Informação transmitida destina-se apenas à pessoa a quem foi endereçada e pode conter informação confidencial,
legalmenteprotegida e para conhecimento exclusivo do destinatário. Se o leitor desta advertência não for o seu
destinatário,fica ciente de que sua leitura, divulgação ou cópia é estritamente proibida. Caso a mensagem tenha sido
recebidapor engano, favor comunicar ao remetente e apagar o texto de qualquer computador. 


The information transmitted is intended only for the person or entity to which it is addressed and may contain
confidentialand/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any
actionin reliance upon this information, by person or entity other than the intended recipient is prohibited. If you
receivedthis in error, please contact the sender and delete the material from any computer. 
**********************************************************************

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Lee Wu"
Дата:
Сообщение: Re: select * and save into a text file failed
Следующее
От: Tom Lane
Дата:
Сообщение: Re: select * and save into a text file failed