feat(dao): support diff transaction

[chronolaw]

Summary

KAG-3258
Target PR: #13157

Checklist

• The Pull Request has tests
• A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
• There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

Fix #[issue number]

[dndx]

The get_latest_version function need to be made transactional safe as well by returning MAX(version), as in case of transaction rollback, the pg_get_serial_sequence('clustering_sync_version', 'version') function will return a version number that does not exist, and cause issues in the DP.

[chronolaw]

The get_latest_version function need to be made transactional safe as well by returning MAX(version), as in case of transaction rollback, the pg_get_serial_sequence('clustering_sync_version', 'version') function will return a version number that does not exist, and cause issues in the DP.

I think we already rollbacked the insert operation of "clustering_sync_version" (INSERT INTO clustering_sync_version DEFAULT VALUES RETURNING version INTO new_version;), is it not enough?

And the function max() can not be applied to the pg_get_serial_sequence('clustering_sync_version', 'version') since it is a serial name (string type).

[dndx]

@chronolaw I do not believe this is safe, as sequences can not be rolled back due to concurrent transaction could be happening while this transaction is active. So in this case, we should apply max on the version field, not the sequence.

See: https://stackoverflow.com/questions/2095917/sequences-not-affected-by-transactions

[chronolaw]

@chronolaw I do not believe this is safe, as sequences can not be rolled back due to concurrent transaction could be happening while this transaction is active. So in this case, we should apply max on the version field, not the sequence.

See: https://stackoverflow.com/questions/2095917/sequences-not-affected-by-transactions

Done.
Since version is already a primary key, I think that postgres will create a index for it automaticlly.