Re: pgsql: Implement streaming mode in ReorderBuffer.
От | Amit Kapila |
---|---|
Тема | Re: pgsql: Implement streaming mode in ReorderBuffer. |
Дата | |
Msg-id | CAA4eK1+f_Z7J52F0hrFgc1-Phnghk+v=eX9mgf7+GyR4sNN+bw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Implement streaming mode in ReorderBuffer. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Implement streaming mode in ReorderBuffer.
|
Список | pgsql-committers |
On Wed, Apr 28, 2021 at 5:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <akapila@postgresql.org> writes: > > Implement streaming mode in ReorderBuffer. > > I notice that new buildfarm member wrasse is unhappy about some of the > code added by this commit: > > "/export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/../pgsql/src/backend/replication/logical/reorderbuffer.c", line 2510:Warning: Likely null pointer dereference (*(curtxn+272)): ReorderBufferProcessTXN > > It's griping about this: > > curtxn->concurrent_abort = true; > > and I think it's got a point. There is little if any reason to have > confidence that curtxn must be non-NULL when this code is reached, > because it's in a PG_CATCH segment and there is a lot of code within > the PG_TRY that could throw an error before the spot where curtxn > is set. Not to mention that curtxn is set only conditionally. > > So I think > > if (curtxn) > curtxn->concurrent_abort = true; > > would be cheap insurance against a core dump. > We can do that to silence this Warning, otherwise, there won't be any problem because it is set only when we get a particular error code and we can get that error code only when the conditions that lead to curtxn being set are met. -- With Regards, Amit Kapila.
В списке pgsql-committers по дате отправления: