8000 Clean duplicated code and some typos by hyongtao-db · Pull Request #112 · sraoss/pg_ivm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Clean duplicated code and some typos #112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Feb 12, 2025
Merged

Clean duplicated code and some typos #112

merged 10 commits into from
Feb 12, 2025

Conversation

hyongtao-db
Copy link
Contributor
@hyongtao-db hyongtao-db commented Dec 24, 2024

Long log:

  • The 47th and 53rd lines in pg_imv.h are duplicated, and one of them can be removed.
  • Fix some typos.
  • Fix different input orders for the function apply_new_delta_with_count‘s declaration and definition.

Signed-off-by: Yongtao Huang yongtaoh2022@gmail.com

Long log:

The 47th and 53rd lines are duplicated, and one of them can be deleted.

Signed-off-by: Yongtao Huang <yongtaoh@gmail.com>
Fix typo, `a IMMV` -> 'an IMMV'
Fix typo, `a IVM` -> `an IVM`
@hyongtao-db hyongtao-db changed the title Update pg_ivm.h Clean some duplicated code and some typos Dec 24, 2024
@hyongtao-db hyongtao-db changed the title Clean some duplicated code and some typos Clean duplicated code and some typos Dec 24, 2024
Fix some typos in README.md

Signed-off-by: Yongtao Huang <yongtaoh2022@gmail.com>
@@ -257,7 +257,7 @@ When a base table is truncated, the IMMV is also truncated and the contents beco

### Concurrent Transactions

Suppose an IMMV is defined on two base tables and each table was modified in different a concurrent transaction simultaneously. In the transaction which was committed first, the IMMV can be updated considering only the change which happened in this transaction. On the other hand, in order to update the IMMV correctly in the transaction which was committed later, we need to know the changes occurred in both transactions. For this reason, `ExclusiveLock` is held on an IMMV immediately after a base table is modified in `READ COMMITTED` mode to make sure that the IMMV is updated in the latter transaction after the former transaction is committed. In `REPEATABLE READ` or `SERIALIZABLE` mode, an error is raised immediately if lock acquisition fails because any changes which occurred in other transactions are not be visible in these modes and IMMV cannot be updated correctly in such situations. However, as an exception if the IMMV has only one base table and doesn't use DISTINCT or GROUP BY, and the table is modified by `INSERT`, then the lock held on the IMMV is `RowExclusiveLock`.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This sentence is too long, I'm afraid you may find it difficult to notice where I changed it.

are not be visible

Remove be.

`refesh_immv` should be `refresh_immv`
…ation and definition

- declaration: apply_new_delta_with_count(... StringInfo target_list, StringInfo aggs_set, ...)
- definition: apply_new_delta_with_count(... StringInfo aggs_set, StringInfo target_list, ...)

the input order is different.
@yugo-n
Copy link
Collaborator
yugo-n commented Feb 12, 2025

I am sorry for my late response and thank you so much for your checks and fixes of types in details!

@hyongtao-db
Copy link
Contributor Author

I am sorry for my late response and thank you so much for your checks and fixes of types in details!

Thanks for your work. It is my pleasure.

@yugo-n yugo-n merged commit 094add9 into sraoss:main Feb 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0