Vous n'êtes pas identifié(e).
Hello !!
Je pense avoir trouvé d'ou vient le problème
SELECT reltoastrelid FROM pg_class WHERE relname = 'pg_largeobject';
reltoastrelid
---------------
16637Ceci doit s'expliquer du fait d'un changement de tablespace de la table pg_largeobject (vrai ou pas ?)
Avez vous une solution qui pourrait reproduire cette solution
UPDATE pg_class
SET reltoastrelid = 0
WHERE relname = 'pg_largeobject';OU bien dois je restorer la base via dump ????
Merci
La fonction grant_lob_access_to_ro exécute:
UPDATE pg_largeobject_metadata
SET lomacl ='{user=rw........}'
WHERE oid = NEW.blob;
RETURN NEW; Hello !
Merci d'avoir pris la peine de répondre
Voici plus de détail de la table:
id | bigint | | not null | | plain |
blob | oid | | not null | | plain |
Index :
"lob_pkey" PRIMARY KEY, btree (id)
Triggers :
lob_lo_unlink AFTER DELETE ON my_table FOR EACH ROW EXECUTE FUNCTION delete_lo()
lob_ro_access AFTER INSERT OR UPDATE ON my_table FOR EACH ROW EXECUTE FUNCTION grant_lob_access_to_ro()Merci
Bonjour à tous,
J'utilise debezium et donc la replication logique et je suis récemment tombé sur cette erreur qui fait planter l'utilisation de cet outil.
Cette erreur est intervenu à l'init dans une BDD et dans une autre, elle est intervenue après 1 mois d'utilisation de l'outil
ERROR: could not open toast relation with OID 0 (base relation "my_table")my_table =>
id | bigint | not null
blob | oid | not null
J'utilise PostgreSQL 12.12 , des LO se trouvent dans ma BDD et la table my_table ci dessus ne fait pas partie d'une publication
Donc debezium qui est un outil de change data capture n'est pas censé obtenir ces changements.
Auriez-vous une idée du problème ? est il possible de le résoudre ?
Merci d'avance
Debezium est un outil de change data capture !
Pour l'utiliser il faut forcement utiliser de la réplication logique
Bonjour à tous,
Nous venons d'implementer l'outil debezium avec pgoutput logical decoder
Postgresql 12.9
Master / standby avec replication physique (wal stocké sur s3)
replication logique activé pour utilisation de debezium
creation d'un replication slot pour debezium
J'aimerai ne perdre aucun event lors d'un éventuel failover/switchover. (95% des cas sont des bascules programmées)
Je pars sur une méthode qui consiste à recopier à l'identique mon replication_slot sur la futur master afin de garder le meme restart_lsn et confirmed_flush_lsn
Voici mes étapes lors d'une bascale:
=> stop Master
=> Copy du fichier state de pg_replslot/* sur mon futur master
=> Restart du futur master (pour prendre en compte le replication_slot)
=> Promote
=> Ici je retrouve mon replication_slot avec les meme valeurs restart_lsn et confirmed_flush_lsn
=> Restart de DEBEZIUM avec un erreur
Voici l'erreur => Caused by: org.postgresql.util.PSQLException: ERROR: requested WAL segment 000000060000001C000000E2 has already been removed
Pouvez m'expliquer cette erreur ?
Pouvez m'indiquer si est possible d'y remédier facilement ?
PS: j'ai pu résoudre cette erreur en récupérant ce wal manquant et en le copiant dans pg_wal
Bonjour,
Je prévois de passer sous PostgreSQL 12 bientôt, néanmoins mon application possède énormément de CTE,
Est ce que PostgreSQL à prévu un moyen simple de revoir la syntaxe des CTE une fois passé en PostgreSQL 12 afin de garder son comportement initial ?
Ou bien est ce que je vais devoir rajouter "MATERIALIZED" à la main pour chaque CTE de mon code ?
Merci
Bonjour,
J'aimerai savoir si quelqu'un a une explication à mon problème :
Cette erreur survient lors d'une tentative d'upgrade de pg9.5 vers pg12 via pg_upgrade et le link mode.
Ci-dessous mon erreur :
Linking user relation files
No match found in new cluster for old relation with OID 16619 in database "my_database": "pg_toast.pg_toast_2613" which is the TOAST table for "pg_catalog.pg_largeobject"
No match found in new cluster for old relation with OID 16621 in database "my_database": "pg_toast.pg_toast_2613_index" which is an index on "pg_toast.pg_toast_2613" which is the TOAST table for "pg_catalog.pg_largeobject" Merci
Bonjour,
Sauf erreur de ma part initdb initialise la locale et l'encodage de jeu de caractères par défaut du cluster en se basant sur template 1
Ma question est la suivante :
Est ce que les valeurs des paramètre LC_COLLATE et LC_CTYPE du template 1 seront toujours les mêmes lors d'un initdb ?
ou bien peux ton trouver des valeurs différentes en fonctions de l'installation (rds,sqlcloud,distribution...) ?
Merci
Merci Messieurs pour vos réponses !
Marc votre explication à surement du sens, en effet ma base à fait un bon de 15 GB depuis que le SELECT avait été lancé sur le slave
Ce qui prouve peut être que les vacuum ne passaient pas et que du bloat s'est installé affectant peut être les perf de la base
Bonjour,
J'aurai voulu savoir si un slave peut impacter les performances de son Master ?
Mon master étant surchargé depuis plusieurs jour je viens tout juste de me rendre compte qu'une requête SELECT était en cours sur le slave depuis plusieurs jours
Mais une fois la requête cancel sur le slave, la Master reste toujours chargé.
Pour infos :
archive_command = 'AWS_REGION=eu-west-1 wal-e --s3-prefix s3://bucket --aws-instance-profile wal-push %p'
wal_level =hot_standby
archive_mode = on
hot_standby = on
Merci
Malheureusement personne n'a exécuté de pg_stat_reset !
Donc est ce que postgresql peut reset ses stats autrement que par l'utilisation de pg_stat_reset ??
Merci
Bonjour,
Je viens de remarquer un reset de stats sur ma base postgres (à 01:00) et ma base en production (à 20h14),
J'aurai voulu comprendre le pourquoi mes 2 bases ont été reset ! Pour information il y a eu intervention sur la base "ma_base_prod_db" avec un pg_terminate_backend à 20h14 ( heure du reset )
SELECT datname, stats_reset from pg_stat_database;
datname | stats_reset
-----------+-------------------------------
ma_base_prod_db | 2019-05-29 20:14:55
template0 |
postgres | 2019-05-30 01:00:01
template1 |
(4 rows)
Merci à vous
Bonjour,
J'aurai voulu savoir s'il y avait un moyen simple de savoir le nombre de lock effectué dans une transaction ?
Merci
Bonjour ,
Je dois faire un vacuum full sur la table pg_largeobject , après un premier test il a mit plus de 8h.
J'aimerai savoir quels peuvent être les paramètres de conf postgresql à modifier pour accélérer le temps de ce vacuum !
Contexte :
Juste le vacuum full de pg_largeobject tournera sur la base, la table contient 500 millions de live tuples et plus d'un milliard de dead rows.
maintenance_work_mem='2GB'
Machine :
CPU Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz (16 threads) -- 64 Go RAM
Merci
Merci Guillaume,
Du coup le jour J j'aimerai :
- cancel cet autovacuum qui tourne depuis très longtemps
- delete les rows de ma table "table_lob"
- Puis lancer un Vacuumfull sur pg_largeobjet
J'aimerai savoir si tu as une solution pour empêcher un autovacuum(prevent wraparound) de se déclancher ???
Merci
Bonjour,
J'ai testé la suppression de 35k rows sur une table "table_lob" , résultat 3h30 !!! c'est vraiment trop long et j'aimerai comprendre pourquoi 
Le contexte :
- Sur la table "table_lob" il y a un trigger qui fait : AFTER DELETE ON table_lob FOR EACH ROW EXECUTE PROCEDURE delete_lo()
- Un autovaccum (prevent wraparound) en cours sur la table pg_largeobjet
Je pense que le trigger y est pour quelques chose , et j'aimerai savoir si l'autovacuum sur pg_largeobject a aussi des conséquences sur le temps du Delete ?
Je suis aussi ouvert à toute proposition pour améliorer mon temps de suppression.
Merci d'avance
Je viens de tester de lancer un VACUUMFULL pendant que l'autovacuum: VACUUM pg_catalog.pg_largeobject (to prevent wraparound) tourne .
Et j'ai mon vacuumfull qui est en WAITING .
Est ce normal ? Il faut donc bien que je cancel l'autovaccum puis qu'après je lance le vacuumfull ?
Bonjour,
Voici ma situation :
J'ai la possibilité de faire une interruption de service de plusieurs heures chez un client ,
J'aimerai donc on profiter pour faire un VACUUM FULL sur la table pg_largeobjet : 4 To dont 700 gigas de données ....
J'ai actuellement un autovacuum: VACUUM pg_catalog.pg_largeobject (to prevent wraparound) qui tourne depuis plusieurs mois ..
Première question : Y'a t-il un risque à cancel l'autovacuum: VACUUM pg_catalog.pg_largeobject (to prevent wraparound) ? afin que je puisse lancer mon VACUUMFULL
Deuxième question : Comment faire pour que l'autovacuum (to prevent wraparound) ne s'active pas entre le moment ou je vais le cancel et le moment ou je lancerai mon VACUUMFULL (j'ai cru comprendre que meme avec autovacuum off il s'activait)
En espérant avoir été suffisamment clair .
Merci
Parfait !
Merci Guillaume .
Bonjour,
J'aurai une petite question concernant la commande psql -c :
Voici un script utilisé sur ma machine locale version 9.6 :
for row in $schema_table; do
psql -At $database -c "set statement_timeout = 20000;" -c "ANALYZE $row; -- anal_all_tables.sh cron" || true
done
Résultat :
SET
ANALYZE
SET
ANALYZE
SET
ANALYZE
.......
Et ce même script sur une machine "prod" version 9.5 renvoie :
ANALYZE
ANALYZE
ANALYZE
ANALYZE
ANALYZE
.....
Donc sur ma machine local (9.6) le set statement_timeout = 20000 est bien prit en compte ,
alors que sur la machine "prod" il n'est pas prit en compte.
J'aimerai comprendre le cause de se problème , est ce que la version postgresql joue un role ? ou bien est un changement de conf qui influe psql sur la machine prod !
Merci !!!!
Merci Guillaume pour la réponse !
Bonjour ,
J'ai actuellement une table pg_largeobject qui fait 3.5 Teraoctet dont 2.5 Teraoctect de bloat et 1 Tera de livetuples !
Petite question technique :
Aujourd'hui je pense qu'un vacuumfull sur cette table mettrait plusieurs jours, mais j'aimerai savoir si le fait de supprimer une grande partie des livetuples diminurait le temps de ce vacuumfull ???
Merci
Bonjour ,
J'ai actuellement une table pg_largeobject qui fait 3.5 Teraoctet dont 2.5 Teraoctect de bloat et 1 Tera de livetuples !
Petite question technique :
Aujourd'hui je pense qu'un vacuumfull sur cette table mettrait plusieurs jours, mais j'aimerai savoir si le fait de supprimer une grande partie des livetuples diminurait le temps de ce vacuumfull ???
Merci
Bonjour ,
e.papet avez vous des nouvelles concernant votre problème ?
Cela m’intéresse énormément.
Merci