Re: Replication slot stats misgivings
От | Amit Kapila |
---|---|
Тема | Re: Replication slot stats misgivings |
Дата | |
Msg-id | CAA4eK1JSbr0NN_OG=PgXY_AZ4Sh+nQpw49vrpZoKpM1q2UeTGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Replication slot stats misgivings (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Replication slot stats misgivings
|
Список | pgsql-hackers |
On Wed, Apr 28, 2021 at 12:49 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > BTW regarding the commit f5fc2f5b23 that added total_txns and > total_bytes, we add the reorder buffer size (i.g., rb->size) to > rb->totalBytes but I think we should use the transaction size (i.g., > txn->size) instead: > You are right about the problem but I think your proposed fix also won't work because txn->size always has current transaction size which will be top-transaction in the case when a transaction has multiple subtransactions. It won't include the subtxn->size. For example, you can try to decode with below kind of transaction: Begin; insert into t1 values(1); savepoint s1; insert into t1 values(2); savepoint s2; insert into t1 values(3); commit; I think we can fix it by keeping track of total_size in toptxn as we are doing for the streaming case in ReorderBufferChangeMemoryUpdate. We can probably do it for non-streaming cases as well. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: