WEBVTT 00:00.000 --> 00:12.400 So, welcome to our second talk. Thomas got us off to a great start with some of the interesting 00:12.400 --> 00:17.200 data about how performance has changed in the last 20 years. He also referenced, it's not 00:17.200 --> 00:21.680 just about performance, it's also around new features. One of the features I'm super excited 00:21.680 --> 00:28.720 about is logical replication. So, Boris, I think a few of you will recognize Boris, very active 00:28.720 --> 00:33.760 member of the community through Postgres User Groups events like this. So, I'll hand 00:33.760 --> 00:37.440 of the Boris to talk about another really cool feature in Postgres which keeps on growing 00:37.440 --> 00:38.720 logical replication. 00:44.720 --> 00:50.000 Thank you very much. Can you make up for this working well? Yes. I need to move a little with you. 00:50.000 --> 00:54.720 So, we're going to start with our survey because they always say, I'm trying to become 00:54.720 --> 00:58.800 a better speaker so they say, you need to know your audience. So, I'm going to try to get to know 00:58.800 --> 01:04.720 the audience. So, the first question is, have you ever raised your hand in a presentation before 01:04.720 --> 01:10.400 please raise your hand? So, you have already the training, that's excellent. Who is running Postgres 01:10.400 --> 01:19.920 in production today? Good. Who is running Postgres 17? 16 or 15 or 14? Good, because you guys need to 01:19.920 --> 01:25.040 upgrade and that's a good audience for this one, for logical replication because we use it to 01:25.040 --> 01:36.320 upgrade. Who here can see themselves as DBAs? Okay, good. Excellent. Developers? More, 01:36.320 --> 01:41.200 excellent. This is for them. That's good. Excellent. Another developer there. Great. So, 01:41.200 --> 01:46.880 this is something that is have to be well understood by DBAs so that they can support the 01:46.880 --> 01:52.320 developers but the developers also can know a lot so that they can help design in the application 01:52.320 --> 01:59.040 and the schemas so that it works much better for any upgrade or any fancy architecture build with 01:59.040 --> 02:06.320 logical replication. Now, logical replication is more powerful like power metal than a physical 02:06.320 --> 02:13.920 replication, however, is complex compared to physical replication. But, simpler than complex 02:14.240 --> 02:18.480 is better than complicated. So, we are good. It's not complicated. It's just complex. Now, 02:20.320 --> 02:24.240 my name is Boris Mehlis. I'm originally from Chile, leaving in Belgium since the beginning of the 02:24.240 --> 02:30.080 century. I think this is my 21st first step. I'm super happy to be able to speak in a Devroom. 02:30.080 --> 02:36.720 And then my title is Holistic Systems Software Engineer. That means that I like to see the things 02:36.720 --> 02:42.800 from the part of the system and also from above from the design application. So, try to combine 02:42.880 --> 02:48.080 everything because I believe in the fundamental interconnectedness of all things hence the term Holistic. 02:48.800 --> 02:54.000 Now, I'm also actually an er guitar player that actually what I do every day more than engineering 02:54.800 --> 03:00.720 but not professionally. So, I'm not going to do it here. Now, this reminds me about another 03:00.720 --> 03:08.400 question that I wanted to have regarding the audience who likes here heavy metal. Oh, that's good, 03:08.480 --> 03:13.920 excellent. Who tolerates heavy metal? Okay, it's good. So, you're the right audience for this one. 03:15.920 --> 03:20.720 Because we're going to use as an example. I like learning by example. And we are going to talk 03:20.720 --> 03:28.240 about logical replication. So, logical replication has many use cases and the most common one is this one. 03:28.800 --> 03:32.960 So, I was saying upgrade of a major version. I'm going to explain the difference between physical 03:33.040 --> 03:39.920 and logical and then you understand why is it good for major upgrades. Now, for doing major upgrades, 03:40.960 --> 03:46.720 one of my goals in life is to become a better writer but still not very yet. So, I cannot write 03:46.720 --> 03:52.080 things to put them in images in your head. So, I decided to draw images instead of writing them because 03:52.080 --> 03:57.200 it's going to be more difficult. So, the idea here is that what is my pen here? Good. 03:57.680 --> 04:08.880 You're going to have a primarily note which is run in your version 15 or 16 or below with a 04:08.880 --> 04:13.200 standby. This is a physical replica. In physical replicas, it's just going to be absolutely 04:13.200 --> 04:20.320 everything. But then what you want to do is you want to move to a version 17, which also has a replica. 04:20.320 --> 04:30.080 The advantage. Well, they have to bear with me with a few in the streaming story. Sorry for 04:30.080 --> 04:39.360 the streaming. I'm going to disappear for a few moments. So, you can do is to take everything out 04:39.360 --> 04:44.000 with PG dump and then inject it on the other side but this mean a lot of downturn. So, what you can do 04:44.080 --> 04:51.760 is to take only this schema which is all the definitions of your table then you put it here 04:51.760 --> 04:56.800 and then you have all the tables on your target which is a different version of major version 04:56.800 --> 05:00.880 and then what you're going to do is you're going to set up logical replication which is going to 05:00.880 --> 05:06.880 send streaming first, synchronize all the data and then it's going to change every gender 05:06.880 --> 05:11.200 application write something here. So, the application is continuously writing, 05:11.200 --> 05:16.400 put it's going to be sent to the logical replica and then at a certain moment you say, okay, 05:16.400 --> 05:25.280 we are done with the old version. We stop everything. So, we fence it and then we say, now the 05:25.280 --> 05:32.240 application is going to be pointing to the new fantastic version of 17 and then it's nearly 05:32.240 --> 05:36.640 zero downtime. It's not zero downtime but it's nearly zero downtime. So, this is what we are 05:36.640 --> 05:42.960 going to try to achieve. Now the point is what happens is why you are doing this? So, some step back, 05:45.840 --> 05:50.320 there is something that is going to break here the replication somehow. So, this is what we are 05:50.320 --> 05:55.760 going to study. But if something goes wrong then you will say, all we need to start all over again 05:55.760 --> 06:02.320 or maybe not. So, this is what I'm going to show you. So, this is one of the main stuff that you can do. 06:02.400 --> 06:06.480 The other thing that you can do is that you have this typical situation where you want to have 06:06.480 --> 06:12.160 one to have back here for this. You have one node which is super large that is to start collecting 06:12.160 --> 06:17.360 data from different places. And this one can be done with logic or replication as well because 06:17.360 --> 06:21.360 you have different sources and you aggregate them. The thing is that here you are going to have 06:21.360 --> 06:26.480 the possibility because you can write on this node to have some conflicts of data. And this is how 06:26.640 --> 06:35.520 we are also going to study today. Now, in version 1617 people decided that they are ready to do 06:35.520 --> 06:40.240 active active by the external replication changing data from one source to the target and from the 06:40.240 --> 06:45.840 target to the source. But it has a lot of complexity and a lot of things to solve. So, I'm not 06:45.840 --> 06:49.760 going to go into some details here but some of the stuff that we are going to study today are 06:49.760 --> 06:55.680 going to be super important if you ever want to try active active. So, this is all the settings 06:55.680 --> 07:02.960 why we are doing this stuff. But first, let's go with physical replication. Just just to know 07:02.960 --> 07:07.280 how fast I need to go, who here in the room thinks that you could sit with a colleague and then 07:07.280 --> 07:11.920 explain them how physical replication works. Let's see your knowledge of physical replication. 07:11.920 --> 07:16.800 Okay, we can do the same about with logic or replication. Okay, so not everybody which is good, 07:16.800 --> 07:25.440 so I'm going to explain this. This is your database. You have at the left side this is one node 07:25.520 --> 07:31.520 and this is our replica. Okay, what we have here is the share buffers. What we have here is 07:32.080 --> 07:36.160 your database, your files. And while it's going to happen is the application 07:37.200 --> 07:42.480 through a backend is going to start reading some stuff from the database, select everything from 07:42.480 --> 07:46.960 a table. If the table is not there, it's going to be a red from this point and it's going to be put 07:46.960 --> 07:52.400 in memory. And this is how you access your database in memory. You never access directly on the 07:53.360 --> 07:58.880 disk. Then you decide to write and then you make it dirty. Yeah, so your buffer is dirty. 07:59.840 --> 08:06.960 But who know about acid? Yeah, yes, this is like an answer to them. Every time I ask an answer 08:06.960 --> 08:11.680 to them, every day, they say, well, we're talking about databases. Let me get you excited. 08:12.320 --> 08:18.560 So this is the properties, the D for durability in acid or acid means that every time that I write 08:18.560 --> 08:22.400 something, when I commit, I have to have the guarantee that it's going to be really on this 08:22.400 --> 08:27.520 and if the RAM crashes, it is there. So what happens is that every time that you change something, 08:27.520 --> 08:31.920 through the world buffers is going to go to the wall file, which is right ahead log. It's a 08:31.920 --> 08:38.160 log of changes. So this log of changes is used for multiple things for recovering your database 08:38.160 --> 08:43.440 when it crashes or for sending it to another machine and then we can do a replication. Yeah, 08:43.520 --> 08:48.400 so this is how physical replication works, actually. So replication is based on restored. 08:48.400 --> 08:54.800 Okay, so that's basically when you have one single note, this is not enough because you send it to 08:54.800 --> 09:01.200 the, well, it's called the file system, but the file system could have some also some cache in between. 09:01.200 --> 09:05.360 So that's why we need to flush the data. And we're going to make sure, like when you 09:06.080 --> 09:10.560 amount the disk first there, you just be before you put it out, you have to make sure that first 09:10.560 --> 09:14.800 you amount it and then you take it out otherwise you're going to not have the physical copy here. 09:14.800 --> 09:19.440 Okay, so this is one note. Now you're going to have a replica which is going to have the following situation. 09:19.440 --> 09:24.080 You have a wall sender which is going to read every change here and it's going to send it to the 09:24.080 --> 09:28.880 wall receiver which is at the other machine and it's going to write it on the wall files at the 09:28.880 --> 09:36.080 replica. Absolutely everything. Even if you say insert something and then you say roll back that 09:36.160 --> 09:41.440 garbage is going to send to the other machine as well. Even if you do vacuum to remove and clean up 09:41.440 --> 09:46.960 your database, it's also going to send that all the maintenance is sent. Now the important thing here 09:46.960 --> 09:52.320 is that here you can identify at which state is my replica. It receives the data, this is this. 09:53.520 --> 10:01.200 It receives it, but it's also on disk at the other side for sure is this one and it is apply. 10:01.200 --> 10:05.760 So that is readable for the application at the other side that is also something that we can measure. 10:05.840 --> 10:11.120 So we know that this is good for read at the other side, but this is read only. It's a physical copy. 10:11.120 --> 10:16.240 So you can only read. If I try to write here, boom, it crashes. That's not crash. Sorry, 10:16.240 --> 10:20.560 the transaction crashes. Sorry, you cannot write here because this is read only. 10:20.560 --> 10:26.800 Yep. Physical replication. Good. And then because in a certain moment you want to send things 10:26.800 --> 10:31.200 from the run to the database, this is called a checkpoint. Here's called a restart point. 10:31.280 --> 10:37.760 Things are going to go from the run down, okay. Right. Now how logical replication works. 10:37.760 --> 10:42.480 Let's get to this point. We were here when we have one node. Now instead of having a wall sender 10:42.480 --> 10:46.160 and a wall receiver just like that, in addition we have, but we also have the wall sender and the 10:46.160 --> 10:52.800 wall receiver, but a logical decoder decoder gives us already a lot of information. It means that 10:52.800 --> 10:57.840 it's going to look at the transaction and it's going to decode it. It's going to extract and it's 10:57.920 --> 11:03.200 going to say, I'm not going to talk about blocks or anything. I'm going to say, this row should have 11:03.200 --> 11:08.480 this value. Yeah. And because I'm decoding this, it means that at the other side, I can 11:08.480 --> 11:14.640 store it in whatever order format. That means that I can do a different major version of postgres 11:14.640 --> 11:19.360 and the implementation is going to be different. So I can do that. In fact, you could take this 11:19.360 --> 11:25.680 representation, convert it into JSON and send it through Kafka to all the nodes. So all these things 11:25.680 --> 11:31.120 of getting postgres sent to other different type of databases is going to load your replication. 11:31.120 --> 11:38.000 You decode information and you stream it to all the places. So this is very powerful. So 11:40.320 --> 11:45.840 important thing, load your replication is not going to just take anything. Only when you commit, 11:45.840 --> 11:51.040 it's going to say, okay, this transaction is a good thing. So it's worse doing all the decoding 11:51.040 --> 11:54.640 work and then send it. Otherwise, it's just going to skip it. It means also that all the 11:54.640 --> 12:00.640 maintenance stuff like vacuuming and all the stuff is also skipped. Yeah. So I commit and then 12:00.640 --> 12:04.080 the logical decode, I say, okay, this is the thing I have to start to do and then it's going to 12:04.080 --> 12:08.320 look at backward and then I'm going to take everything. There are new protocols that says that if you 12:08.320 --> 12:13.600 have super large transactions going to start doing work in advance, so that doesn't get to a very 12:14.400 --> 12:19.840 slow moment. But then it says, it's a row operation that it says. Yeah, it doesn't say in block, 12:19.840 --> 12:25.440 it says, like, insert this row, update this row, delete this row, truncate this table. Yeah. 12:26.640 --> 12:30.880 And then the downstreamer, it really sounds like a character from Ronin James' Deal, 12:30.880 --> 12:37.280 like the star gaser, the downstreamer. Yeah. So that one is not going to apply to the wall. See, 12:37.280 --> 12:43.680 it's going to, through a process, put it immediately on the shareholders. Yeah. So it is available 12:44.080 --> 12:50.400 there together with all the stuff that applications are right in there. And I try to do as much 12:50.400 --> 12:57.040 as possible, friendly for blind color blind people. But this is one color, this is a different color, 12:57.040 --> 13:02.000 if you don't see it. So there is this one, it's also able to write. Yeah. You can see also that 13:02.000 --> 13:06.480 the representation here is kind of horizontal, here is kind of vertical. So different representations 13:06.480 --> 13:11.120 of the block. And then everything will go through the wall buffer here from the other primary 13:11.120 --> 13:15.600 nodes. So you have two right of all those two primaries. Okay. So this is important to 13:15.600 --> 13:19.760 consider, because if you want to do active active, actually what you're doing is that you're mixing 13:19.760 --> 13:24.560 things here and then having to filter stuff to send them back to the other side. We're not going 13:24.560 --> 13:28.880 to get there yet, but that's a little bit of the idea. And this one can do his own checkpoints 13:28.880 --> 13:33.760 in a completely different way. Yeah. Okay. Good. Have any questions about this? 13:36.080 --> 13:40.080 It's clear now. Okay. Good. Excellent. Try to explain it to somebody else. When you try to 13:40.160 --> 13:43.840 explain to somebody else, you test your own knowledge. That's the reason actually what I 13:43.840 --> 13:51.360 give talks because otherwise I would think that I know. Yeah. Yes. Good question. So it goes the both 13:51.360 --> 13:59.360 both the replicated data and the updated goal, shared buffer stem into a red headlog. Yes. 13:59.360 --> 14:05.440 But if we want to do a cent from this node to another one back to that one. Yeah. Okay. 14:05.440 --> 14:10.000 So the question is, Boris, can you repeat the question? Yes. So I want to do a bit of the question, 14:10.000 --> 14:14.080 of course. So he's asking, okay, everything coming from this side gets into the share buffer 14:14.080 --> 14:18.480 here and the application that writes here also gets here and the same share buffer everything goes 14:18.480 --> 14:23.040 through the world files. How do I send this to all the places? Well, I need to set up 14:23.040 --> 14:28.880 that on publication and subscriber. So this is the key. At this moment, this is a publication 14:28.880 --> 14:33.280 and this is a subscriber. This is a subscriber. We receive all from the publisher. So if you 14:33.280 --> 14:38.240 want to start sending things to another node, then you have to create a new publisher here. 14:39.440 --> 14:45.040 So you have to set up. Yeah. Send it to this one. It's going to complicate stuff. But 14:45.040 --> 14:52.560 but that's it is possible now since version 16. Yeah. Good. So this is all the the theoretical stuff. 14:54.000 --> 15:00.080 Now let's go do some cool stuff. So before that, that's why I put this one to remind myself, 15:00.480 --> 15:07.760 this is per database. You put a publisher for a single database. And the subscriber is also one 15:07.760 --> 15:13.680 single database. If your post list instance has 10 databases, you need to set up 10 publishers 15:13.680 --> 15:20.400 and 10 subscriber. The advantages that you can do a major upgrade of one database at the time. 15:20.400 --> 15:24.000 So you can say, okay, we are going to coordinate to that development team and they can do the upgrade 15:24.000 --> 15:29.040 whereas the other team is waiting instead of like waiting that everybody agrees to move to version 17. 15:29.120 --> 15:34.480 Or you can even say like, well, this database is actually using more than half of the CPU 15:34.480 --> 15:39.440 and all the nine databases are kind of having trouble. So let's take it away. How you take it away 15:39.440 --> 15:43.760 with a publisher and a subscriber and then you send it to another node. So plenty of possibilities, 15:43.760 --> 15:51.200 super cool. But it's one single database at the time. Yeah. Which means that users when you create a 15:51.200 --> 15:55.360 user that doesn't belong to a database, you have to make sure that your users are present in 15:55.440 --> 15:58.480 all the subscribers as well. Otherwise, you're going to see some funky stuff. 15:59.200 --> 16:03.200 And metal is better than funky. So you better don't see funky stuff. Although it's not bad, 16:03.200 --> 16:08.880 but I mean, it's not as good as metal. Okay. So let's break it. Let's see how it's working and then 16:08.880 --> 16:12.640 let's break it and then let's see how it's going to. The first thing that I'm going to show you is 16:13.920 --> 16:19.680 so let's say there's some who needs to Belgium here. So there's some metal festival here. One 16:19.680 --> 16:24.000 is called Grass Pop, the other one is called Ikatras and I realize now there's one in Durui. So the 16:24.080 --> 16:28.160 French-speaking community also have their own metal festival. I think in Durui, they also bring 16:28.160 --> 16:34.320 some rock stuff from most of the time. Not that much. So let's have a table here which is for the 16:34.320 --> 16:40.800 genres of heavy metal. You know what I mean? But isn't it just one single genre? No. There are many, 16:40.800 --> 16:46.400 many heavy metal styles. And this is what we're going to study here. So we have an idea which is a 16:46.400 --> 16:51.840 serial number that incremented self. It's our primary key and a genre which is unique. Because 16:51.920 --> 16:56.880 each genre is unique in itself. You're going to repeat this stuff. Very simple but very useful 16:56.880 --> 17:04.000 for our test. So sorry for the streaming but I need to move here. Because I'm going to show you 17:04.000 --> 17:10.720 here. This is one database which is Grass Pop. Let me try to increase the phones. Is it better? 17:12.320 --> 17:15.680 So let me show you the table select what you can do. You can do select star 17:15.920 --> 17:29.920 from genre. And so nothing or you can also do a table. And it's exactly the same. So let me 17:29.920 --> 17:34.720 copy this and I'm going to put it in another database here which is the, this is the upgrade. 17:34.720 --> 17:43.840 This is looks select version. This is running version 17. This one here. It is running version 16. 17:43.920 --> 17:53.680 Yep. And now here I'm going to show you a table. Nothing. Okay. So what I'm going to do here 17:53.680 --> 18:01.680 is I'm going to insert a genre. Insert into genre. The genre and then it will be values. 18:01.680 --> 18:08.720 Let's put a fair classical one heavy metal. I also like bear metal more than 18:09.680 --> 18:16.080 little machines and stuff like that. But it's a different story. So then let me do. You can do watch here. 18:17.520 --> 18:22.800 Yeah. So every second is going to you see it inserts a value heavy metal. I made a type of there. 18:22.800 --> 18:38.240 So let's fix the type of update genre sets value genre to heavy metal. Where I 18:38.240 --> 18:46.080 think it is 11. 11. Okay. So I change. So you see, insert updates. They're all replicated. 18:46.080 --> 18:54.000 Awesome. Can you read? Can you know everybody with this? Yeah. Okay. Good. Yeah. So that works well. 18:54.000 --> 19:05.360 Very nice. Here I can check in publications that I have select star from PG publication. Look, 19:05.440 --> 19:10.000 this one doesn't look very nice. But if you do exactly the same query and then you replace the 19:10.000 --> 19:15.840 semicolon. There's a song from Lannor. So we're good with semicolons. With backslatch GX, 19:15.840 --> 19:22.240 it's going to show it vertically. Cool, isn't it? The good thing. I mean you can do backslatch EX 19:22.240 --> 19:27.120 and you change every query but if you want to change only one, you do it like this. And you can see 19:27.120 --> 19:33.440 that I'm going to publish inserts, also updates, also deletes and truncates. So then you can know 19:33.520 --> 19:38.640 what you're doing. So you could have your publication, like you have let's say internet of things, 19:38.640 --> 19:44.320 you just do logging. So you only add stuff, you publish only the insertion. And then at the other 19:44.320 --> 19:58.400 side, like this, better, you say select star from PG subscription. Sorry. Yeah. And here you can see 19:58.400 --> 20:03.600 that I'm connected to the database, grass pop with the whole grass pop. I'm trying to also take 20:03.600 --> 20:08.160 advantage to change the name of the database to GMM because it's shorter and some people say 20:08.160 --> 20:14.960 that shorter is better than longer. However, I think the GMM, it means grass pop metal knitting. 20:17.200 --> 20:21.840 It is a festival. How you go to the meeting? I mean, it's like if you have a super nice events 20:21.840 --> 20:27.120 and you call it metal knitting, maybe gathering sounds more like epic. But no metal knitting, 20:27.120 --> 20:30.560 imagine if you have a super nice conference of developers and you call it, I don't know, 20:30.560 --> 20:35.760 developers, European knitting. And you say you have meetings from Monday to Friday and then you 20:35.760 --> 20:42.240 want to have meetings on the weekend as well. But not for some is great. I love it. But I mean, 20:42.240 --> 20:48.720 why did it put within at the end? Anyway. So that's the subscriber. And it's working well. 20:48.720 --> 20:55.360 But I told you that I was going to break this stuff. So let me break it. And the reason that I'm going 20:55.360 --> 21:02.800 to break it is with this video. Video means data definition language. So it's a language to 21:02.800 --> 21:11.040 define your schema. So I'm going to change the definition of the table jar. So let's change it. 21:11.760 --> 21:15.120 And this is going to break my logical replication. So I'm going to say here, 21:15.120 --> 21:22.400 author, table, well, was it a jar of art or column? Because we want you to know which bands are 21:22.480 --> 21:29.680 more willing to come to the festival. So popularity, popularity, which is going to be an integer. 21:30.560 --> 21:35.760 Yeah. And now I'm going to insert a new. Let me put it here. I'll see it again. 21:37.680 --> 21:46.480 Table, jar, and then we do watch one. Anybody want to suggest a jar of heavy metal that 21:46.480 --> 21:56.240 is particularly like? Power metal. Power metal, okay. Insert into genre. And then it's a genre 21:58.080 --> 22:04.480 values. And then the values are going to be power. And I really like power metal, so let's see. 22:07.120 --> 22:12.560 Okay, it's inserted. But it's not here. See? Why not? 22:17.200 --> 22:26.080 Because the column at the publisher has three columns. It has ID, genre, and popularity. Whereas 22:26.080 --> 22:31.120 the receiver only has two. So it doesn't know what you do with the data. It's a missing column. 22:32.160 --> 22:38.960 The missing link. How do we know? Well, we go to the logs. So we go to logs and exit. And then 22:38.960 --> 22:49.920 we do a tail minus 11, because 11 is a nice number. Follow bar, log, postgres. So you have to 22:49.920 --> 22:56.720 logs are very important. Very useful. Okay. But lazy. Error. Logical replication target replication. 22:56.720 --> 23:02.640 Graspo is missing column popularity. So the log is going to help me to figure out why this 23:02.640 --> 23:07.840 thing broke. So we need to keep back on this streaming stuff. So let me just do the same thing here. 23:08.000 --> 23:14.320 So P-sql, gmm. And then let me do outer table. Oops. 23:18.400 --> 23:25.200 Check. And then I want to see the tables. And then it is broken at the moment. So what happens is 23:25.200 --> 23:32.160 that. Yeah. Now you can back. So what happened is that it breaks. But it doesn't try to 23:32.160 --> 23:36.320 consistently give me the data given the data. And I said, okay, well, let me try a little bit later, 23:36.320 --> 23:41.680 because maybe the DBA is fixing this stuff. So it's not going to reconnect immediately. 23:41.680 --> 23:46.080 It's going to wait some random moment of time between X and Y. And then it's going to reconnect. 23:46.640 --> 23:49.440 Yes. And right now it's time now. So go to have the questions for the end. 23:50.320 --> 23:53.120 And this is a very important question. Is it a very important question that you think 23:53.120 --> 23:56.880 that I need to ask this question? Good for the other way around. What if I had the column 23:56.880 --> 24:01.760 field? I'm not there. Okay. We'll work the other way around. Like I asked a column of the other 24:01.760 --> 24:07.920 side actually, I don't remember. But I have a slide there at the end that says test your assumption. 24:07.920 --> 24:13.840 So I assume that there are some rules. At least I work with another software, which is not open source, 24:13.840 --> 24:19.200 where you can define rules. And then you say it is a missing column of the receiver, just skip that column 24:19.200 --> 24:25.840 and don't worry about it. Yeah. So the question was, what if I added first the column at the target, 24:25.840 --> 24:30.160 would that work or not? If we have time, we would try it otherwise we try it on the 24:31.040 --> 24:34.560 or T break, because T is shorter than coffee, so it should be a better word. 24:35.840 --> 24:39.600 According to some people, I don't know why. I like long wars. Like in Dutch, you have a 24:39.600 --> 24:44.400 water, a real water server in Cislasi, super long word that I learned and I'm super proud that I 24:44.400 --> 24:50.160 learned that word. Okay. Good. So we broke it and we fixed it. So that's nice. So that's the title 24:50.160 --> 24:56.320 of this presentation. To keep on streaming even though it's broken. So DBL is not replicated, 24:57.200 --> 25:01.760 which means that if you're doing a publisher's describing, you need to be able to manage your 25:01.760 --> 25:07.040 changes on your schema. Every time that you do something, you do it in the two nodes. Okay? 25:08.000 --> 25:14.880 Good. Okay. Next one. Sequences. What about sequences? Because this one was a serial. Yeah. So 25:14.880 --> 25:19.120 let's see what is happening with sequences. This one I'm not going to break it at this moment, 25:19.120 --> 25:27.360 but if you look at the definition again of the table, it says that here it is going to be the next 25:27.360 --> 25:35.120 value of this request. The one that is going to be the next value for the ID. Yeah? So if I call that 25:35.200 --> 25:49.200 here, next, well, it gave me 13. We're talking about metal and then we get all these kind of numbers. 25:50.480 --> 26:02.480 Okay. But then if I want exactly the same query here, I get one. Because I haven't inserted anything there 26:02.560 --> 26:08.400 at the replica. So I'm not breaking it now, but I want to show you that when you are going to 26:08.400 --> 26:13.200 do remember when I have the application that switched from the source to the target, at that moment, 26:13.200 --> 26:17.760 if you're starting 17 data, it is going to break then because it's going to think that, oh my 26:17.760 --> 26:26.400 next value is 1. No, it is 665. Yeah? Which is almost evil, but not there yet. So you need to be able 26:26.400 --> 26:30.720 to synchronize the whole thing with the sequences. So this is super important when you do the 26:30.720 --> 26:35.600 cut-over, that's something that you need to take into consideration. Sequences. Okay? Good. 26:36.800 --> 26:41.360 Next one, conflict. All right. So this one is a little bit more complicated and have two ways 26:41.360 --> 26:48.080 of breaking the conflict. Yeah? Now, the first one is going to be the following. So I don't have 26:48.080 --> 26:54.160 only the situation of doing the major upgrade that I go from a source to a target, which is exactly 26:54.160 --> 26:59.840 same festival. I mentioned that there is another festival called Akatras. Akatras is very interested 26:59.920 --> 27:06.560 in also getting the information from the other system, the other festival. So it's going to say, 27:07.120 --> 27:15.040 you don't have two DNS DNS. Two actually schemas, one for Akatras and the other one is for 27:15.040 --> 27:20.640 glassboard. Yeah? The use of actually that the owners here are referring to two important 27:20.640 --> 27:26.320 Chilean women. This is Juanita Parra, drummer from the band, Los Hibas, really very good drummer. 27:26.640 --> 27:31.520 And Tiripaneque, which is an astronomer from Chile, which is also an ambassador, ambassadors 27:31.520 --> 27:38.080 from for UNESCO. So that's why I use them as the owners of this stuff. Okay? So 27:39.520 --> 27:45.360 this one also have a subscription. So look, select start from PG subscription. 27:48.000 --> 27:50.560 And it's also going to take you the host grasp book. Yeah? 27:51.520 --> 28:02.240 And so it means that if I do select start from genre, it's empty. Why is empty? 28:04.240 --> 28:09.920 No, I was missing the column, but it should have get the heavy meta first. 28:12.000 --> 28:18.080 No, it had the subscription. What is the schema? I showed you that I have two schemas. 28:18.400 --> 28:23.200 You need to do it like this, show search path. This is nothing to do with the logic 28:23.200 --> 28:27.360 of application, but it is something that some people kind of, I have done it multiple times, 28:27.360 --> 28:32.320 and it's like why is not working. The search path is super important. The search path is like the path 28:32.320 --> 28:36.800 in Linux. When you try to find your commands to execute, this is the same thing, but with the 28:38.880 --> 28:43.200 schemas, it's going to search the tables on this schemas that I have defined. And for this database, 28:43.200 --> 28:51.600 I define architectures. So I have to do it explicitly. And if you know the zen of Python, 28:51.600 --> 28:57.200 explicit is better than implicit. So let's make it explicit. Grasper. There you go. So I have 28:57.200 --> 29:02.080 very metal with a new update, but I don't have the other one because I'm missing the column. Yeah, 29:02.080 --> 29:21.680 so it's very good. So where was my name? All right. So this one was was broken, but if I show 29:21.680 --> 29:30.960 everything from the table, it's going to come back at any time. Watch one. I should come. 29:31.040 --> 29:36.240 How about I still have a, no. Thank you. Thank you. Thank you. Thank you. What did I forget? 29:38.720 --> 29:42.400 Oh, when did the other table? Yeah, perfect. Perfect. Yeah. Thank you. 29:44.560 --> 29:50.400 It's good to have a such a collaborative stuff. Yeah, there you go. Good. So you see, 29:51.680 --> 29:56.160 that's why we're working in the open, because you can get fixed in fixes from the other people. 29:56.160 --> 29:59.920 Super important for open source. Okay. So it's working now. But let's say that the people in 29:59.920 --> 30:04.640 Alcatraz say like, oh, I know that this super good band Brutus from Belgium is going to be playing, 30:04.640 --> 30:09.440 but they haven't put the information yet. And I'm going to put the genre of a Brutus already there. 30:09.440 --> 30:14.960 So let's insert it anyway. Insert into a grass pop. Then I need to put the genre. 30:16.080 --> 30:22.240 And then they're going to put the values directly. Values are going to be 42. 30:23.040 --> 30:28.480 And then a Brutus plays post metal. Some people say that it's post hardcore post rock. 30:28.480 --> 30:32.400 There's some discussion there, but let's say that it's post metal. Yeah, then there it is. 30:33.200 --> 30:43.200 So you see, now you have, this subscriber can also write. And that's dangerous, 30:43.200 --> 30:49.120 because why does the publisher also write exactly the same thing? Or not exactly the same thing, 30:49.200 --> 30:55.520 but something that is going to conflict with my data locally. Yeah. So let's say that I 30:55.520 --> 30:59.520 be able from grass pop seller. I have a forgotten to insert Brutus. Let's insert Brutus then. 31:00.560 --> 31:08.320 Let's insert post metal. Yep. Okay. Insert it. No problem. But here, 31:08.640 --> 31:24.720 it's still 42. However, here, it is number 15. So this one have 15 post metal. And the other one 31:24.720 --> 31:30.160 has 42. So let's insert another one. I really like non-war of steel. It used to be non-war, 31:30.160 --> 31:36.720 but they need to change the name for no reason. And then have part of the now. I have a part of 31:36.720 --> 31:44.000 you here now. What happened here? I don't have part of it because it breaks. Why did it break? 31:44.000 --> 31:50.720 It didn't break because I have the same ID, but I said that the genre is unique. So this is going 31:50.720 --> 31:54.880 to be a problem that you're violating a constraint that says that this has to be unique. And I 31:54.880 --> 32:02.960 have two rows with the same genre. And that's bad. Okay. So let me look at the logs. You have the 32:03.120 --> 32:14.480 logs here of here. Yeah, here. But this is agatrust. Let me put it larger. Let me run here again. 32:15.680 --> 32:24.560 You can see here. Here error. So I'm sure you have to debug your logical replication. It says 32:24.640 --> 32:31.520 duplicate key via this unique constraint, genre, genre key, which is a unique stuff, 32:31.520 --> 32:38.880 post metal already exists. Yeah. So there are two ways here. You're fixing it. How much 32:38.880 --> 32:47.040 then you have it? Okay. There are two ways to fix it. And help me decide which one. I can either. 32:47.040 --> 32:52.640 The easiest one, ID leads the one that I have in the target. The one with number 42. And this is 32:52.640 --> 32:56.400 going to release the whole stuff. It's very simple. Okay. Now I can receive this stuff because 32:56.400 --> 33:02.000 there is no conflict anymore. Yeah. If you have active active, you delete it here. So you send 33:02.000 --> 33:08.400 the lead at the other side that you break it even worse. So that's active active is dangerous. Yeah. 33:10.400 --> 33:16.160 So that's one thing. I can delete it and it's going to be fixed. The other one, I can try to figure 33:16.320 --> 33:23.600 out what is the LSN that break and I can skip it. I'm your subscriber, but I don't want that 33:23.600 --> 33:29.440 particular transaction because it's going to break my whole thing. Which one do you like? Number 33:29.440 --> 33:35.680 two? Number two? Number one. Raise your hand if you prefer delete the row. Raise your hand 33:35.680 --> 33:41.200 if you want to see how to skip the LSN. Okay. It's clear. I like democracy. Tell the LSN 33:41.360 --> 33:49.200 I'll leave it here. So first of all, I need to figure out which one is the LSN. 33:52.160 --> 34:00.720 Here, it says, I need two pieces of information. The LSN that break my transaction as I'm 34:00.720 --> 34:10.480 in my streaming and the name of the streaming that go broken. And that is here. Here. You see 34:10.560 --> 34:16.640 context. This is like humor. And humor context is super important in error. The context is also 34:16.640 --> 34:20.960 very important. You're going to just tell a joke in the middle of some other context. Nobody's 34:20.960 --> 34:25.520 going to think funny might be offensive. Here, the error is also important. So the context is 34:25.600 --> 34:32.640 glass book journal in transaction 7080 finish. And here's the LSN. Logical application, broke. 34:39.600 --> 34:44.800 Yeah, this is the finish of this one. So this is the number and the subscription. What is it 34:44.800 --> 34:53.920 in the name of the subscription? Ah, here it is. TG 16659 and this is the, this is the different 34:53.920 --> 35:07.040 section. Okay. So, this is the query. Select PG remote. I always forget. When you forget the function, 35:07.040 --> 35:13.360 I have this a trick. You do backslash df for this cry function. Everything that I was called PG 35:13.360 --> 35:23.600 something with origin on it. And it was something with advance on it. Yeah, advance. There you go. 35:23.600 --> 35:29.680 I found the function. It is called PG underscore replication origin advance. And it received a text 35:29.680 --> 35:41.040 for the subscription and the LSN. Yeah. So let me copy that. Okay. So I do select that function. 35:42.000 --> 35:46.000 Yeah. And then I pass a text, which is my subscription. This one here. 35:52.000 --> 35:55.120 And then the LSN. But the LSN have to be slightly. 35:58.640 --> 36:04.400 So this is like this. And I need to cast this. All the ones in the string. So I need to say that 36:04.400 --> 36:11.920 this is not this number, but it is a LSN PG LSN. But now this is not the one that I need. I need the 36:11.920 --> 36:17.200 next one. Yeah. So I need to add that. Yeah. It's super difficult to automate this kind of stuff. But 36:18.400 --> 36:25.280 first you need to do it manually in the nearest one. Okay. I say, I know that this particular LSN 36:25.280 --> 36:30.720 LSN is for log sequence numbers. So your log not as a log in for the errors and information, 36:30.800 --> 36:34.720 but the right ahead log, it has a sequence number, everything gets serialized. And you 36:34.720 --> 36:39.520 say, that particular change, I want to skip it in advance to the next one. So that's what I did. 36:39.520 --> 36:40.720 And now let's look at this. 36:44.640 --> 36:49.840 Sir, I fixed it. I got the part of the, I skipped the one that was giving me the problem with the post 36:49.840 --> 36:56.480 metal and now I have my table there. Yeah. Okay. So if I would have deleted, it would have been, okay. 36:56.480 --> 37:02.080 But are you going to have an issue now with 42? Yes. So I'm going to have an issue now because the 37:02.080 --> 37:09.200 key 42 might be a four in key for all the tables that refers to the ID. So then because this is also 37:09.200 --> 37:20.640 a rightable note, I can update the key and I can say update a grasp of genre set key equals 15 37:21.520 --> 37:28.000 where key equals 42. What did I say? ID. And I think you think. 37:29.280 --> 37:35.040 Now it's just just because I like keys. You know, there's a very nice album called the 37:35.040 --> 37:46.080 keyboard of the seven keys. All right. So it is, it is a complex. But once you understand, 37:46.080 --> 37:55.920 like you said, hey, the key, they're strong. It's good. Yeah, conflict. So this is just a reminder that 37:55.920 --> 38:00.480 share stake concurrency because our share in the state of the table is a source of all evil. 38:00.480 --> 38:05.680 If you read the book, the call of Tulu by Lovecraft, you will see that Tulu was created 38:05.680 --> 38:09.840 in a problem of share stake concurrency and that's why he's living in multiple dimensions. 38:09.840 --> 38:13.440 The same thing happened with Becna, which is also one of the new evil stuff that everybody 38:14.320 --> 38:20.000 was a problem of share stake concurrency. So beware. Okay, conflict again, that will be a problem 38:20.000 --> 38:25.360 with keys, not just the unique constraint, but I'm going to skip that one. Now let's see the 38:25.360 --> 38:31.280 importance of the primary key because I told you that we have to publish insert updates, 38:31.280 --> 38:38.080 delete and all the stuff. Turnkate was the other one. So let's go here again to the grasp book. 38:39.040 --> 38:43.840 There's one table that I haven't show you yet, which is select star from editions. 38:45.120 --> 38:52.080 Edition has all the years where grasp book happened, yeah. But they said it never here. 38:52.640 --> 39:00.960 Because 2020 was canceled because of evil epidemic. So I can have a 2020. I need to delete it. 39:01.600 --> 39:11.760 So let's delete it. Delete from editions where year, year, year equals 2020. 39:13.200 --> 39:17.760 But it doesn't let me delete it. You cannot delete what I mean, you cannot delete. 39:18.400 --> 39:22.000 If I wouldn't have just a normal database, this would have been able to delete anything, 39:22.000 --> 39:27.280 no problem. Delete is just a normal operation. However, I had a publication that says that I need 39:28.240 --> 39:34.080 to publish delete. But if I don't have a primary key, another one to be able to send 39:34.080 --> 39:37.360 either updates or delete. So let's look at the definition of the table. 39:39.360 --> 39:45.680 Additions. Here, there's no primary key. So in the drawing, I said that this one doesn't 39:45.680 --> 39:51.840 sense blocks of data that gets modified. It sends raw operation. So I cannot say delete the 39:52.720 --> 39:58.480 raw that has year 2020 because it's not a key. So I cannot find the other side. 39:58.480 --> 40:03.120 I would have to scan the entire thing in order to be able to find it. Well, then it suggests me, 40:03.120 --> 40:08.560 well, if you don't have a primary key, you can set this to a replica identity full for everything. 40:08.560 --> 40:12.160 You need to have an identity for your replica. If you don't have an identity, you cannot. 40:12.720 --> 40:22.720 There's another way which is just half the tables that have primary key in a publication that sends 40:22.720 --> 40:28.720 everything and another one that is an insert only publication. Because I know that I'm just going to 40:28.720 --> 40:32.480 insert stuff. But if you need to delete stuff, then you delete it on the publisher and on the 40:32.480 --> 40:39.040 subscribers. All right. So that's important on the primary key. Good. Our other extensions, 40:39.200 --> 40:43.360 usually when you extract your schema, you get the definition of the tables, but also you have 40:43.360 --> 40:49.040 create extension. Some extensions, like PG carbonara, which tells you how to cook the carbonara, 40:49.840 --> 40:54.720 it has already data on the tables as well. So if you do that, you're going to create an extension 40:54.720 --> 40:59.760 with data or PG agent with PG admin. Who has PG agent with PG admin? Yeah, that's going to 40:59.760 --> 41:05.440 also have description of jobs. If you create extension is a table with data. So you say publish 41:05.520 --> 41:09.600 for all tables. It's also going to send that data from the extension and it's going to arrive 41:09.600 --> 41:16.720 here. It's going to say all error. The data already exists. So you are violation of the same key. 41:16.720 --> 41:21.440 Yeah. So this is going to be a problem. The way you fix it is either you create the section 41:21.440 --> 41:25.040 afterwards. Nobody is going to fail because of this. So you have to turn K the table and then 41:25.040 --> 41:32.640 start the publication. It's not obvious. But there's a word. So closely words. Keep the logical 41:32.640 --> 41:37.680 replication streaming. It is complex but it's possible. What you need to remember is that these 41:37.680 --> 41:43.360 are two primary notes. So you can write on the publisher and on the subscriber as well. That's 41:43.360 --> 41:50.240 the main difference with physical replication. There is no idea the other replication. There are some 41:51.200 --> 41:56.640 software that provides that built in. But those are different. Suppose you don't have it at, 41:56.640 --> 42:00.320 I mean, there are some functions that PG logical. You can have a function. You say, 42:01.040 --> 42:06.400 with this function, I want you to add the idea here and also on my target. But by default, 42:06.400 --> 42:11.920 there is no idea a replication. So you have to manage it yourself. There is no remote looking. 42:12.480 --> 42:17.600 So you cannot look another table at the target to be able to do your modification consistently 42:17.600 --> 42:25.280 across everywhere. I like this because if the other one fails, remote looking, it is a share 42:25.280 --> 42:34.240 second currency. Unless you really, really, really, really need to do it. Then you evaluate it again. 42:34.240 --> 42:40.960 You make sure that you really, really, really remote looking. I don't like it. Personal opinion. 42:40.960 --> 42:49.120 But you will see the consequences. The subscriber will follow the publisher, but not blindly. 42:49.120 --> 42:53.680 If it's going to break my data here, I'm just going to say, I don't want your transaction 42:53.840 --> 42:58.480 talk to the hand. I'm not accepting it because it's going to break my consistency. And then the 42:58.480 --> 43:04.560 other one said, I've been going to accept it. I'm not sending you anything else ever. That's a publisher. 43:04.560 --> 43:07.920 So what you need to do is, okay, well, let's negotiate. Let me modify something here so that I can 43:07.920 --> 43:12.400 accept your change. And then you continue. That will be delete in the row or you say, well, well, 43:12.400 --> 43:16.560 I'm going to skip that one and then send me all the rest. But then I'm going to manage the consistency 43:16.560 --> 43:26.480 myself. So you have to be careful about it. Primary keys are keys. I mean, yes, but a key concept in 43:26.480 --> 43:31.280 your logical replication because you have to identify your row is a row operation that you're sending 43:31.280 --> 43:36.640 to the other side. So use primary keys as much as you can unless you are just doing insert only data. 43:38.400 --> 43:42.480 And then mind the sequences because they are not going to be synchronized. Don't forget about them 43:42.480 --> 43:48.560 because it happens to me a few times. So it might happen to you as well. And the extension. 43:48.560 --> 43:52.720 Don't think that off extension just create the extension. Some of the extension is they have data. 43:53.520 --> 43:58.960 You have to be able to manage what's going on with that, okay? I think that was it. I know, 43:58.960 --> 44:04.960 there are two my last messages that I want to give to you. First one is test your assumptions. 44:04.960 --> 44:08.320 When I was doing the delete, I think it depends on the version of post. This one is just 44:08.320 --> 44:11.280 going to say, I'm just going to delete it, but I'm not going to be able to send it because I don't 44:11.360 --> 44:15.440 have a primary key, but I'm deleting locally. Now, this version of Postgres 16, 44:15.440 --> 44:23.040 the source didn't allow me to delete. So test your assumptions in general in life. It's not just 44:23.040 --> 44:30.720 for Postgres. And practice regularly. I've been discussing with people firemen or fire people 44:30.720 --> 44:36.000 firewomen as well. They practice a lot. They do many, many exercises because when you are 44:36.080 --> 44:40.880 understress in a situation, if you know your stuff, it's going to be much more relaxed and 44:40.880 --> 44:45.680 you're going to really be able to fix and identify, like you were saying, I'm in super stress here 44:45.680 --> 44:50.400 in front of the audience, but somebody in the box said, oh, you forgot this key on aim because 44:50.400 --> 44:55.920 you are more relaxed. So if you want to be more relaxed in a stressful situation, practice a lot. 44:55.920 --> 45:01.360 Yeah. So do these kind of exercises, test your assumption, break your logical replication, 45:01.360 --> 45:05.200 try to fix it in two different ways by deleting the row, by skipping the transaction. 45:06.240 --> 45:08.880 And I think that's it. Thank you very much. 45:19.920 --> 45:22.240 Yeah, you have a question here. I can repeat the question, so. 45:22.960 --> 45:29.120 So the question is, you mentioned that it's going to be useful for people who want to upgrade. 45:29.120 --> 45:33.360 Yes. But you didn't specify what kind of conditions you would see. It's just where the 45:33.440 --> 45:38.800 source code location is. I mean, I think you might have that we can do migration or 45:38.800 --> 45:42.880 a large code location, right? Yeah. So the question is, where are the considerations that you 45:42.880 --> 45:46.320 need to take into account when you want to do an upgrade with logical replication? 45:46.320 --> 45:51.760 About the version. Yeah. So version compatibility, I think anything that is supported by 45:51.760 --> 45:58.400 Postgres, to anything that is supported by Postgres will work. So all this one, which one is 12? 12 45:58.480 --> 46:08.320 is the oldest one that we have? 13, 13. 13, 14, 15, 16 can upgrade to 14, 15, 16, 17. 46:08.320 --> 46:13.360 So then what about application or work, for example, 14, 17? Yeah, no problem. 46:13.360 --> 46:18.480 Yeah, you don't need to go one by one. You can go from 13, the register 17. 46:20.480 --> 46:26.240 One more question. What is the purpose of being able to select what kind of updates you were 46:26.320 --> 46:34.000 to publish? Why do they want to select updates? Okay, so if you want to separate the kind of 46:34.000 --> 46:37.920 information that you're going to publish, I don't want to say updates or delete or just insert, 46:37.920 --> 46:42.560 that is, most of the time when you have data that is a collection of things is you're not really 46:42.560 --> 46:47.360 making a clone, but you are collecting some stuff. So you say, I'm going to do auditing, 46:48.080 --> 46:52.080 which means I want to have all the data and if something gets deleted, I don't want to delete it 46:52.080 --> 46:55.920 in the auditing service because I want to be able to see all the operations. So that will be 46:56.000 --> 47:00.720 one way or say, like, I'm just going to do insert, but I'm not going to send any delete or updates. 47:00.720 --> 47:06.800 Yeah. Thank you. So if you can chat the question out and Boris will repeat it for the people 47:06.800 --> 47:11.040 who are online. So, yeah, there's a question there, sorry. 47:25.920 --> 47:33.120 That for the long duration queries at some point database will close the query and say, oh no, 47:33.120 --> 47:38.800 I have two of these, I'm going to like data about some practicating changes, all the tables you 47:38.800 --> 47:46.800 are trying to query at the moment. I mean, that one solution is to enable that one publisher 47:46.800 --> 48:09.200 and say, okay, they're not holding that so that this will be back. So the question is about 48:09.760 --> 48:16.400 the fact that you use your replica, what is physical or logical, actually, for doing read queries. 48:16.800 --> 48:22.160 But sometimes you are reading something that takes a lot of time here and the publisher is either 48:22.160 --> 48:26.480 preventive for pushing stuff because it's going to touch data that you're using for reading 48:26.480 --> 48:31.040 or it takes too much time and this one decides, like, I forget about you, I need to remove 48:31.040 --> 48:35.680 my wall files because I need some disk space and then it breaks the entire thing and then 48:35.680 --> 48:41.360 you're out of synchronization. So, actually, a logical replication, you are forced to use 48:41.360 --> 48:45.360 a replication slot. So you cannot do it without replication slot. That's why I'm showing you this 48:46.000 --> 48:51.200 replication slot and you see that for the grasp of GMM for the upgrade and for the grasp of 48:51.200 --> 48:56.640 ICATRAS, which is just to get some information, both of them need to have a replication slot, 48:56.640 --> 49:01.440 which is logical. You can see a slot type logical. In both cases it's active, you will see that 49:01.440 --> 49:10.080 it falls when it breaks the streaming. So this is one way of seeing, like, oh, I don't have the 49:10.080 --> 49:15.280 streaming working. My logical slot is accumulating a lot of disk space. I need to do something 49:15.280 --> 49:20.640 about it. Either I fix the streaming or I say, okay, well, this is broken. Let me get rid of 49:20.640 --> 49:24.800 the replication slot and then I continue. But this is the best way of keeping everything in sync. 49:25.440 --> 49:32.320 The logical replication slot. Yeah. I hope, if that doesn't, the question I'm going to be in the 49:32.320 --> 49:38.240 boost of Postgres from 12 to 4 p.m., you can also ask me questions there. We have time for one 49:38.240 --> 49:42.400 more quick question that we're going to finish. Probably at 10, 50. Anyone have a quick question? 49:45.040 --> 49:56.080 When you change the video, you use it off-table and afterwards you're thinking on the 49:56.080 --> 50:02.720 of this subscriber, can you add that moment to the course of the single initiation? 50:03.200 --> 50:08.960 Ah. So I showed that when it breaks the streaming, the streaming is not going to immediately 50:08.960 --> 50:13.040 start doing the risk synchronization, but it's going to wait something. And then the question 50:13.040 --> 50:20.720 is whether I can force the trying to get the synchronization as fast as possible. Because sometimes 50:20.720 --> 50:25.120 you can fix it only one day and then the spirit of time is longer. I don't remember whether it's 50:25.120 --> 50:29.680 a way of saying, like, try to synchronize again. Ah, there is one way, say, altars description, 50:30.320 --> 50:35.040 disable and enable it. So you disable it and you enable it immediately. When you enable the 50:35.040 --> 50:38.720 subscription, it's going to say, okay, let's try to connect and then let's try to get to the 50:38.720 --> 50:43.520 public share now. And then it's going to start getting the error again or it's going to fix the error. 50:43.520 --> 50:48.800 So re-enable the subscription is going to force the connection. Yeah. Thank you very much. We are at 50:48.800 --> 50:51.760 time. So thank you. Thank you. Thank you. Thank you. Thank you.