Re: Reducing the chunk header sizes on all memory context types
От | Amit Kapila |
---|---|
Тема | Re: Reducing the chunk header sizes on all memory context types |
Дата | |
Msg-id | CAA4eK1LGx6WW4UPn5-h4KhRCP_NLbNih+si1vpA6KU8TvHgung@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reducing the chunk header sizes on all memory context types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reducing the chunk header sizes on all memory context types
Re: Reducing the chunk header sizes on all memory context types |
Список | pgsql-hackers |
On Mon, Aug 29, 2022 at 7:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.com> writes: > > I suspect, going by all 3 failing animals being 32-bit which have a > > MAXIMUM_ALIGNOF 8 and SIZEOF_SIZE_T of 4 that this is due to the lack > > of padding in the MemoryChunk struct. > > AllocChunkData and GenerationChunk had padding to account for > > sizeof(Size) being 4 and sizeof(void *) being 8, I didn't add that to > > MemoryChunk, so I'll do that now. > > Doesn't seem to have fixed it. IMO, the fact that we can get through > core regression tests and pg_upgrade is a strong indicator that > there's not anything fundamentally wrong with memory context > management. I'm inclined to think the problem is in d2169c9985, > instead ... though I can't see anything wrong with it. > Yeah, I also thought that way but couldn't find a reason. I think if David is able to reproduce it on one of his systems then he can try locally reverting both the commits one by one. > Another possibility is that there's a pre-existing bug in the > logical decoding stuff that your changes accidentally exposed. > Yeah, this is another possibility. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: