Início / dba / 问题

All perguntas(dba)

Martin Hope
machineghost
Asked: 2025-04-09 02:14:35 +0800 CST
  • 5

Estou tentando configurar o PostgreSQL em um novo computador (Linux Mint). Tudo funciona perfeitamente até eu tentar acessar o banco de dados. Quando o faço, como meu próprio usuário, recebo o seguinte erro (esperado):

$ psql 
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "me" does not exist

Isso faz sentido, porque no Linux há um postgresusuário separado com acesso ao banco de dados. Tentei usá-lo:

$ sudo su postgres
[sudo] password for me:
$ psql
Password for user postgres:  psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: fe_sendauth: no password supplied

Nesse ponto, fiquei confuso: o postgresusuário deveria ter acesso sem senha a todos os bancos de dados PostgreSQL. Além disso, tentei configurar meu pg_hba.confarquivo para permitir acesso local a todos os usuários:

# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

Entretanto, mesmo depois de reiniciar o PostgreSQL (com /etc/init.d/postgresql reload), ainda fui solicitado a fornecer uma senha de banco de dados para o usuário postgres.

Alguém pode me ajudar a entender:

  1. Por que estou sendo solicitado a digitar uma senha quando tento acessar meu banco de dados como postgresusuário (em uma nova instalação)?
  2. Por que ainda recebo a solicitação mesmo depois de definir conexões locais IPv4/IPv6 como trust?
  3. Como posso corrigir meu postgresusuário para que fique igual a outras máquinas Linux (ou seja, não tenha nenhuma senha de banco de dados, mas ainda consiga acessar todos os bancos de dados)?
postgresql
Martin Hope
Dolphin
Asked: 2025-04-08 18:14:48 +0800 CST
  • 6

Quero selecionar várias linhas no bloco de seleção do PostgreSQL. Então tentei usar a função row para fazer uma consulta no PostgreSQL 15 assim:

select c.a from ( select row(1 as a, 2 as b) as c)

mostra erro ERROR: syntax error at or near "as, eu também tentei:

select (c).a from ( select row(1 , 2 ) as c(a,b))

Estou esquecendo de alguma coisa? Ou como obter o valor da linha? Descobri que isso funciona bem:

select * from ( select row(1 , 2 ) ) a

Como conseguir o 1 ou o 2? Eu tentei:

select a[0] from ( select row(1 , 2 ) ) a

parece que não funcionou.

postgresql
Martin Hope
ErikEV
Asked: 2025-04-08 07:59:48 +0800 CST
  • 9

Introdução

Tenho lido muitos artigos sobre exclusão de bancos de dados e os perigos de usar o comando shrink. No entanto, tenho a oportunidade de mover um banco de dados para um novo servidor com uma grande janela de inatividade, então quero redefinir o banco de dados e reduzir seu tamanho (para aumentar o desempenho e economizar custos em um ambiente hospedado).

Fundo

  • O SQL Server existente é a Web Edition 2016.
  • Nova edição Standard do SQL Server 2022.
  • Tamanho do banco de dados ~120 GB.
  • Algumas tabelas grandes compõem a maior parte disso, assim como os índices nessas tabelas grandes.
  • Quero me concentrar apenas na redução do tamanho do banco de dados. Estou confortável com as outras partes da criação de um novo servidor.

Processo proposto

Antes da interrupção

  1. Execute procedimentos armazenados que usam DELETE FROMsintaxe. Eu os testei cuidadosamente. Eles agrupam as exclusões e serão executados ao longo de alguns dias.
  2. Monitore os arquivos de log e o disco de log para verificar se há espaço suficiente.
  3. Garanta que o processamento de exclusão seja concluído antes de chegarmos à janela de interrupção.

Durante a interrupção

  1. Faça um backup completo do banco de dados e coloque-o em um local seguro.
  2. Elimine os maiores índices (há cerca de 3 ou 4 que eu vou focar).
  3. Coloque o banco de dados no modo de recuperação simples.
  4. Reduza os arquivos de log e de banco de dados o máximo possível.
  5. Faça backup do banco de dados.
  6. Copie o arquivo de backup para o novo servidor.
  7. Restaurar o banco de dados para os locais de arquivo corretos
  8. Aplique os índices que foram removidos.
  9. Reconstrua todos os índices.
  10. Atualizar estatísticas.
  11. Retorne o banco de dados ao modelo de recuperação completa.
  12. Testando e reiniciando aplicativos
sql-server
Martin Hope
raphael
Asked: 2025-04-08 02:17:40 +0800 CST
  • 5

Estamos tentando combinar eventos com linhas com base na distância geográfica mais próxima

--pseudo code
LATERAL JOIN (
    SELECT line_id, geom 
    FROM lines 
    ORDER by distance(lines.geom, events.geom) 
    LIMIT 1) nearest_line

Às vezes, surpreendentemente, há empates. Queremos garantir que, se nosso pipeline de ETL for executado novamente com os mesmos conjuntos de dados, as mesmas linhas sejam retornadas. Uma ideia foi incluir line_idno ORDER BY, mas isso poderia distorcer nossa correspondência para valores mais baixos line_id. Existe alguma maneira de desfazermos os empates aleatoriamente, produzindo a mesma saída se nosso ETL tivesse que ser refeito nos mesmos conjuntos de dados?

Eu estava pensando em algo como, random()mas definir a semente com base em uma combinação de event_ide line_id. Algo como usar mod()nos IDs poderia ser... OK?

postgresql
Martin Hope
Jukurrpa
Asked: 2025-04-07 23:16:01 +0800 CST
  • 5

Executar a mesma consulta em duas tabelas que diferem apenas no número de linhas (~7,8M vs ~1,4M) resulta em dois planos diferentes, o que parece razoável. Mas a execução na tabela menor é de 4 a 5 vezes mais lenta e eu gostaria de entender o porquê.

As tabelas são definidas como estão:

   Column   |           Type           | Collation | Nullable | Default 
------------+--------------------------+-----------+----------+---------
 image_id   | bigint                   |           | not null | 
 h3_cell    | h3index                  |           | not null | 
 created_at | timestamp with time zone |           | not null | 
 location   | geometry(PointZ,4326)    |           | not null | 
Indexes:
    "images_a_pkey" PRIMARY KEY, btree (image_id)
    "images_a_created_at_idx" btree (created_at)
    "images_a_h3_cell_idx" btree (h3_cell)

A consulta é a seguinte

h3_cells AS (
    SELECT UNNEST(h3_linestring_to_cells(:line_string, 13, 1)) AS cell
)
SELECT COUNT(*)
FROM images
JOIN h3_cells hc ON images.h3_cell = hc.cell

A h3_linestring_to_cells()função retorna um array cujo h3indextamanho pode, em alguns casos, chegar a dezenas de milhares de valores. Nos exemplos abaixo, ele retorna cerca de 50.000.

Na tabela com 7,8 milhões de linhas, as entradas de plano e execução são as seguintes (valores da matriz redigidos para brevidade):

Aggregate  (cost=347404.47..347404.48 rows=1 width=8) (actual time=74.311..74.312 rows=1 loops=1)
  Buffers: shared hit=154681 read=328
  I/O Timings: shared read=1.362
  ->  Nested Loop  (cost=0.43..346724.23 rows=272093 width=0) (actual time=0.051..74.246 rows=833 loops=1)
        Buffers: shared hit=154681 read=328
        I/O Timings: shared read=1.362
        ->  ProjectSet  (cost=0.00..256.90 rows=51377 width=8) (actual time=0.002..4.113 rows=51377 loops=1)
              ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.000..0.001 rows=1 loops=1)
        ->  Index Only Scan using images_a_h3_cell_idx on images_a  (cost=0.43..6.68 rows=5 width=8) (actual time=0.001..0.001 rows=0 loops=51377)
              Index Cond: (h3_cell = (unnest('{...}'::h3index[])))
              Heap Fetches: 354
              Buffers: shared hit=154681 read=328
              I/O Timings: shared read=1.362
Planning Time: 139.421 ms
Execution Time: 74.345 ms

Enquanto na tabela menor de 1,4 milhões de linhas, o plano e a execução são estes:

Aggregate  (cost=105040.78..105040.79 rows=1 width=8) (actual time=327.586..327.587 rows=1 loops=1)
  Buffers: shared hit=148358 read=6315 written=41
  I/O Timings: shared read=26.521 write=0.327
  ->  Merge Join  (cost=4791.05..104802.14 rows=95455 width=0) (actual time=321.174..327.575 rows=118 loops=1)
        Merge Cond: (ptilmi.h3_cell = (unnest('{...}'::h3index[])))
        Buffers: shared hit=148358 read=6315 written=41
        I/O Timings: shared read=26.521 write=0.327
        ->  Index Only Scan using images_b_h3_cell_idx on images_b ptilmi  (cost=0.43..95041.10 rows=1415438 width=8) (actual time=0.026..245.897 rows=964987 loops=1)
              Heap Fetches: 469832
              Buffers: shared hit=148358 read=6315 written=41
              I/O Timings: shared read=26.521 write=0.327
        ->  Sort  (cost=4790.62..4919.07 rows=51377 width=8) (actual time=11.181..13.551 rows=51390 loops=1)
              Sort Key: (unnest('{...}'::h3index[]))
              Sort Method: quicksort  Memory: 1537kB
              ->  ProjectSet  (cost=0.00..256.90 rows=51377 width=8) (actual time=0.002..3.716 rows=51377 loops=1)
                    ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.000..0.001 rows=1 loops=1)
Planning Time: 146.617 ms
Execution Time: 327.626 ms

No caso de uma matriz de origem menor, por exemplo, de tamanho 25.000, o plano na tabela menor muda para o primeiro (loop aninhado) e seu tempo de execução se torna mais alinhado com as expectativas (mais rápido do que na tabela maior).

Não consigo entender o que desencadeia essa mudança de plano para um menos eficiente.

Observe que estou usando CTE+JOIN em vez de eg WHERE h3_cell = ANY(h3_linestring_to_cells(:line_string, 13, 1)), pois o array resultante costuma ser bem grande e descobri que o primeiro método costuma ser mais eficiente neste caso. Curiosamente, com um array de 50.000 entradas, a = ANY()abordagem é mais rápida na tabela menor; com 25.000, é mais lenta.

postgresql
Martin Hope
BotskoNet
Asked: 2025-04-07 13:32:09 +0800 CST
  • 6

Preciso de uma consulta que possa ser executada no banco de dados Postgres de um usuário e determinar se ele tem permissão para criar procedimentos/funções. Precisa ser uma consulta apenas porque se trata de uma verificação de inicialização do software que distribuo, e os usuários o conectam aos seus próprios bancos de dados, que às vezes são compartilhados e eles não têm permissões de procedimento.

Preciso de uma maneira somente SQL para determinar se eles têm a capacidade de usar CREATE FUNCTION. A documentação afirma que:

Para poder criar uma função, você deve ter privilégio USAGE nos tipos de argumento e no tipo de retorno.

Tentei usar este SQL, mas não tenho certeza se ele me dará algo útil.

SELECT * FROM information_schema.role_usage_grants 
WHERE grantee = 'postgres';

postgres    postgres    prism_v4    information_schema  cardinal_number DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  character_data  DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  sql_identifier  DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  time_stamp  DOMAIN  USAGE   YES
postgres    postgres    prism_v4    information_schema  yes_or_no   DOMAIN  USAGE   YES

No MySQL posso usar SHOW GRANTS FOR CURRENT_USER();e verificarCREATE_ROUTINE

postgresql
Martin Hope
Alex
Asked: 2025-04-06 16:45:49 +0800 CST
  • 7

Tenho um monte de propriedades (colunas no banco de dados) que devem ter um valor de string de uma lista de valores predefinidos, por exemplo active, inactive, pending.

Fora do banco de dados, que é javascript (deno+react no front-end), eu realmente quero tê-los como enumerações de strings, e não como inteiros, porque isso adiciona alguma clareza ao código e, na verdade, reduz a quantidade de código que você precisa escrever.

No banco de dados, tenho duas opções: armazená-los como estão (strings) ou smallintconvertê-los de/para strings durante a seleção/inserção no banco de dados.

O problema com a segunda opção é que ela requer uma transformação adicional no código e, ao usar o TypeScript, essa transformação não é tão direta quanto fazer um mapeamento simples, porque o ts não permite que você reatribua tipos diferentes a propriedades existentes, então você precisa copiar e fazer mais coisas...

De qualquer forma, eu só queria perguntar, quanto é o desempenho do postgres e/ou sobrecarga de tamanho se eu armazená-los diretamente como strings no banco de dados também, para eliminar a etapa de transformação? Imagino que cada registro cresceria em cerca de 20 bytes se eu mudasse de smallintpara texte isso teria algum tipo de efeito no desempenho? Além disso, essas colunas precisam ser indexadas, e isso adiciona outros 20 bytes para cada registro

postgresql
Martin Hope
Joel
Asked: 2025-04-05 05:01:50 +0800 CST
  • 6

Todas as tabelas e colunas do meu banco de dados usam o conjunto de caracteres utf8mb4 e a ordenação utf8mb4_unicode_ci. Gostaria de migrar para a ordenação utf8mb4_0900_ai_ci, mas usá-la convert toé inviável em minhas tabelas grandes, a menos que eu use gh-ost ou pt-osc.

Parece-me que isso convert tonão deveria ser necessário, visto que o conjunto de caracteres não muda, mas não consigo encontrar nenhuma documentação que confirme ou negue isso. Preciso usar convert toneste caso ou é alter table ... modify col ... collate ...suficiente?

Dei uma olhada em "Usando CONVERTER EM CONJUNTO DE CARACTERES para alterar apenas a ordenação?", que faz uma pergunta muito semelhante, mas a idade dessa pergunta torna as respostas um tanto obsoletas. Mesmo assim, uma resposta parece sugerir que isso convert toé desnecessário. A outra resposta se aprofunda na conversão de conjuntos de caracteres e no uso de pt-osc, o que eu gostaria de evitar.

mysql
Martin Hope
Daylon Hunt
Asked: 2025-04-05 02:56:29 +0800 CST
  • 7

Tenho duas consultas diferentes que preciso unir em UNION e, então, agregar cada grupo de tipo de taxa em uma tabela final. Para cada grupo de taxa (Rate_001mo, Rate_003mo, etc.)

SELECT EffectiveDate, 
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_001mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_003mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_006mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR012M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_012mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR024M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_024mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR036M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_036mo
FROM dbo.STAGING_FhlbRates WHERE EffectiveDate = '20250131'
group by EffectiveDate

UNION

SELECT EffectiveDate,
    SUM(CASE WHEN RateName = 'USOSFRA' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_001mo,
    SUM(CASE WHEN RateName = 'USOSFRC' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_003mo,
    SUM(CASE WHEN RateName = 'USOSFRF' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_006mo,
    SUM(CASE WHEN RateName = 'USOSFR1' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_012mo,
    SUM(CASE WHEN RateName = 'USOSFR2' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_024mo,
    SUM(CASE WHEN RateName = 'USOSFR3' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_036mo
    FROM dbo.STAGING_SofrOisRates WHERE EffectiveDate = '20250131'
    GROUP BY EffectiveDate

As colunas da tabela de resultados finais devem incluir a Data Efetiva e, em seguida, cada grupo de taxas (Taxa_001mês, Taxa_003mês, etc.)

aggregate
Martin Hope
Tomek Stankowski
Asked: 2025-04-05 01:07:06 +0800 CST
  • 7

Tenho um deadlock em 10.6.21-MariaDB-ubu2004. Aqui está meu esquema:

CREATE TABLE INT_CHANNEL_MESSAGE
(
    MESSAGE_ID       CHAR(36)     NOT NULL,
    GROUP_KEY        CHAR(36)     NOT NULL,
    CREATED_DATE     BIGINT       NOT NULL,
    MESSAGE_PRIORITY BIGINT,
    MESSAGE_SEQUENCE BIGINT       NOT NULL AUTO_INCREMENT UNIQUE,
    MESSAGE_BYTES    BLOB,
    REGION           VARCHAR(100) NOT NULL,
    PRIMARY KEY (REGION, GROUP_KEY, CREATED_DATE, MESSAGE_SEQUENCE)
) ENGINE = InnoDB;

CREATE INDEX INT_CHANNEL_MSG_DELETE_IDX ON INT_CHANNEL_MESSAGE (REGION, GROUP_KEY, MESSAGE_ID);

Inicialmente, tenho uma única linha na tabela. Vamos supor que os valores de cada linha sejam únicos, únicos REGIONe GROUP_KEYfixos.

A transação nº 1 insere duas linhas usando INSERTinstruções separadas:

INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)

A primeira inserção é executada, depois a transação trava. O nível de isolamento para a Transação nº 1 é REPEATABLE_READ(embora tenha tentado mudar para READ_COMMITED).

A transação nº 2 inicia imediatamente após a execução da primeira inserção (da transação nº 1) (é acionada pela aplicação). O nível de isolamento é definido como READ_COMMITED. A linha inicial é selecionada para atualização e, em seguida, a transação trava na DELETEchamada:

    SELECT INT_CHANNEL_MESSAGE.MESSAGE_ID, INT_CHANNEL_MESSAGE.MESSAGE_BYTES
    from INT_CHANNEL_MESSAGE
    where INT_CHANNEL_MESSAGE.GROUP_KEY = ? and INT_CHANNEL_MESSAGE.REGION = ?
order by CREATED_DATE, MESSAGE_SEQUENCE LIMIT 1 FOR UPDATE SKIP LOCKED

DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?

SHOW ENGINE INNODB STATUSsaída:

| InnoDB |      | 
=====================================
2025-04-04 16:06:44 0x7fc6241b3700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 21 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 0 srv_active, 0 srv_shutdown, 2376 srv_idle
srv_master_thread log flush and writes: 2376
----------
SEMAPHORES
----------
------------
TRANSACTIONS
------------
Trx id counter 1646
Purge done for trx's n:o < 1646 undo n:o < 0 state: running
History list length 2
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 1643, ACTIVE 31 sec
2 lock struct(s), heap size 1128, 1 row lock(s), undo log entries 1
MariaDB thread id 76, OS thread handle 140489014748928, query id 8535 172.21.0.1 nbs 
---TRANSACTION 1640, ACTIVE 31 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 1
MariaDB thread id 75, OS thread handle 140488995890944, query id 8537 172.21.0.1 nbs Updating
SET STATEMENT SQL_SELECT_LIMIT=1 FOR DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID='ce0ce618-2430-0b4c-727b-7250e5388f15' and GROUP_KEY='cb18446f-633c-3a46-b5ac-95ab539126d1' and REGION='DEFAULT'
------- TRX HAS BEEN WAITING 31293172 us FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 3 n bits 320 index PRIMARY of table `nbs_biometric`.`INT_CHANNEL_MESSAGE` trx id 1640 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
 0: len 7; hex 44454641554c54; asc DEFAULT;;
 1: len 30; hex 63623138343436662d363333632d336134362d623561632d393561623533; asc cb18446f-633c-3a46-b5ac-95ab53; (total 36 bytes);
 2: len 8; hex 80000196018d82b2; asc         ;;
 3: len 8; hex 8000000000000012; asc         ;;
 4: len 6; hex 00000000066b; asc      k;;
 5: len 7; hex bf000001410110; asc     A  ;;
 6: len 30; hex 63623533326436662d343362352d393164352d636561612d623965616434; asc cb532d6f-43b5-91d5-ceaa-b9ead4; (total 36 bytes);
 7: SQL NULL;
 8: len 30; hex aced0005737200346f72672e737072696e676672616d65776f726b2e6d65; asc     sr 4org.springframework.me; (total 1252 bytes);

------------------
---TRANSACTION (0x7fc6388d7180), not started
0 lock struct(s), heap size 1128, 0 row lock(s)
--------
FILE I/O
--------
Pending flushes (fsync) log: 0; buffer pool: 0
166 OS file reads, 332 OS file writes, 594 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 891776
Log flushed up to   891776
Pages flushed up to 42676
Last checkpoint at  42664
0 pending log flushes, 0 pending chkp writes
334 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 167772160
Dictionary memory allocated 931712
Buffer pool size   8112
Free buffers       7349
Database pages     763
Old database pages 261
Modified db pages  621
Percent of dirty pages(LRU & free pages): 7.654
Max dirty pages percent: 90.000
Pending reads 0
Pending writes: LRU 0, flush list 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 152, created 611, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 763, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 read views open inside InnoDB
Process ID=0, Main thread ID=0, state: sleeping
Number of rows inserted 63, updated 0, deleted 18, read 1182
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
 |

O deadlock não ocorre quando a Transação nº 1 insere uma única linha. Como posso evitar isso?

Estou anexando logs do aplicativo para um contexto mais amplo:

2025-04-04 18:06:13,426 [tx1]: TX START
2025-04-04 18:06:13,426 [tx1]: Executing prepared SQL update
2025-04-04 18:06:13,426 [tx1]: Executing prepared SQL statement [INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)
]
2025-04-04 18:06:13,427 [tx2]: Executing prepared SQL query
2025-04-04 18:06:13,427 [tx2]: Executing prepared SQL statement [   SELECT INT_CHANNEL_MESSAGE.MESSAGE_ID, INT_CHANNEL_MESSAGE.MESSAGE_BYTES
    from INT_CHANNEL_MESSAGE
    where INT_CHANNEL_MESSAGE.GROUP_KEY = ? and INT_CHANNEL_MESSAGE.REGION = ?
order by CREATED_DATE, MESSAGE_SEQUENCE LIMIT 1 FOR UPDATE SKIP LOCKED]
2025-04-04 18:06:13,429 [tx2]: Executing prepared SQL update
2025-04-04 18:06:13,429 [tx2]: Executing prepared SQL statement [DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?]
2025-04-04 18:07:03,430  [tx2]: Error: 1205-HY000: Lock wait timeout exceeded; try restarting transaction
2025-04-04 18:07:03,432 [tx2]: Extracted SQL state class 'HY' from value 'HY000'
2025-04-04 18:07:03,434 [tx1]: Executing prepared SQL update
2025-04-04 18:07:03,434 [tx1]: Executing prepared SQL statement [INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)
]
2025-04-04 18:07:03,435 [tx2]: Resetting isolation level of JDBC Connection [HikariProxyConnection@1449683964 wrapping org.mariadb.jdbc.Connection@5b1420f9] to 4
2025-04-04 18:07:03,436  [tx1]: TX END
mariadb
Próximo