Lennart - Slava Ukraini's questions

Tentei criar um procedimento para ajustar uma sequência de acordo com o valor máximo em uma coluna. Para obter o valor máximo da coluna e armazená-lo em uma variável, acabei usando um cursor "fictício". Imagino que haja uma maneira mais simples, mas não consegui fazer nenhuma delas funcionar. Alguma sugestão sobre como me livrar do cursor e ainda conseguir usar o valor máximo na instrução alter?

--#SET TERMINATOR @
CREATE OR REPLACE PROCEDURE Adjust_Sequence(
    IN p_table_schema VARCHAR(128),
    IN p_table_name VARCHAR(128),
    IN p_column_name VARCHAR(128),
    IN p_sequence_name VARCHAR(128)
)
LANGUAGE SQL
BEGIN
    DECLARE v_max_value BIGINT DEFAULT 1;
    DECLARE v_sql_stmt VARCHAR(1000);
    DECLARE cur CURSOR FOR S;

    -- Construct SQL to get the max value of the specified column
    SET v_sql_stmt = 'SELECT COALESCE(MAX(' || p_column_name || '), 0) + 1 FROM ' ||  p_table_schema || '.' || p_table_name;

    -- Prepare and execute the statement properly
    PREPARE S FROM v_sql_stmt;
    OPEN cur;
    FETCH cur INTO v_max_value;
    CLOSE cur;

    -- Construct SQL to alter the sequence to restart with the new max value
    SET v_sql_stmt = 'ALTER SEQUENCE ' || p_sequence_name || ' RESTART WITH ' || v_max_value;

    -- Execute the sequence alteration
    EXECUTE IMMEDIATE v_sql_stmt;
END @
--#SET TERMINATOR ;

Percebi que importar dados truncados apenas gera um aviso. Achei que seria simples capturar esse aviso e sinalizar um erro por meio de um manipulador, mas não consigo fazer isso. Alguma sugestão?

CREATE OR REPLACE PROCEDURE FILE_IMPORT_HANDLER(filename VARCHAR(255), tablename 
VARCHAR(255))
LANGUAGE SQL
BEGIN
    DECLARE EXIT HANDLER FOR SQLSTATE '22001'
        SIGNAL SQLSTATE '75002'
            SET MESSAGE_TEXT = '...';

    CALL ADMIN_CMD('import from ' || filename || ' of del insert into ' || tablename);
END @

Eu gostaria de falhar muito se 22001 for encontrado. De certa forma, aumente a gravidade do truncamento de dados durante a importação

Antes de perceber que existia um procedimento para revalidar objetos (SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS), escrevi o meu próprio. Agora, tento substituí-lo pelo padrão, mas parece que a chamada para SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS destrói o cursor sobre o qual estou fazendo o loop. Exemplo de procedimento antigo:

db2 -td@ +c "BEGIN FOR v AS c1 CURSOR FOR SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS DO CALL TOOLBOX.COMPILE_SCHEMA2(v.schemaname); END FOR; END @"
DB20000I  The SQL command completed successfully.

Exemplo usando ADMISN_REVALIDATE_DB_OBJECTS

db2 "CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>'TMP')"
Return Status = 0
db2 "CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>'TMP')"
Return Status = 0

Tentando usar isso em um loop sobre um cursor:

db2 -td@ +c "BEGIN FOR v AS c1 CURSOR FOR SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS DO CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>v.schemaname); END FOR; END @"
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0501N  The cursor specified in a FETCH statement or CLOSE statement is not 
open or a cursor variable in a cursor scalar function reference is not open.  
SQLSTATE=24501

Observe que não ajuda conectar o esquema:

db2 -td@ +c "BEGIN FOR v AS c1 CURSOR FOR SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS DO CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>'TMP')
[...]

também produz um erro. Tentei variações de loop sobre um cursor:

BEGIN
    DECLARE s VARCHAR(128);
    DECLARE v_at_end INTEGER default 0;
    DECLARE not_found CONDITION FOR SQLSTATE '02000';
    DECLARE C1 CURSOR for
        SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS;
    DECLARE CONTINUE HANDLER FOR not_found  SET v_at_end = 1 ;

    OPEN C1;
    fetch_loop:
    LOOP
        FETCH FROM C1 INTO s;
        IF v_at_end <>0 THEN LEAVE fetch_loop; END IF;
        CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>s);
    END LOOP;
    CLOSE C1;
END
@

Mas também não funciona. Alguma pista, o que precisa ser feito para poder chamar ADMIN_REVALIDATE_DB_OBJECTS em um loop?

Acho que vi em algum lugar que há algum tipo de diferença semântica entre CHAR(n) FOR BIT DATAe BINARY(n), mas não consigo localizar onde estava. Alguma indicação?

Estou perguntando porque tenho um monte de colunas definidas como CHAR(16) FOR BIT DATAantes BINARY(16)existiam, e pensando em migrá-las gradativamente para BINARY(16). Estou curioso para saber se há alguma circunstância em que a migração de um lado de um relacionamento fk antes do outro causará problemas.

Estou procurando converter várias tabelas de log para particionamento de intervalo, o objetivo principal é reduzir o tamanho do banco de dados desanexando e arquivando dados históricos. Processo se parece com:

CALL SYSPROC.ADMIN_MOVE_TABLE('S','T1','', '', '', '', '',
'(ACTION_TIME) (STARTING FROM (''2000-01-01-00.00.00.000000'') ENDING AT (''2029-12-31-23.59.59.999999'') EVERY 1 YEAR)', '', 'COPY_USE_LOAD', 'MOVE' );

...

CALL SYSPROC.ADMIN_MOVE_TABLE('S','T120','', '', '', '', '',
'(ACTION_TIME) (STARTING FROM (''2000-01-01-00.00.00.000000'') ENDING AT (''2029-12-31-23.59.59.999999'') EVERY 1 YEAR)', '', 'COPY_USE_LOAD', 'MOVE' );

Por questões de simplicidade durante este teste, não fiz nada sobre o índice em cada tabela (pk + ts), eles permanecem no mesmo tablespace de antes. Todas as tabelas usam este tablespace para seus índices

Parece funcionar bem, embora eu receba vários avisos misteriosos. Para cada tabela eu recebo:

SQL0206N "STATSPROFTYPE" is not valid in the context where it is used.

e para algumas das tabelas temporárias (que pareciam ser tabelas com nomes entre aspas terminando com letras minúsculas), recebi outras reclamações sobre runstats.

Fiz alguns testes e as tabelas pareciam acessíveis.

Então eu separei partições antigas como:

for t in $(db2 -x "select rtrim(tabschema) || '.' || rtrim(tabname) from SYSCAT.DATAPARTITIONS where tabname like '%_LOG' group by tabschema, tabname having COUNT(datapartitionname) > 1"); do
    for p in part{0..18}; do 
        db2 "alter table $t detach partition $p into ${t}_$p"; 
        db2 "drop table ${t}_$p"; 
    done 
    # db2 "reorg table $t";
    db2 "runstats on table $t with distribution and sampled detailed indexes all"
done

Ainda assim, todas as tabelas são acessíveis, mas se eu consultar:

db2 "SELECT substr(tabschema,1,20), substr(tabname,1,60), substr(VALUE,1,10) FROM SYSTOOLS.ADMIN_MOVE_TABLE WHERE KEY='STATUS'"

Todas as tabelas têm um valor de CLEANUP. Deixei por algumas horas, não há atividade no banco de dados, mas as tabelas permanecem as mesmas. Em média, provavelmente removi 50% das linhas nessas tabelas, mas o tamanho de acordo com:

db2 "CALL GET_DBSIZE_INFO(?, ?, ?, -1)"
...
Parameter Name  : DATABASESIZE
Parameter Value : 769891516416 

não é reduzido.

Por falta de ideias, dei um loop nas tabelas e reorganizei cada tabela e todos os índices, mas isso não parece mudar nada.

É normal que as tabelas permaneçam nesse estado por um longo período de tempo? Ajudaria esperar pelo CLEANUP, antes de migrar a próxima tabela?

Estou brincando com docker e db2, mas estou tendo problemas quando tento executar comandos como usuário db2inst1 em um contêiner em execução. Eu inicio o contêiner como (é 1 linha, mas eu o divido para facilitar a leitura):

docker run -itd --name mydb2 --privileged=true -p 50000:50000 
  -e LICENSE=accept 
  -e DB2INST1_PASSWORD=pelle_paltnacke 
  --mount type=volume,dst=${backupdir},volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=${addr}\",volume-opt=device=:${device} 
  -v /etc/passwd:/etc/passwd 
  -v /etc/group:/etc/group 
  -v /opt/nya/users/db2inst1:/opt/nya/users/db2inst1 
  -v /home/system/db2fenc1/:/home/system/db2fenc1/ ibmcom/db2

Agora, se eu tentar fazer:

docker exec --user db2inst1 -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
unable to find user db2inst1: no matching entries in passwd file

Como root não há problema:

docker exec -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash

e também --user root funciona bem:

docker exec --user root -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash

Então eu tentei com o uid do arquivo passwd montado:

docker exec --user 422 -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash

/etc/passwd é legível para todos. De qualquer forma, usar o uid não me leva muito longe:

docker exec --user 422 -ti mydb2 bash -c "db2licm -l"
bash: db2licm: command not found

então eu tento com:

docker exec --user 422 -ti mydb2 bash -c "whoami; . ~db2inst1/sqllib/db2profile; 
db2licm -l"
db2inst1
bash: /opt/nya/users/db2inst1/sqllib/adm/db2licm: Permission denied

Este é apenas alguns comandos que executei para demonstrar o problema. Alguém tem uma explicação de por que o --user db2inst1 não é capaz de executá-los?

FWIW, tentei sem o nfs-mount, mas recebo o mesmo comportamento.

O contêiner em si parece estar funcionando bem. Se eu girar o contêiner como acima e:

#> docker exec -ti mydb2 bash
[root@0ee67959246f /]# mkdir -p /data/db/db2
[root@0ee67959246f /]# chown db2inst1:db2iadm1 /data/db/db2/
[root@0ee67959246f /]# su - db2inst1
[db2inst1@0ee67959246f ~]$ cd /data/backup/db2/wb11/MD000I11/
[db2inst1@0ee67959246f MD000I11]$ db2 "restore db MD000I11 incremental auto taken at 20220307141244 to /data/db/db2 into WD000I11"
DB20000I  The RESTORE DATABASE command completed successfully.

EDIT: Uma observação interessante é:

docker exec --user 422 -ti mydb2 bash -c "id"
uid=422(db2inst1) gid=0(root) groups=0(root)

docker exec --user 422:422 -ti mydb2 bash -c "id"
uid=422(db2inst1) gid=422(db2iadm1) groups=422(db2iadm1)


docker exec --user 422:422 -ti mydb2 bash -c "whoami; . 
~db2inst1/sqllib/db2profile; db2licm -l"

db2inst1
Product name:                     "DB2 Community Edition"
License type:                     "Community"
...

Infeliz:

docker exec --user db2inst1:db2iadm1 -ti mydb2 bash -c "id"
unable to find user db2inst1: no matching entries in passwd file

Acho que nunca refleti sobre isso, mas atualmente estou carregando uma tabela de um cursor e os utilitários de lista mostram:

  Phase Number               = 3
  Description                = BUILD
  Total Work                 = 46 indexes
  Completed Work             = 0 indexes
  Start Time                 = Not Started

No esquema atual, existem 4 índices + uma coluna XML (que parece contribuir com 2 de acordo com syscat.indexes). No começo eu pensei que poderia ser um bug contando índices para o mesmo nome de tabela em esquemas diferentes, mas isso também não conta, já que existem 10 esquemas com uma tabela com esse nome.

Estou apenas curioso o que o "Trabalho Total" significa para esta fase?

Estou pensando em mover algumas de nossas grandes tabelas de log para particionamento de intervalo para facilitar o arquivamento. Eles raramente são usados ​​para consultas, além de suporte e coisas relacionadas. Digamos que meus dados mais antigos sejam de 2013 e eu esteja usando 1 partição por ano. Que efeitos negativos isso terá se eu adicionar partições por alguns anos à frente (digamos até 2025)? Além disso, não há problema em usar uma coluna de carimbo de data/hora como chave de particionamento ou há alguma vantagem em usar uma coluna gerada para o ano?

Estou tentando usar o Access como front-end para um banco de dados SQL Server 2017. Os objetos que me interessam são 6 tabelas temporais e uma view unindo-as. Criei uma fonte de dados de usuário ODBC e vinculei as tabelas e a exibição. Para a exibição, criei um gatilho em vez de atualização que atualiza as tabelas subjacentes e funciona bem.

Como as chaves primárias das tabelas subjacentes são de identidade, imaginei que seria mais fácil inserir/excluir diretamente nas tabelas subjacentes em vez de por meio da exibição (precisei ao SET IDENTITY_INSERT ONmanipular a exibição via SQL).

Posso adicionar uma linha a uma das tabelas sem problemas, mas quando tento excluir ou atualizar uma linha na tabela, recebo um erro dizendo "Reserverat fel (-7776). Det finns inget meddelande för felet". Traduzido livremente, seria algo como "Erro reservado (-7776). Não há mensagem para o erro".

Eu visito o mundo do Windows regularmente a cada 20 anos ou mais, então não tenho nenhuma pista real sobre por onde começar a procurar pistas sobre qual pode ser o erro. Alguma percepção?

O engraçado é que se eu criar uma view que una duas das tabelas (a chave primária de uma das tabelas também é única na view), posso atualizar a view, e a tabela subjacente também é atualizada (não ao invés de trigger necessário).

Também é possível inserir uma nova linha (para excluir parece que vou precisar de um em vez de um gatilho). Então, acho que isso é uma solução alternativa, mas parece bastante estranho que eu possa atualizar a exibição, mas não a tabela.

Encontrei algumas anotações antigas minhas de 2011 e também reli o excelente artigo 10 Cool SQL Optimisations That Not Depend on the Cost Model de @lukas-eder. Então eu pensei em levar minhas notas para outra rodada. O cenário é bastante simples Fiddle

create table emp ( 
    emp_no int not null primary key, 
    title varchar(10) not null, 
    salary int not null, 
        check (emp_no > 0), 
        check (title in ('BOSS','WORK'))
);

insert into emp with recursive t (n) as (
    values (1) 
    union all 
    select n+1 from t where n+1 < 1000
) select n, case when mod(n,10) = 0 then 'BOSS' else 'WORK' end, 
            case when mod(n,10) = 0 then 110 else 0 end + mod(n,90) 
from t;

Agora, dadas as regras:

 (TITLE = BOSS) implies (SALARY > 100)

e

 (TITLE = WORK) implies (SALARY <= 100)

que pode ser implementado como:

-- (TITLE = BOSS) => (SALARY > 100)
alter table emp add constraint cc1 
    CHECK ( (title <> 'BOSS' OR salary > 100) );
-- (TITLE = WORK) => (SALARY <= 100)
alter table emp add constraint cc2
    CHECK ( (title <> 'WORK' OR salary <= 100) );

e a consulta:

select * 
from emp 
where title = 'BOSS' and salary <= 100

o DBMS pode detectar a contradição e retornar um conjunto de resultados vazio sem nem mesmo tocar nos dados?

Let A = ( title = ’BOSS’ ), B = ( salary > 100 )

select * from emp where (A ^ ~B)                    
select * from emp where (A ^ ~B) ^ (~A v B)           # by cc1 
select * from emp where (A ^ ~B ^ ~A) v (A ^ ~B ^ B)    
select * from emp where (FALSE ^ ~B) v (A ^ FALSE)      
select * from emp where (FALSE) v (FALSE)           
select * from emp where (FALSE)

Eu tentei o Postgres 13 (veja o violino acima)

Seq Scan on emp  (cost=0.00..26.50 rows=2 width=46) (actual time=0.134..0.134 rows=0 loops=1)
  Filter: ((salary <= 100) AND ((title)::text = 'BOSS'::text))
  Rows Removed by Filter: 999
Planning Time: 0.312 ms
Execution Time: 0.149 ms

e Db2 11.5.4.0:

Optimized Statement:
-------------------
SELECT 
  Q1.EMP_NO AS "EMP_NO",
  Q1.TITLE AS "TITLE",
  Q1.SALARY AS "SALARY" 
FROM 
  DB2INST1.EMP AS Q1 
WHERE 
  (Q1.SALARY <= 100) AND 
  (Q1.TITLE = 'BOSS')

Access Plan:
-----------
        Total Cost:             51.8267
        Query Degree:           1


      Rows 
     RETURN
     (   1)
      Cost 
       I/O 
       |
     90.2441 
     TBSCAN
     (   2)
     51.8267 
        4 
       |
       999 
 TABLE: DB2INST1
       EMP
       Q1

mas ambos não conseguem fazê-lo. Algum outro SGBD que possa identificar a contradição e agir sobre ela? É claro que isso é mais uma diversão do que um problema do mundo real, mas ainda assim.

Edit: A restrição sugerida por @federico-razzoli em sua resposta também não funciona:

alter table emp add constraint cc1
    check ((title = 'BOSS' and salary > 100) or 
           (title = 'WORK' AND salary <= 100));

e a mesma consulta ainda causa acesso à tabela

 Rows 
 RETURN
 (   1)
  Cost 
   I/O 
   |
 90.2441 
 TBSCAN
 (   2)
 51.8267 
    4 
   |
   999 

TABELA: DB2INST1 EMP Q1

Estou criando um script de backup/restauração para um pequeno banco de dados postgres 12.2, rodando dentro de um container docker. O backup se parece com:

docker exec -e PGPASSWORD=${passwd} ${container} \
   pg_dump -h ${host} -U ${username} ${db} \
   -Fc > ${backupdir}${db}_$(date +"%Y-%m-%d-%H.%M.%S.%N").pgdump

Em seguida, crio um novo banco de dados e tento restaurar nele como:

docker exec -i ${container} pg_restore -Fc --verbose --clean \
   --no-acl --no-owner -U ${username} \
   -d ${testdb} < ${backupdir}${db}_ ...

Isso parece funcionar para várias tabelas e, em seguida, congela em uma tabela específica, todas as vezes. Nada parece acontecer, embora o Postgres esteja usando 80% da CPU. Deixei funcionando por 10 horas sem terminar.

A tabela em questão contém ~ 1E6 linhas, uma tabela 3 vezes maior restaura em cerca de 10 segundos. A tabela contém uma coluna gerada:

CREATE TABLE MIND.FILER
( DOKUMENT_UUID UUID NOT NULL   -- document_uuid
, SIDNUMMER INTEGER NOT NULL    -- page number
, FILTYP TEXT NOT NULL          -- file type
, TILLSTAND SMALLINT NOT NULL   -- state 
, FILNAMN TEXT NOT NULL         -- name of file
, FULLSTANDIGT_FILNAMN TEXT GENERATED ALWAYS AS -- complete file name including path 
    (mind.uuid_2_path(dokument_uuid) || rtrim(filnamn)) STORED
,   CONSTRAINT PK_FILER PRIMARY KEY (DOKUMENT_UUID, SIDNUMMER, FILTYP)
,   CONSTRAINT FK_SIDOR
        FOREIGN KEY (DOKUMENT_UUID, SIDNUMMER)
            REFERENCES MIND.SIDOR (DOKUMENT_UUID, SIDNUMMER)
                ON DELETE CASCADE
                ON UPDATE CASCADE
,   CONSTRAINT FK_FILTYPER
        FOREIGN KEY (FILTYP)
            REFERENCES MIND.FILTYPER (FILTYP)
                ON DELETE CASCADE
                ON UPDATE CASCADE
);

mas tenho a impressão de que isso não deve afetar a restauração, pelo menos não nessa medida.

A função MIND.UUID_2_PATH localiza o ponto de montagem no sistema de arquivos, dependendo da versão do UUID utilizada.

CREATE OR REPLACE FUNCTION MIND.UUID_2_PATH(DUID UUID)
    RETURNS TEXT AS $$
    DECLARE s text;
    DECLARE ss text;
    DECLARE uuid_v int;
BEGIN
    SELECT substr(DUID::text,15,1) into uuid_v;
    IF uuid_v = 4 THEN
        SELECT REPLACE(CAST(DUID AS TEXT),'-','') INTO s;
        SELECT monteringspunkt
                  ||SUBSTR(s,1,4)||'/'
                  ||SUBSTR(s,5,4)||'/'
                  ||SUBSTR(s,9,4)||'/'
                  ||SUBSTR(s,13,4)||'/'
                  ||SUBSTR(s,17,4)||'/'
                  ||SUBSTR(s,21,4)||'/'
                  ||SUBSTR(s,25,4)||'/'
                  ||SUBSTR(s,29,4)||'/' INTO ss
        FROM mind.filsystemsmonteringar
        WHERE uuid_version = 4;
    ELSE -- uuid_v = 3
        SELECT lpad(dokument_id::text, 10,'0') into s FROM MIND.DOKUMENT where dokument_uuid = DUID;
        SELECT monteringspunkt
                  ||SUBSTR(s,1,3)||'/'
                  ||SUBSTR(s,4,3)||'/'
                  ||SUBSTR(s,7,2)||'/'
                  ||s||'/' INTO ss
        FROM mind.filsystemsmonteringar
        WHERE uuid_version = 3;
    END IF;
    RETURN ss;
end;
$$
LANGUAGE plpgsql
IMMUTABLE
RETURNS NULL ON NULL INPUT;

Pode não ser a maneira mais eficiente de fazer isso, mas carregar milhões de linhas na tabela usando \copy tem um desempenho decente.

De vez em quando aparecem entradas como:

2020-10-06 12:36:17.078 UTC [27] LOGG:  checkpoint starting: time
2020-10-06 12:38:47.123 UTC [27] LOGG:  checkpoint complete: wrote 689 buffers (4.2%); 0 WAL file(s) added, 0 removed, 10 recycled; write=149.943 s, sync=0.000 s, total=150.045 s; sync files=79, longest=0.000 s, average=0.000 s; distance=163338 kB, estimate=163338 kB
2020-10-06 12:41:17.223 UTC [27] LOGG:  checkpoint starting: time
2020-10-06 12:41:17.743 UTC [27] LOGG:  checkpoint complete: wrote 5 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.503 s, sync=0.013 s, total=0.519 s; sync files=4, longest=0.012 s, average=0.003 s; distance=369 kB, estimate=147041 kB

no registro. Pelo que posso dizer, nada foi feito com a configuração do Postgres. Eu tive que aumentar o shm, mas fora isso é baunilha simples. Não tenho certeza de quais áreas/configurações de memória podem melhorar o desempenho do pg_restore. Como você pode ver, sou novo no postgres (ser um imbecil no docker também não parece ajudar ;-). Portanto, quaisquer dicas sobre o que pode causar esse "congelamento" ou onde procurar mais informações serão apreciadas.

EDIT: com a ajuda que @laurenz-albe forneceu, eu poderia cancelar uma restauração mais antiga e voila a restauração restante foi concluída em minutos.

Em seguida, larguei o banco de dados, criei-o novamente e verifiquei a seguinte consulta que resultou em 0 linhas:

select pid, application_name, backend_start, state_change, backend_type 
from pg_stat_activity 
where datname = 'testdb';

Em seguida, iniciei uma nova restauração como antes e verifiquei a consulta novamente. O resultado é 1 back-end de cliente e 2 trabalhadores paralelos, os trabalhadores parecem reiniciar de vez em quando, mas a restauração parece travada.

Olhando para a consulta:

select backend_type, query 
from pg_stat_activity 
where datname = 'testdb';

mostra que:

client backend  | COPY mind.filer (dokument_uuid, sidnummer, filtyp, tillstand, filnamn) FROM stdin;         +
                 | 
 parallel worker | SELECT lpad(dokument_id::text, 10,'0')        FROM MIND.DOKUMENT where dokument_uuid = DUID
 parallel worker | SELECT lpad(dokument_id::text, 10,'0')        FROM MIND.DOKUMENT where dokument_uuid = DUID

então os trabalhadores estão executando uma consulta da função usada na coluna gerada. É possível que o pg_restore esteja se bloqueando devido à dependência de outra tabela?

É possível ter pg_restore virar a expressão gerada durante \copy? Fiquei com a impressão de que esse era o padrão afinal o valor já existe no dump.

Depois de matar os trabalhadores:

postgres=# select pg_cancel_backend(pid) 
    from pg_stat_activity 
    where datname = 'testdb' and backend_type = 'parallel worker';
 pg_cancel_backend 
-------------------
 t
 t
(2 rader)

A restauração continua, mas a tabela fica vazia após a restauração

Dado o seguinte cenário:

DB1:
EXPORT TO T.IXF OF IXF ... modified by codepage=... SELECT * FROM T;

DB2:
CREATE TABLE T (...) COMPRESS YES ADAPTIVE ORGANIZE BY ROW;
CREATE INDEX ... ON T (...) COMPRESS YES;
...
LOAD FROM T.IXF OF IXF INSERT INTO T (...);

Os índices são os mesmos no DB1 e no DB2, além de serem compactados no DB2, e a proporção do cluster parece boa no DB1 (não tenho certeza se isso importa). A página de código difere entre DB1 e DB2

Há algum ponto em fazer uma reorganização após o carregamento? Eu encontrei alguns artigos de Z que parecem sugerir que a maneira como os dados são exportados é importante (já que ZI não leu isso com atenção, então não sei se isso é mais relevante em Z e/ou LUW) .

Eu tentei em um número bastante grande de tabelas e fiz um REORGCHK após o carregamento e tudo parece bem. Comparando CALL GET_DBSIZE_INFO(?, ?, ?, 0)antes e depois do REORG mostra uma ligeira diminuição no tamanho (<1%), mas não sei se isso é uma coincidência.

Existe alguma situação específica em que um REORG seria benéfico após o carregamento em uma tabela vazia?

Este é apenas um exemplo bobo sobre o qual comecei a pensar, mas não consigo encontrar uma solução elegante. Assumindo uma tabela Calendar (vou usar a sintaxe do Db2):

create table calendar
( dt date not null primary key
);

insert into calendar (dt)
with t (dt) as ( values cast('2020-01-01' as date)
                 union all
                 select dt + 1 day from t where dt < '2020-01-11')
select dt from t                 
;

e uma mesa que contém o saldo:

create table balance 
( dt date not null
, amount int not null
,     primary key (dt)
);

insert into balance (dt, amount)
values ('2020-01-03',100) ,('2020-01-05', -50);

Se quisermos copiar o último saldo conhecido, podemos usar LAST_VALUE e 'IGNORE NULLS' como:

select c.dt, last_value(b.amount, 'IGNORE NULLS') over (order by c.dt)
from calendar c
left join balance b
    on c.dt = b.dt;

No entanto, se adicionarmos uma dimensão, digamos cid (customer_id), não será mais óbvio o que last_value significa. Normalmente particionamos por cid, mas cid é perdido devido à junção esquerda:

create table balance1 
( cid int not null
, dt date not null
, amount int not null
, primary key (cid, dt)
);

insert into balance1 (cid, dt, amount)
values (1, '2020-01-03',100) ,(1, '2020-01-05', -50)
     , (2, '2020-01-04',75), (2, '2020-01-08',55), (2, '2020-01-10', -35);


select c.dt, last_value(b.amount, 'IGNORE NULLS') over (partition by ? 
                                                        order by c.dt)
from calendar c
left join balance b
    on c.dt = b.dt;

O melhor que consegui foi usar um produto cartesiano entre calendário e clientes distintos de saldos:

select cid, dt, last_value(amount, 'IGNORE NULLS') over (partition by cid order by dt)
from (
  select cid, dt, amount from balance1
  union
  select distinct b.cid, c.dt, null 
  from balance1 b
  cross join calendar c
  where not exists (
    select 1 from balance1 
    where dt = c.dt and cid = b.cid
  )
) t  
order by dt, cid
;

Não é tão bonito, e estou procurando uma solução mais elegante. Eu usei a sintaxe do Db2 acima e neste Fiddle , mas é o princípio que procuro, então qualquer sintaxe de fornecedor servirá.

Um processo em lote executado pelo usuário U descarta e cria uma mesa de trabalho T. Configuração simplificada:

direitos para o usuário U

db2 grant dataaccess on database to user U
db2 grant all on table T to user U
db2 transfer ownership of table T to user U 

Como o código é chamado de vários lugares achei que seria legal largar e criar a tabela a partir de um procedimento P, para evitar que códigos diferentes criem looks diferentes para a tabela.

db2 -td@ -f "create procedure P()
   LANGUAGE SQL
   BEGIN
       BEGIN
           -- do nothing if drop table fails
           DECLARE CONTINUE HANDLER FOR SQLSTATE '42704'
           BEGIN
           END;
           execute immediate 'drop table T';
       END;
       execute immediate 'CREATE TABLE T (x int)';
END @"

No entanto, quando o usuário U chama esse procedimento, ele falha com:

db2 "call P()"
SQL0551N  The statement failed because the authorization ID does not have the 
required authorization or privilege to perform the operation.  Authorization 
ID: "U". Operation: "CREATE TABLE". Object: T SQLSTATE=42501

É possível conceder direitos ao usuário U (além de dbadm ou outras opções nucleares :) para que ele possa executar o procedimento P com sucesso?

Estou migrando vários bancos de dados para UTF-8 e acabei de descobrir fenômenos que não conhecia. Ao selecionar dados para o terminal, bytes adicionais são adicionados à saída. Exemplo:

~]$ x=$(db2 -x "values 'a'")
~]$ echo "${x}b"
a b

Um espaço adicional após um

~]$ x=$(db2 -x "values 'aa'")
echo "${x}b"
aa  b

Dois espaços adicionais após aa

Não parece importar quantos bytes um caractere ocupa em utf8:

~]$ x=$(db2 -x "values '?'")
~]$ echo "${x}b"
? b

Um espaço adicional após g-clave

~]$ x=$(db2 -x "values '??'")
~]$ echo "${x}b"
??  b

Dois espaços adicionais após a clave de sol

db cfg:

Database territory                                      = SE
Database code page                                      = 1208
Database code set                                       = UTF8
Database country/region code                            = 46
Database collating sequence                             = SYSTEM_819_SE

O terminal tem codificação UTF8 (tentei terminador e gnome-terminal), e antes de conectar ao banco de dados eu fiz:

export LC_CTYPE=sv_SE.utf8

O acima é, obviamente, apenas exemplos bobos, mas eu tenho uma boa quantidade de testes em scripts semelhantes a esse:

dbtype=`db2 -x "values nya.get_db_type()"`
if [ "${dbtype}" = "N" ]; then
    ...

onde eu preciso mudar o teste de uma forma ou de outra.

Alguma ideia sobre uma configuração que eliminaria os bytes extras?

~]$ uname -a
Linux nya-ladok3-release 3.10.0-1062.9.1.el7.x86_64 #1 SMP Mon Dec 2 08:31:54 EST 2019 x86_64 x86_64 x86_64 GNU/Linux
~]$ db2level
DB21085I  This instance or install (instance name, where applicable: 
"db2inst1") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/opt/ibm/db2/V11.5".

EDIT: demonstrei minha ignorância confundindo atributo com elemento, atualizei minha pergunta. Desculpe. Para esclarecer, estou procurando a existência do código do elemento em:

<conditionmessage:code>MYCODE</conditionmessage:code>

Eu tenho um monte de esquemas onde há uma tabela que contém uma coluna XML. Há alguns índices XML em cada coluna. Tenho certeza de que os esquemas XML diferem entre os esquemas SQL, no entanto, os mesmos índices XML existem em cada esquema. Suspeito copiar/colar e não consigo encontrar nenhuma documentação para os esquemas XML. Então, pensei em uma abordagem mais pragmática, ou seja, percorrer as colunas XML e verificar se cada elemento existe ou não. As tabelas já existem há algum tempo, então todos os elementos possíveis já devem estar lá.

Agora, a pergunta, qual é a melhor maneira de verificar a existência de um elemento, independentemente do valor? Infelizmente, meu cérebro é incompatível com XPATH/XQUERY, e tenho que lutar sempre para me convencer de que a consulta faz o que deveria fazer. Minha abordagem atual parece funcionar, mas estou curioso para saber se existe uma maneira melhor. A cardinalidade da menor tabela é ~ 100.000 linhas e a maior ~ 100.000.000 linhas:

import ibm_db
import ibm_db_dbi
...
conn = ibm_db_dbi.connect("...")
c1 = conn.cursor()

for schema in [ "S1", "S2", ... ]:
    for attribute in [ "a1", "s2", ...]:
        sql = f"""
            select * from {schema}.ATOM_ENTRY
            WHERE XMLEXISTS('$d//*:{attribute}[fn:matches(text(), $p, "i")]' 
                PASSING ENTRY_XML AS "d", CAST('\S*' AS VARCHAR(128)) as "p")
            fetch first 1 rows only
            optimize for 1 rows"""
        c1.execute(sql)
        exists = False
        for row in c1.fetchall():
            exists = True
        print(f"{schema}.ATOM_ENTRY -> {attribute} : {exists}")

Como parte de uma migração, criei um novo bufferpool - digamos BP8K - tamanho 8K e um tablespace usando esse bp e uma tabela nesse tablespace, que é carregada com dados. No entanto, recebo um:

 SQL1218N There are no pages currently available in bufferpool "4097"

durante esse processo. Olhando para db2topele, parece que o bufferpool padrão IBMSYSTEMBP8K é usado em vez de BP8K, o que explica o fenômeno.

Eu vi semelhante quando não há memória compartilhada suficiente para iniciar o bufferpool, mas neste caso BP8K aparece em ambos db2top, e db2pd -d ... -bufferpools. Também é possível alterar o tamanho do bp que, no caso de memória insuficiente, geralmente resulta em um aviso de que o bufferpool não foi iniciado.

A db2stop; db2startcorrige o problema, mas isso deveria ser realmente necessário? A migração é um script sql que é executado a partir de uma estrutura de atualização, então prefiro não adicionar algum gancho que force todos os aplicativos. Pensamentos?

db2level
DB21085I  This instance or install (instance name, where applicable: 
"db2inst1") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/opt/ibm/db2/V11.5".

db2licm -l
Product name:                     "DB2 Enterprise Server Edition"
License type:                     "Restricted"
Expiry date:                      "Permanent"
Product identifier:               "db2ese"
Version information:              "11.5"
Max amount of memory (GB):        "128"
Max number of cores:              "16"

cat /proc/meminfo 
MemTotal:       164759044 kB
MemFree:         4267032 kB
MemAvailable:   131089520 kB

Mark Barinstein me ajudou a determinar que o bufferpool não foi iniciado afinal:

ADM6073W  The table space "TBSPC8K" (ID "9") is configured to use 
          buffer pool ID "3", but this buffer pool is not active at this time. 
          In the interim the table space will use buffer pool ID "4097".

A maior parte da memória está configurada para AUTOMATICincluir o novo BP, então não sei por que não pode iniciá-lo. Há muita memória disponível no servidor, e o db está usando ~ 1,8 Gb (principalmente bufferpool), então não sei por que o Db2 não pode iniciar o novo bufferpool. Tentei adicionar um commit após a criação do bp, tbspace mas isso não ajudou.

A pergunta agora se torna: Por que o Db2 não pode iniciar este BP. De acordo com os documentos :

Se houver memória suficiente disponível, o conjunto de buffers poderá se tornar ativo imediatamente. Por padrão, novos conjuntos de buffers são criados usando a palavra-chave IMMEDIATE e, na maioria das plataformas, o gerenciador de banco de dados pode adquirir mais memória.

Parece haver muita memória disponível no servidor. O banco de dados alocou aproximadamente 1,8 Gb de memória antes de criar novos tablespaces. As instruções para a criação de bp se parecem com:

CREATE BUFFERPOOL BP8K SIZE AUTOMATIC PAGESIZE 8K @
CREATE BUFFERPOOL BP16K SIZE AUTOMATIC PAGESIZE 16K @
CREATE BUFFERPOOL BP32K SIZE AUTOMATIC PAGESIZE 32K @
CREATE LARGE TABLESPACE TBSPC8K PAGESIZE 8K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP8K @
CREATE LARGE TABLESPACE TBSPC16K PAGESIZE 16K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP16K @
CREATE LARGE TABLESPACE TBSPC32K PAGESIZE 32K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP32K @

Eu parei o script após a criação do bp, tbspace, forcei todos os aplicativos, depois executei o resto e funcionou bem. Não tenho essa impressão dos documentos, mas talvez isso tenha que ser feito.

Atualizei db cfg memory configde acordo com:

db2 update db cfg for <db> using SELF_TUNING_MEM ON
db2 update db cfg for <db> using DATABASE_MEMORY AUTOMATIC
db2 update db cfg for <db> using SORTHEAP AUTOMATIC
db2 update db cfg for <db> using SHEAPTHRES_SHR AUTOMATIC
db2 connect reset
db2 connect to <db>

e verifiquei que SEL_TUNING_MEMORYestava ativo:

db2 get db cfg for <db> show detail | grep SELF

mas continuo com o mesmo problema.

Depois de restaurar o banco de dados (ou seja, todas as configurações de memória), fiz um pequeno teste:

~]$ cat test.sh 
#!/bin/sh

OPTS=`getopt -o d:u:p: -- "$@"`
eval set -- "$OPTS"

user=""
passwd=""
while true ; do
    case "$1" in
        -d) db="$2"; shift 2;;
        -u) user="$2"; shift 2;;
        -p) passwd="$2"; shift 2;;
        --) shift; break;;
    esac
done

db2 connect to $db user $user using $passwd
if [ $? -ne 0 ]; then
    exit 1
fi

db2diag -A

db2 +c -td@ "BEGIN
  DECLARE EXIT HANDLER FOR SQLWARNING
    SIGNAL SQLSTATE '75001' SET MESSAGE_TEXT = 'The bufferpool BP8K is not allocated';

  EXECUTE IMMEDIATE 'CREATE BUFFERPOOL BP8K SIZE AUTOMATIC PAGESIZE 8K';
END
@"

db2 +c -td@ "BEGIN
  DECLARE EXIT HANDLER FOR SQLWARNING
    SIGNAL SQLSTATE '75001' SET MESSAGE_TEXT = 'The bufferpool BP8K is not allocated';

  EXECUTE IMMEDIATE 'CREATE LARGE TABLESPACE TBSPC8K PAGESIZE 8K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP8K';
END
"

db2 +c -td@ "BEGIN
  DECLARE EXIT HANDLER FOR SQLWARNING
    SIGNAL SQLSTATE '75001' SET MESSAGE_TEXT = 'The bufferpool BP8K is not allocated';

  EXECUTE IMMEDIATE 'COMMIT';
END
"

db2diag -A

Então fiz este teste:

db2diag: Moving "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log"
         to     "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log_2020-03-28-12.20.57"

DB20000I  The SQL command completed successfully.
DB20000I  The SQL command completed successfully.
DB20000I  The SQL command completed successfully.
db2diag: Moving "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log"
         to     "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log_2020-03-28-12.20.57"

então todas as 3 instruções sql foram bem-sucedidas, mas no diaglog eu encontro:

2020-03-28-12.20.57.162214+060 I1800E409             LEVEL: Event
PID     : 5301                 TID : 140165787223936 PROC : db2diag
INSTANCE: db2inst1             NODE : 000
HOSTNAME: gollum
FUNCTION: DB2 UDB, RAS/PD component, pdDiagArchiveDiagnosticLog, probe:88
CREATE  : DB2DIAG.LOG ARCHIVE : /opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log_2020-03-28-12.20.57 : success
IMPACT  : Potential

2020-03-28-12.20.57.228408+060 E2210E868             LEVEL: Warning
PID     : 17468                TID : 140189351536384 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : STUDERA
APPHDL  : 0-637                APPID: *LOCAL.db2inst1.200328112127
UOWID   : 1                    ACTID: 4
AUTHID  : DB2INST1             HOSTNAME: gollum
EDUID   : 2442                 EDUNAME: db2agent (STUDERA) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbAssignBufferPool, probe:2
MESSAGE : ADM6073W  The table space "TBSPC8K" (ID "9") is configured to use 
          buffer pool ID "3", but this buffer pool is not active at this time. 
          In the interim the table space will use buffer pool ID "4097".  The 
          inactive buffer pool should become available at next database startup 
          provided that the required memory is available.

2020-03-28-12.20.57.272773+060 I3079E557             LEVEL: Info
PID     : 17468                TID : 140189351536384 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : STUDERA
APPHDL  : 0-637                APPID: *LOCAL.db2inst1.200328112127
UOWID   : 1                    ACTID: 5
AUTHID  : DB2INST1             HOSTNAME: gollum
EDUID   : 2442                 EDUNAME: db2agent (STUDERA) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbCreateBufferPoolAct, probe:98
MESSAGE : Creating bufferpool "BP8K" Size: "1000"  <automatic>

Resumindo, não tenho a menor idéia de como detectar se o bufferpool foi iniciado ou não.

Confirmar cada instrução em test.sh(e também no meu script original) é bem-sucedido e não há entrada no diaglog. Apesar disso parecer resolver o problema, também adicionei um atraso após a criação de bufferpools:

CREATE BUFFERPOOL BP8K SIZE AUTOMATIC PAGESIZE 8K @

-- delay commit
BEGIN
    DECLARE now TIMESTAMP;
    DECLARE end TIMESTAMP;
    SET now = TIMESTAMP(GENERATE_UNIQUE());
    SET end = now + 5 seconds;
    WHILE (now < end) DO
        SET now = TIMESTAMP(GENERATE_UNIQUE());
    END WHILE;
END @

Esta é minha máquina de laboratório e não há praticamente nenhuma outra atividade nela.

Estou procurando compressão adaptativa. Não consigo encontrar nenhuma informação sobre como o HADR é afetado quando uma tabela é compactada e reorganizada. Exemplo

t=mytable
db2 "alter table $t compress yes adaptive";
for i in $(db2 -x "select rtrim(indschema) || '.' || rtrim(indname) from syscat.indexes where rtrim(tabschema) || '.' || rtrim(tabname) = '${t}' order by 1"); do
    db2 "alter index $i compress yes"
done

db2 "reorg table $t resetdictionary";
db2 "reorg indexes all for table $t"
db2 "runstats on table $t with distribution and sampled detailed indexes all";

A questão é se eu preciso desativar o HADR durante esse processo e reiniciá-lo assim que terminar, ou tudo é capturado no log, para que o HADR possa continuar?

Parece que apenas os primeiros n caracteres são usados ​​como colvalue para colunas varchar/vargraphic. Do meu teste abaixo, parece ser 33/16. O comprimento está documentado em algum lugar? Tentei pesquisar a documentação, mas não consigo encontrar nada (provavelmente procurando a coisa errada)

Caso de teste simples:

DROP TABLE LEJO0004.T;
CREATE TABLE LEJO0004.T (
        ID BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY 
            ( START WITH 1 INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 NO CYCLE CACHE 20 NO ORDER ),
        TCOL_C VARCHAR(64) NOT NULL,
        TCOL_G VARGRAPHIC(64) NOT NULL
);

insert into LEJO0004.T (tcol_c, tcol_g)
with n100 (n) as ( values 0 union all select n+1 from n100 where n<100 )
   , n10  (n) as ( values 0 union all select n+1 from n10 where n<10 )
   , n1   (n) as ( values 0 )
select 'commons.domain.regel.avbrottsregel'
     , 'commons.domain.regel.avbrottsregel'
from n100
union all
select 'commons.domain.regel.grupp.overfors.nya.endast.som.merit'
     , 'commons.domain.regel.grupp.overfors.nya.endast.som.merit'
from n10
union all
select 'commons.domain.regel.ingar.i.grupp.overfors.till.nya'
    ,  'commons.domain.regel.ingar.i.grupp.overfors.till.nya'
from n1;

runstats on table lejo0004.T with distribution on all columns;

select cast(colname as varchar(15))
    ,  type
    ,  seqno
    ,  cast(colvalue as varchar(40))
    ,  valcount
from sysstat.COLDIST
where tabschema = 'LEJO0004'
  and tabname = 'T'
  and colname in ('TCOL_C', 'TCOL_G')
  and colvalue is not null
  and type = 'F'
order by type, colname, seqno;

Resultado é:

TCOL_C  F 1 'commons.domain.regel.avbrottsrege' 101
TCOL_C  F 2 'commons.domain.regel.grupp.overfo'  11
TCOL_G  F 1 g'commons.domain.r'                 113

Parece ser o mesmo para Q

values char_length(g'commons.domain.r' using codeunits32)
16

values char_length('commons.domain.regel.avbrottsrege' using codeunits32)
33

Testado em:

db2level
DB21085I  This instance or install (instance name, where applicable: 
"lejo0004") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/home/lejo0004/sqllib".

Ao tentar responder Criar colunas de ID de inteiro a partir de colunas de string existentes (codificação de inteiro?) Descobri que eu precisava da minha própria versão do postgres para brincar. Eu já tinha uma versão decente do postgres instalada:

stack=# select version();
                                                version                         

--------------------------------------------------------------------------------
------------------------
 PostgreSQL 11.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (R
ed Hat 9.1.1-1), 64-bit

mas não tinha o módulo pgcrypto:

stack=# CREATE EXTENSION pgcrypto;
ERROR:  could not open extension control file "/usr/pgsql-11/share/extension/pgcrypto.control": No such file or directory

então eu instalei:

sudo dnf install postgresql-contrib 

mas ainda recebo o mesmo erro. Se eu olhar em:

]$ ls /usr/pgsql-11/share/extension/
plpgsql--1.0.sql  plpgsql.control  plpgsql--unpackaged--1.0.sql

Existe algum outro pacote que eu preciso instalar, ou estou faltando mais alguma coisa?

ATUALIZAR:

rpm -qa postgresql\* 
postgresql-contrib-11.3-1.fc30.x86_64 
postgresql11-11.4-1PGDG.f30.x86_64 
postgresql-11.3-1.fc30.x86_64 
postgresql11-server-11.4-1PGDG.f30.x86_64 
postgresql11-libs-11.4-1PGDG.f30.x86_64 

Eu recebo um erro para dnf install postgresql11-contrib:

[...] Falha ao sincronizar cache para repo 'fedora-modular' Erro: Falha ao sincronizar cache para repo 'fedora-modular'

pdgd parece ser o mais recente disponível:

rpm -qa | grep pgdg-fedora
pgdg-fedora-repo-42.0-4.noarch

ATUALIZAÇÃO2:

Aparentemente, algo estava temporariamente inativo, agora funcionou para:

sudo dnf install postgresql11-contrib
[...]
Downloading Packages:
postgresql11-contrib-11.4-1PGDG.f30.x86_64.rpm  285 kB/s | 602 kB     00:02    

rpm -qa postgresql\*
postgresql-contrib-11.3-1.fc30.x86_64
postgresql11-11.4-1PGDG.f30.x86_64
postgresql11-contrib-11.4-1PGDG.f30.x86_64
postgresql-11.3-1.fc30.x86_64
postgresql11-server-11.4-1PGDG.f30.x86_64
postgresql11-libs-11.4-1PGDG.f30.x86_64

stack=# CREATE EXTENSION pgcrypto;
CREATE EXTENSION