Skip to content

Conversation

@ilya071294
Copy link
Contributor

VIO_writelock creates new_rpb by copying from org_rpb which has rpb_delta flag set. new_rpb is passed to prepare_update. It creates a delta but its size exceeds the limit (1024) so the current version is stored as a regular record. The problem is that rpb_delta flag remains set for new_rpb, and then replace_record sets it in the header of the primary version. From this moment any attempt to get data of older versions fails.
The fix is to let prepare_update clear rpb_delta flag from new_rpb just before an attempt to generate a delta.

…hen WITH LOCK clause is used

VIO_writelock creates new_rpb by copying from org_rpb which has rpb_delta flag set. new_rpb is passed to prepare_update. It creates a delta but its size exceeds the limit (1024) so the current version is stored as a regular record. The problem is that rpb_delta flag remains set for new_rpb, and then replace_record sets it in the header of the primary version. From this moment any attempt to get data of older versions fails.
@ilya071294 ilya071294 requested a review from hvlad November 16, 2025 08:00
@ilya071294 ilya071294 self-assigned this Nov 16, 2025
Copy link
Member

@hvlad hvlad left a comment

Choose a reason for hiding this comment

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

Looks ok.

To be completely sure: have you considered to change VIO_writelock() instead ?
What about other flags, copied from old record (rpb_incomplete, for example) ?

@ilya071294
Copy link
Contributor Author

To be completely sure: have you considered to change VIO_writelock() instead ?

Yes, but that leaves open the possibility of facing a similar bug again, so I see it as a worse solution.

What about other flags, copied from old record (rpb_incomplete, for example) ?

I thought about it and came to this logic: if prepare_update determines how the backversion is stored then it should have full control over rpb_delta flag. It doesn't do anything else with new_rpb, so it should not care about other flags. The caller should. And both VIO_writelock and VIO_modify handle other flags correctly as I can see.

@ilya071294 ilya071294 merged commit 937a512 into FirebirdSQL:master Nov 17, 2025
21 of 23 checks passed
@ilya071294 ilya071294 deleted the fb_master_delta_fix_8799 branch November 17, 2025 12:21
ilya071294 added a commit that referenced this pull request Nov 17, 2025
…CK clause is used (#8803)

VIO_writelock creates new_rpb by copying from org_rpb which has rpb_delta flag set. new_rpb is passed to prepare_update. It creates a delta but its size exceeds the limit (1024) so the current version is stored as a regular record. The problem is that rpb_delta flag remains set for new_rpb, and then replace_record sets it in the header of the primary version. From this moment any attempt to get data of older versions fails.
ilya071294 added a commit that referenced this pull request Nov 17, 2025
…CK clause is used (#8803)

VIO_writelock creates new_rpb by copying from org_rpb which has rpb_delta flag set. new_rpb is passed to prepare_update. It creates a delta but its size exceeds the limit (1024) so the current version is stored as a regular record. The problem is that rpb_delta flag remains set for new_rpb, and then replace_record sets it in the header of the primary version. From this moment any attempt to get data of older versions fails.
ilya071294 added a commit that referenced this pull request Nov 17, 2025
…CK clause is used (#8803)

VIO_writelock creates new_rpb by copying from org_rpb which has rpb_delta flag set. new_rpb is passed to prepare_update. It creates a delta but its size exceeds the limit (1024) so the current version is stored as a regular record. The problem is that rpb_delta flag remains set for new_rpb, and then replace_record sets it in the header of the primary version. From this moment any attempt to get data of older versions fails.
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.

BUGCHECK "decompression overran buffer (179)" when WITH LOCK clause is used

2 participants