Re: logical decoding and replication of sequences

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: logical decoding and replication of sequences
Дата
Msg-id ae3cab67-c31e-b527-dd73-08f196999ad4@enterprisedb.com
обсуждение исходный текст
Ответ на Re: logical decoding and replication of sequences  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: logical decoding and replication of sequences  (Amit Kapila <amit.kapila16@gmail.com>)
Re: logical decoding and replication of sequences  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Re: logical decoding and replication of sequences  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Hi,

here's an updated version of the patches, dealing with almost all of the
issues (at least in the 0001 and 0002 parts). The main changes:

1) I've removed the  'created' flag from fill_seq_with_data, as
discussed. I don't think it's needed by any of the parts (not even 0003,
AFAICS). We still need it in xl_seq_rec, though.

2) GetCurrentTransactionId() added to sequence.c are called only with
wal_level=logical, to minimize the overhead.


There's still one remaining problem, that I already explained in [1].
The problem is that with this:

  BEGIN;
  SELECT nextval('s') FROM generate_series(1,100);
  ROLLBACK;


The root cause is that pg_current_wal_lsn() uses the LogwrtResult.Write,
which is updated by XLogFlush() - but only in RecordTransactionCommit.
Which makes sense, because only the committed stuff is "visible".

But the non-transactional behavior of sequence decoding disagrees with
this, because now some of the changes from aborted transactions may be
replicated. Which means the wait_for_catchup() ends up not waiting for
the sequence change to be replicated. This is an issue for tests in
patch 0003, at least.

My concern is this actually affects other places waiting for things
getting replicated :-/

I have outlined some ideas how to deal with this in [1], but we got
sidetracked by exploring the alternative approach.


regards


[1]
https://www.postgresql.org/message-id/3d6df331-5532-6848-eb45-344b265e0238%40enterprisedb.com

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Adding CI to our tree
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set