Database possible corruption , unsolvable mystery

From: Eric Lauzon
Subject: Database possible corruption , unsolvable mystery
Date: ,
Msg-id: F7B73864DD39FA40B6C56B3CE0D4D1CBF00796@asdc003.abovesecurite.lan
(view: Whole thread, Raw)
Responses: Re: Database possible corruption , unsolvable mystery  (Richard Huxton)
Re: Database possible corruption , unsolvable mystery  (Mark Lewis)
List: pgsql-performance

Tree view

Database possible corruption , unsolvable mystery  ("Eric Lauzon", )
 Re: Database possible corruption , unsolvable mystery  (Richard Huxton, )
 Re: Database possible corruption , unsolvable mystery  (Mark Lewis, )
 Re: Database possible corruption , unsolvable mystery  ("Eric Lauzon", )
  Re: Database possible corruption , unsolvable mystery  (stef, )
 Re: Database possible corruption , unsolvable mystery  ("Eric Lauzon", )
  Re: Database possible corruption , unsolvable mystery  (Josh Berkus, )

Greetings,

    We have an issue where we have a database with many tables.
    The layout of the database is 3 set of look alike tables with different names.
    Each set of tables has some referential integrety that point back to the main
    control table.

    On two set of tables we are able to efficiently delete referential and main record
    without a problems, but on the 3rd set we have an issue where the control table is clugged
    and delete seem to take forever , as example on the first two set a delete of 60K record take about
    4 second to 10 second but on the 3rd set it can take as long as 3hours.

    This seem to be only affecting one database , the schema and way of doing is replicated elsewhere
    and if efficient.

    The question is, even after droping 3rd set integrity , dumping the table data , deleting the table,
    doing a manual checkpoint and recreating the table with the dump data , with or without referential
    integrity , the problems still araise.

    If we copy the data from the live table and do a create table aaa as select * from problematic_table;
    the table aaa operations are normal and efficient.

    This is why our investigation brought us to the folowing questions:

    1. Are postgresql data file name are hashed references to table name(as oracle)? [~path to data
EX:/var/log/pgsql/data/[arbitraty                 numbers]/[datafile]]? 

    2. If the data files are corrupted and we re-create is it possible it uses the same files thus creating the same
issue?

     3. Since we know that all the tables has that problems is there an internal table with undisclosed references to
tablesdata files? 

    I hope the questions were clear.

    Have a good day, and thank you in advance.


Eric Lauzon
[Recherche & Développement]
Above Sécurité / Above Security
Tél  : (450) 430-8166
Fax : (450) 430-1858

AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ

Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et
peutêtre assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser
immédiatementet le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite. 

CONFIDENTIALITY NOTICE

This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and
maycontain privileged information. If you have received this communication by error, please notify the sender and
deletethe message without copying or disclosing it. 


pgsql-performance by date:

From: "Eric Lauzon"
Date:
Subject: Re: Database possible corruption , unsolvable mystery
From: Gorshkov
Date:
Subject: Re: Decide between Postgresql and Mysql (help of