Início / dba / Perguntas / 332867
Accepted
Labs
Asked: 2023-11-07 22:04:58 +0800 CST

Reverter uma transação se uma leitura retornar um valor diferente no momento da confirmação

  • 772

Quero um determinado comportamento para transações no Postgresql, mas não sei dizer se é possível. Eu descreveria esse comportamento como “Bloqueio de leitura otimista”, mas esse não parece ser o termo certo para isso.

Aqui está o comportamento que eu quero:

  1. Minha transação começa. Seu nível de isolamento de transação é “leitura repetível” ou “serializável”.
  2. Na transação eu li a linha A.
  3. Na transação, leio e escrevo mais um pouco, mas nunca atualizo a linha A.
  4. Tento confirmar a transação.

Agora preciso que a transação falhe, se a linha A tiver sido alterada por alguma outra transação durante o tempo de vida da minha transação. Se a linha A não foi alterada, desejo que a transação seja confirmada.

Existe uma maneira de fazer isso no Postgresql?

Minha abordagem alternativa seria atualizar a linha A com algum valor aleatório na minha transação, para forçar um conflito de gravação. No entanto, isso significaria muitos conflitos desnecessários, porque sem forçar conflitos, a linha A raramente seria atualizada, mas frequentemente lida.

postgresql

1 respostas

  1. Best Answer

    Você provavelmente está falando sobre uma situação como esta:

    CREATE TABLE events (
   event_id bigint PRIMARY KEY,
   ts timestamp with time zone NOT NULL
);

CREATE TABLE summary (
   summary_id bigint PRIMARY KEY,
   processed_until timestamp with time zone NOT NULL
);

INSERT INTO events VALUES
   (1, '2023-11-07 12:00:00+00'),
   (2, '2023-11-07 12:10:00+00');

    Agora a transação 1 resume os eventos:

    BEGIN ISOLATION LEVEL SERIALIZABLE;

SELECT max(ts) FROM events;

          max           
════════════════════════
 2023-11-07 12:10:00+00
(1 row)

INSERT INTO summary VALUES (100, '2023-11-07 12:10:00+00');

    Antes que a transação 1 possa ser confirmada, a transação 2 insere uma linha mais antiga:

    BEGIN ISOLATION LEVEL SERIALIZABLE;

INSERT INTO events VALUES (3, '2023-11-07 12:05:00+00');

COMMIT;

    E não haverá erro quando a transação 1 for confirmada.

    Uma solução possível é que a transação 2 leia a tabela de resumo após inserir a nova linha. Vejamos como isso funciona:

    Transação 1:

    BEGIN ISOLATION LEVEL SERIALIZABLE;

SELECT max(ts) FROM events;

          max           
════════════════════════
 2023-11-07 12:10:00+00
(1 row)

INSERT INTO summary VALUES (100, '2023-11-07 12:10:00+00');

    Transação 2:

    BEGIN ISOLATION LEVEL SERIALIZABLE;

INSERT INTO events VALUES (3, '2023-11-07 12:05:00+00');

-- check if everything is fine
SELECT summary_id FROM summary WHERE processed_until >= '2023-11-07 12:05:00+00';

 summary_id 
════════════
(0 rows)

COMMIT;

    Agora, quando a transação 1 for confirmada:

    COMMIT;
ERROR:  could not serialize access due to read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during commit attempt.
HINT:  The transaction might succeed if retried.

    Como a transação 2 olhou summarye não viu a linha de resumo, ela foi executada logicamente antes da transação 1. Mas como a transação 1 não viu seus resultados, ela foi executada logicamente antes da transação 2. Essa contradição causa o erro de serialização.

    Se a transação 2 encontrar uma summarylinha, ela estará em uma situação difícil e deverá reverter e descartar o novo valor ou tentar corrigir o resumo. Se isso não for uma opção, você terá que serializar verdadeiramente as operações com grandes bloqueios, o que não é muito atraente.

    • 0

relate perguntas