SLONIK_LOCK_SET(7)

πŸ“¦
version 2.2.11 Β· 4 versions
, in debian trixie, ubuntu questing

πŸ’… SLONIK LOCK SET(7) πŸ’…

okay bestie, welcome to slonik lock set β€” a page straight outta the Slony-I 2.2.11 docs. this one's short but it's important, so stay with me 🫢


✨ NAME ✨

LOCK SET β€” guard your Slony-I replication set so it's all prepped and pretty for MOVE SET πŸ’–


✨ SYNOPSIS ✨

LOCK SET (options);

✨ DESCRIPTION ✨

so basically, this command puts a guard on a replication set so your client apps can't sneak updates in while you're getting ready to run a SLONIK MOVE SET(7) command. it's giving bodyguard energy, fr fr πŸ›‘οΈ

okay but here's the tea: this command must be the first one in a possible statement group (that's a try). no cap.

why tho?? because it needs to commit the changes it makes to the tables (it's adding a special trigger function) before it can sit around waiting for every concurrent transaction to finish. and at the same time it cannot hold an open transaction to the same database itself β€” because then it would just be blocking itself forever 😭 a whole self-own. so yeah. first in the group, always.

also, heads up: this is a locking operation, which means it can absolutely get stuck behind other database activity. it's in the queue like everyone else, bestie πŸ™ˆ

the operation waits for transaction IDs to advance so that data isn't missed on the new origin. so if you've got long-running transactions chugging along on the source node, this thing is gonna wait for those transactions to complete. and here's the annoying part β€” if you have another database on the same postmaster as the origin node, long-running transactions on that database will also be considered, even though they're essentially independent. like, mind your business?? but no, it counts them anyway πŸ’€

  • ID = ival β€” the ID of the set you wanna lock πŸ”’
  • ORIGIN = ival β€” the Node ID of the current set origin πŸ“

this uses β€œschemadoclockset(p_set_id integer)” [not available as a man page].


✨ EXAMPLE ✨

here's what it looks like in the wild, mwah:

LOCK SET (
   ID = 1,
   ORIGIN = 3
);

✨ LOCKING BEHAVIOUR ✨

exclusive locks on each replicated table get taken out on the origin node, and triggers get added to each such table that reject table updates. so like, no one's touching those tables, periodt πŸ’…


✨ SLONIK EVENT CONFIRMATION BEHAVIOUR ✨

Slonik does not wait for event confirmations before performing this command. it just does the thing and moves on, iconic behaviour honestly 🌈


✨ VERSION INFORMATION ✨

this command was introduced in Slony-I 1.0. a classic. an OG. we stan an elder πŸ‘‘


and that's the whole page, bestie πŸŽ€ this was SLONIK LOCK SET(7) from the Slony-I 2.2.11 documentation, dated 19 September 2024. go lock those sets, you got this πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from