The size of a database with big records becomes bigger after backup/restore #7627
Assignees
Comments
|
While I didn't verify it with tests, seems you right. |
Yes, I will prepare the PR. |
hvlad
added a commit
that referenced
this issue
Jun 16, 2023
Fix #7627: The size of the database with big records becomes bigger after backup/restore
hvlad
pushed a commit
that referenced
this issue
Jun 17, 2023
…fter backup/restore The problem appears when bulk inserts are used (currently during restore). Without the fix the primary data page is released if it has the dpg_large flag, and the new record is inserted on the next empty page. As a result, each primary page has only one record. Generally the fix solves an issue where per-relation cache of data page numbers is not working for tables with big records.
|
Fix is backported into v4 also, not sure about v3 yet. |
mrotteveel
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FB5 is affected. Seems like bulk inserts don't work correctly with big records. The problem is in locate_space() where the dpg_large flag is checked when the cached primary page number is used. The page is released if it has this flag, and the new record is inserted on the next empty page. As a result, each primary page has only one record. I would suggest to remove the dpg_large flag check from the locate_space(), and also from DPM_get() and DPM_next() because it prevents the cache of data page numbers to work. FB3 and FB4 don't have issues with the database size but the problem with cached page numbers is there and can be fixed the same way.
The text was updated successfully, but these errors were encountered: