Re: logical decoding and replication of sequences, take 2
От | Amit Kapila |
---|---|
Тема | Re: logical decoding and replication of sequences, take 2 |
Дата | |
Msg-id | CAA4eK1J-r8Y00CYn6WT4vexZbG5OandDrm5gcb+9Y_CCKVUkag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical decoding and replication of sequences, take 2 (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: logical decoding and replication of sequences, take 2
|
Список | pgsql-hackers |
On Thu, Dec 14, 2023 at 9:14 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > On Thu, Dec 14, 2023 at 2:51 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > It can only be cleaned if we process it but xact_decode won't allow us > > to process it and I don't think it would be a good idea to add another > > hack for sequences here. See below code: > > > > xact_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf) > > { > > SnapBuild *builder = ctx->snapshot_builder; > > ReorderBuffer *reorder = ctx->reorder; > > XLogReaderState *r = buf->record; > > uint8 info = XLogRecGetInfo(r) & XLOG_XACT_OPMASK; > > > > /* > > * If the snapshot isn't yet fully built, we cannot decode anything, so > > * bail out. > > */ > > if (SnapBuildCurrentState(builder) < SNAPBUILD_FULL_SNAPSHOT) > > return; > > That may be true for a transaction which is decoded, but I think all > the transactions which are added to ReorderBuffer should be cleaned up > once they have been processed irrespective of whether they are > decoded/sent downstream or not. In this case I see the sequence hash > being cleaned up for the sequence related transaction in Hayato's > reproducer. > It was because the test you are using was not designed to show the problem I mentioned. In this case, the rollback was after a full snapshot state was reached. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: