Potential bug.

[ruseinov]

After writing several records to the database I got flaky results when retrieving said records.

Steps to reproduce:

1. Reinstate this and try running several times

Version: 0.4.11

I use iter and iter_column_while to retrieve those keys from two different columns.

Here's a link to a failing CI job illustrating the issue: https://github.com/ChainSafe/forest/actions/runs/6485470422/job/17611617665.

[arkpar]

Column iterator may not observe recent commits. This is documented here:
https://github.com/paritytech/parity-db/blob/master/src/db.rs#L1022

Do you really need such guarantees?

[ruseinov]

Column iterator may not observe recent commits. This is documented here: https://github.com/paritytech/parity-db/blob/master/src/db.rs#L1022

Do you really need such guarantees?

It would be great to have such guarantees when testing, otherwise, it's pretty hard to verify results. I'm curious if this can somehow be fixed by using instrumentation feature.

[ruseinov]

Column iterator may not observe recent commits. This is documented here: https://github.com/paritytech/parity-db/blob/master/src/db.rs#L1022
Do you really need such guarantees?

It would be great to have such guarantees when testing, otherwise, it's pretty hard to verify results. I'm curious if this can somehow be fixed by using instrumentation feature.

I have tried a different approach for testing, which is to drop the database and reopen it. But it does not seem to work, because the condition in flush_worker does not let it flush when the shutdown signal has been received. Is this desired behaviour? Here's the code in question.

[arkpar]

Closing and reopening the database should have worked. kill_logs calls flush_logs on shutdown to process any remaining commits.

[arkpar]

Closing due to lack of details