Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
От | Amit Kapila |
---|---|
Тема | Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns |
Дата | |
Msg-id | CAA4eK1JyJL7dACPQ51hQmSz5KrxghmABr_J9AZbSGzSLW3Ghig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
|
Список | pgsql-hackers |
On Fri, Jul 8, 2022 at 12:46 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, Jul 8, 2022 at 3:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > 1. > > In ReorderBufferGetCatalogChangesXacts(), isn't it better to use the > > list length of 'catchange_txns' to allocate xids array? If we can do > > so, then we will save the need to repalloc as well. > > Since ReorderBufferGetcatalogChangesXacts() collects all ongoing > catalog modifying transactions, the length of the array could be > bigger than the one taken last time. We can start with the previous > length but I think we cannot remove the need for repalloc. > It is using the list "catchange_txns" to form xid array which shouldn't change for the duration of ReorderBufferGetCatalogChangesXacts(). Then the caller frees the xid array after its use. Next time in ReorderBufferGetCatalogChangesXacts(), the fresh allocation for xid array happens, so not sure why repalloc would be required? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: