Forums PostgreSQL.fr

Bonjour,

J'utilise le partitionning dans Postgres 12 (avec INHERITS) sur des intervalles de date mensuels. Quand je lance un vacuum full directement sur une "vieille" partition qui peut durer plusieurs minutes, mes autres requêtes d'écriture et même de lecture sont bloquées pendant ce temps. les requêtes de lectures passent par la table principale en précisant un intervalle de date "récent" (ne contenant pas la partition en cours de vacuum).

sur une requête de select "bloquée", je vois un AccessShareLock granted à true sur toutes les partitions sauf à false sur celle en cours de vacuum
La résolution par le planner des partitions impactées pour le select ne peut pas se faire si une des partitions est lockée ?
c'est gênant à l'usage. casser le lien d'héritage le temps du vacuum est-elle la seule solution ?

Je ne sais pas si le partitioning déclaratif change quelque chose à ce niveau ? ou sur une version plus récente de postgres ?

Merci

Le Maroc a supprimé le changement d'heure d'été et conservé son heure d'été depuis le 27Oct2018 (l'Europe réfléchie pour 2021...)
Es ce que postgres gère les historiques de changement d'heure ? comment met on à jour ces définitions dans Postgres ? (exemple en java, il y a un utilitaire tzupdater.jar qui se connecte sur le site web iana pour mettre à jour l'installation java sur la machine locale)

Pour des stats journalières, j'utilise des requêtes du style

select date_trunc('day', horodate at time zone 'Africa/Casablanca') at time zone 'Africa/Casablanca' as dateDay, sum(valeur)
...
goup by dateDay

set timezone='Africa/Casablanca';

select '2017-11-26 20:08 Africa/Casablanca'::timestamp with time zone, '2018-10-26 20:08 Africa/Casablanca'::timestamp with time zone
timestamptz    timestamptz
2017-11-26 20:08:00+00    2018-10-26 20:08:00+01
=> OK hiver 2017 UTC        ok été 2018 UTC+1

select '2018-11-26 20:08 Africa/Casablanca'::timestamp with time zone
timestamptz   
2018-11-26 20:08:00+00
=> KO UTC+1 depuis 27/10/2018

select now() -- 19h13+01
2019-01-14 18:13:18.91+00
=> KO 19h13+01 attendu: UTC+1 depuis 27/10/2018