SLONIK_MERGE_SET(7)

✨ SLONIK MERGE SET ✨

okay bestie, welcome to the SLONIK MERGE SET(7) page 💖 this is from the Slony-I 2.2.11 documentation and it's lowkey one of the most useful little spells in the whole book, so let's get into it 🫶

---

💫 NAME 💫

MERGE SET — merge Slony-I replication sets together 🦋

---

🌸 SYNOPSIS 🌸

MERGE SET (options);

---

🎀 DESCRIPTION 🎀

So here's the vibe: you're merging a set of tables and sequences into another one. That's it, that's the whole job ✨

But why, you ask? Because — and this is the iconically annoying part — it is not possible to add tables/sequences to sets that are already subscribed. Literally cannot be done. So this function is the workaround 💅

Here's the play, step by step, no cap:

• create a temporary set
• add the new objects to that temporary set
• subscribe all the nodes that are currently subscribed to the other set to this new one
• then merge the two together, eliminating the set ID that was being added 👑

And like, one major heads-up before you go wild: this operation will refuse to be run if the two sets do not have exactly the same set of subscribers. Exactly. Same. Subscribers. No wiggle room 🙈

Now the options, and yes they're all required-shaped, don't skip any:

• ID = ival — the unique ID of the set that will contain the union of the two formerly separate sets. Like, the surviving set. The main character 👑
• ADD ID = ival — the unique ID of the set whose objects should be transferred into the above set. This one's getting absorbed 🫶
• ORIGIN = ival — the current origin node for both sets ⭐

Under the hood this uses “schemadocmergeset(p_add_id integer, p_set_id integer)” — and nope, that one is not available as a man page. Sorry bestie 😭

---

🌈 EXAMPLE 🌈

Here's what it looks like irl:

# Assuming that node 1 is the origin of set 999 that has direct subscribers 2 and 3
SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );

see how clean that is? subscribed everyone first, then merged. that's the way ✨

---

🔒 LOCKING BEHAVIOUR 🔒

No application-visible locking should take place. that's it, that's the section, we love a low-drama locking story 🧚

---

💀 DANGEROUS/UNINTUITIVE BEHAVIOUR 💀

okay this is the part where I hold your hand, bestie 🫶

Merging takes place based on the configuration on the origin node. That's the whole thing it looks at. So if you request a merge while subscriptions are still being processed, you can cause in-progress subscribers' replication to break 😭 — because they'll be out here looking for configuration for this set, and the merge request has literally deleted that configuration. gone. poof.

Do not be too quick to merge sets. fr fr. let the subscriptions finish. patience is the vibe 🌸

---

⏳ SLONIK EVENT CONFIRMATION BEHAVIOUR ⏳

Here's the waiting game, and slonik plays it so well:

• Slonik waits for the command submitted to the previous event node to be confirmed on the specified event node before submitting this command ✨
• Slonik will also wait for any in progress subscriptions involving the ADD ID to be subscribed before submitting the MERGE SET command 👑

so it's genuinely out here protecting you from yourself. icon behaviour, honestly 💅

---

📜 VERSION INFORMATION 📜

• This command was introduced in Slony-I 1.0.5 ⭐
• In 1.2.1, a race condition was rectified where the merge request would be submitted while subscriptions were still in process on subscribers; it refuses to merge before subscriptions are complete 🔥

like, the fix literally built in the "wait for subscriptions" behaviour so you don't have to think about it. ate. periodt 💖

---

and that's the whole page, bestie 🎀

this was Slony-I 2.2.11 Documentation, dated 19 September 2024 — mwah, go merge responsibly, and remember: not too quick 💜🦋✨