Skip to content

Conversation

@danolivo
Copy link
Contributor

No description provided.

@danolivo danolivo requested a review from mason-sharp December 30, 2025 09:39
@danolivo danolivo self-assigned this Dec 30, 2025
@danolivo danolivo added the enhancement New feature or request label Dec 30, 2025
@danolivo danolivo marked this pull request as draft December 30, 2025 11:41
@danolivo danolivo marked this pull request as ready for review December 30, 2025 11:41
@mason-sharp mason-sharp requested a review from rasifr January 6, 2026 15:52
@mason-sharp
Copy link
Member

@danolivo Please rebase and also try to take care of the Codacy complaint (check if sizeof(sap) >= sizeof(SpockApplyProgress)? as an assertion?)

Shape the spock_group module a little:

* Remove unused lookup function.
* Make spock_group_foreach static, forasmuch as no one uses it outside
  the module.
* Add forgotten ‘extern’ declarations.
There are plenty of places where Spock touches shared memory structures that
may cause races. It is always an issue, even considering these structures are
rarely accessed for writing.

But the progress state is a high-frequency updated structure, and guarding it with a lock is critical.
After moving to HTAB implementation, we actually don't have a target
connection. So, remove it. While here, fix forgotten 'extern' declaration
in the 'spock_group.h' module.
In Spock 5, we used to employ a progress table and a transactional snapshot
to ensure that the progress corresponds to the replication slot
(snapshot, LSN), and we could request this state at any time until
the transaction ends.

With an HTAB, it's no longer true, and we need to invent extra hacks. With this
commit, we take the progress state right before LR slot creation, which is as
close as possible to the real state.

It is still not entirely consistent in the case of Z0DAN, but while we use it
just for information, it is ok.

XXX:
The code related to table syncing stays as is. Right now, we aren't sure if
the progress state needs to be corrected if we re-sync a single table from
the database. So, just keep the code untouched.
Use direct structure assignment instead of memcpy for copying
SpockApplyProgress. This is more idiomatic, type-safe, and resolves
static analyzer warnings about buffer size validation.

The compiler generates identical code while providing compile-time
type checking and better code clarity.
@danolivo
Copy link
Contributor Author

danolivo commented Jan 9, 2026

@danolivo Please rebase and also try to take care of the Codacy complaint (check if sizeof(sap) >= sizeof(SpockApplyProgress)? as an assertion?)

Done

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

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants