Re: logical decoding : exceeded maxAllocatedDescs for .spill files - Mailing list pgsql-hackers
From | Amit Khandekar |
---|---|
Subject | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Date | |
Msg-id | CAJ3gD9e_5Uee6x36EwNEzGje4n_3iYmA3XbRvtmEBHmt8N7ZMA@mail.gmail.com Whole thread Raw |
In response to | Re: logical decoding : exceeded maxAllocatedDescs for .spill files (Amit Kapila <amit.kapila16@gmail.com>) |
Responses |
Re: logical decoding : exceeded maxAllocatedDescs for .spill files
|
List | pgsql-hackers |
On Sat, 14 Dec 2019 at 11:59, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Dec 12, 2019 at 9:50 PM Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > > > > Attached is a v4 patch that also addresses your code comments so far. > > I have included the test case in 006_logical_decoding.pl. I observed > > that the test case just adds only about 0.5 to 1 sec time. Please > > verify on your env also, and also whether the test reproduces the > > issue without the code changes. > > > > It takes roughly the same time on my machine as well. I have checked > on Windows as well, it increases the time from 14 to 16 (17) seconds > for this test. I don't think this is any big increase considering the > timing of other tests and it would be good to have a test for such > boundary conditions. I have slightly change the comments in the patch > and ran pgindent. Attached, find the patch with a proposed commit > message. > > I have also made minor changes related to below code in patch: > - else if (readBytes != sizeof(ReorderBufferDiskChange)) > + > + file->curOffset += readBytes; > + > + if (readBytes != > sizeof(ReorderBufferDiskChange)) > > Why the size is added before the error check? The logic was : even though it's an error that the readBytes does not match the expected size, the file read is successful so update the vfd offset as early as possible. In our case, this might not matter much, but who knows, in the future, in the exception block (say, in ReorderBufferIterTXNFinish, someone assumes that the file offset is correct and does something with that, then we will get in trouble, although I agree that it's very unlikely. But IMO, because we want to simulate the file offset support in vfd, we should update the file offset immediately after a file read is known to have succeeded. > I think it should be > after that check, so changed accordingly. Similarly, I don't see why > we need to change 'else if' to 'if' in this code, so changed back. Since for adding the size before the error check I had to remove the else-if, so to be consistent, I removed the else-if at surrounding places also. > > I think we need to change/tweak the test for back branches as there we > don't have logical_decoding_work_mem. Can you please look into that Yeah, I believe we need to backport up to PG 9.4 where logical decoding was introduced, so I am first trying out with 9.4 branch. > and see if you can run perltidy for the test file. Hmm, I tried perltidy, and it seems to mostly add a space after ( and a space before ) if there's already; so "('postgres'," is replaced by "(<space> 'postgres',". And this is going to be inconsistent with other places. And it replaces tab with spaces. Do you think we should try perltidy, or have we before been using this tool for the tap tests ? -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
pgsql-hackers by date: