Skip to content

Conversation

@Avogar
Copy link
Member

@Avogar Avogar commented Nov 10, 2021

Changelog category (leave one):

  • Not for changelog (changelog entry is not required)

Move final flush from WriteBiffer's destructors to public method finalize so that it can be called explicitly. By now in some cases destructor of WriteBiffer could be called after the query has already been completed and data could be found in unfinished state and client will be unable to read this data for some time.

@robot-clickhouse robot-clickhouse added the pr-not-for-changelog This PR should not be mentioned in the changelog label Nov 10, 2021
@Avogar Avogar marked this pull request as draft November 10, 2021 23:19
Comment on lines 652 to 654
writer->flush();
write_buf->sync();
write_buf->finalize();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Avogar am I understand correctly that these hunk is a the fix (and mostly everything other is refactoring) since before it calls only WriteBuffer::next() which may leave some data?

BTW there is also commented StorageFileSink::flush, worth removing? -

// void flush() override
// {
// writer->flush();
// }

Copy link
Member Author

@Avogar Avogar Nov 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Avogar am I understand correctly that these hunk is a the fix (and mostly everything other is refactoring) since before it calls only WriteBuffer::next() which may leave some data?

Not only this change is the fix. In some WriteBuffers (for example LZMADeflatingWriteBuffer) final flush was performed only in destructor (not even in finalize method) and sometimes destructor could be called after query already been finished (for example in File, HDFS, S3 and URL engines, so I moved all flushes from destructors in finalize method so that we can flush final data explicitly (and it's also called in destructor if wasn't called explicitly)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW there is also commented StorageFileSink::flush, worth removing? -

Yep, thanks

@Avogar Avogar marked this pull request as ready for review November 15, 2021 18:43
@Avogar
Copy link
Member Author

Avogar commented Nov 15, 2021

Seems like error in perf test is related, will investigate


class WriteBuffer;

/// WriteBuffer that works with another WriteBuffer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment is needed why this decorator is needed/what is does.
Also maybe we can use more specific name, but I don't know which one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also maybe we can use more specific name, but I don't know which one.

I chose WriteBufferDecorator because we decorate data and write it to underlying buffer. But maybe we can use WriteBufferWithUnderlyingBuffer or WriteBufferWithNestedBuffer, what do you think?

@KochetovNicolai KochetovNicolai self-assigned this Nov 16, 2021
Copy link
Member

@KochetovNicolai KochetovNicolai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@azat
Copy link
Member

azat commented Nov 20, 2021

Can someone do a @mergify update to include #31004 into this PR? (I want to check one case)

@mergify
Copy link
Contributor

mergify bot commented Nov 20, 2021

@azat is not allowed to run commands

Hey, I reacted but my real name is @Mergifyio

@Avogar
Copy link
Member Author

Avogar commented Nov 22, 2021

@Mergifyio update

@mergify
Copy link
Contributor

mergify bot commented Nov 22, 2021

update

✅ Branch has been successfully updated

@Avogar
Copy link
Member Author

Avogar commented Nov 22, 2021

@Mergifyio update

@mergify
Copy link
Contributor

mergify bot commented Nov 22, 2021

update

✅ Branch has been successfully updated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr-not-for-changelog This PR should not be mentioned in the changelog

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants