 If anybody wants to follow along and they can't see the slides, the slides are at that URL at the bottom. They're the exact same thing I'm looking at now, so they're available whenever. If anybody needs me to reference back to that slide to get the URL, just let me know. My name is Keith Fisk. I'm a database administrator at OmniTI. Some things I've been, I've mostly been working on a lot of third-party tools in the Postgres community, PG Apartman, some of the bigger ones I've worked on. I also did a PD extractor in Mimeo, which is another logical replication tool for Postgres. OmniTI is a work consulting firm. We specialize in very high-traffic websites and applications. People have like multi-terabytes of data, millions of users are very high-concurrency, so that's mostly what we specialize in. At the moment, we are hiring, we're looking for sysadmins and developers. As with any time you download software or need to get software and knowing where to go to get it is the most important part. Of course, postgresql.org slash download provides all the sources for being able to download Postgres, all the binary packages, all the source code. There's actually live CDs available for demoing as well and whole application suites that are there. The first way I'm going to go over is the way Debian does Postgres packaging. Of the three, I'm going to go over Debian, CentOS slash Red Hat and FreeBSD. I actually like, they deviate the most from traditional Postgres, but I actually also like their method the best because as far as the system administration standpoint, it's a lot easier. As of today, the latest version, Debian is 8.7. As with most of the default repositories and operating systems, the default OS package for Postgres is not the most current. Thankfully, it's not that old. It is 9.4, so it's much better than Debian used to be. They were stuck on 8.4 for quite a long time, well outside of its supported range. But for any Ubuntu-based or Debian, which is also Ubuntu-based distribution, it's highly recommended that you go to app.PostgreSQL.org, and I can click on that. Anytime you see something orange in here, it's actually an active link, so you can click on that and go to it. That takes you to the Postgres Wiki and has full installation instructions for how to actually do this. I'll go through a little bit of a demo later. That has all of the up-to-date packages, that actually has also out-of-date packages as well, so if you need to get older stuff, but it has everything all the way up to and including 9.6, and sometimes they get alpha and beta versions in there available as well. It all depends on how much effort the maintainers feel like putting into it. But this also includes a lot of third-party applications like PgAdmin, PgBouncer, PgPartman. So if you'd like to have packages installed to manage your third-party software, this repository is actually a really good place to go as well. So the naming convention for the packages pretty much goes like this. The one that has no special name to it is the server package. If you just need the client, like you don't need to run the whole server, there's an individual client package. So if you just need PSQL or PgDump or something like that on a server, you can just uninstall the client package. Wherever you install the server, I highly always recommend installing the Contrib module or the Contrib package. That includes, if you go to the Postgres URL source, that includes the third-party tools that are part of Postgres Core like DB Link and PgCrypto and all of those kind of tools. Those are all provided in that one package. So I always highly recommend installing that even if you don't need it at the time that you're installing it. I can almost guarantee you will need it at some point, so just plan that from the beginning. If you need to do any compilation of any other third-party packages where actually development, the source code is available as a package for dev. So that's required for doing any compiling. If you want to compile PgPartman or PgBouncer or something like that yourself, you need that documentation as self-explanatory. The last two are unique to Debian. Common is, I'll get into a little bit later, they have a bunch of wrapper scripts that go around a lot of the binaries that come with Postgres and that's all contained in the common package. And libpq is also its own library if you're doing any C development in Postgres. Those are actually tied to, and I'll get to a little bit later too, there's default packages. Both common, you see common and libpq 5 don't actually have a version number associated with them. They are associated usually by default with whatever the latest version of the package you have installed. So if you installed 9.6, common and libpq are associated with 9.6. If 9.5 is the latest one, if you have 9.5 and 9.6, by default it's associated with 9.6. There's ways to control that as well. When you install the main package, server package for Debian, it does set up a default cluster for you. It runs in it DB for you, sets up a service and starts it up and you're all up and running just by installing that one package. So it's very easy to use. As I said, for common and libpq they're associated with a specific version. If you, if for some reason you need a specific version like you, you want to install 9.6 as you want to test for upgrading, but you need the 9.5 version of libpq or common. You can, this is something you can actually do for any package in Debian or Ubuntu. You can pin the versions. It's basically you go and you just, you can call the file whatever you want, but it looks in this preferences.d folder in the apps config folder. And it follows this basic pattern. So any, any package that starts with postgresql.star and libpq and libpqdev, I want to stay, I want this package to stay it on postgres 9.4.6. It actually pins it to the minor version. So if you need to do that, that's a very easy way to do that. We actually had a client that had some custom libpq code that I think it was the 9.3 binary for some reason broke their 9.1 libpq code. So they had to do this. File locations, I actually, one of the main reasons I wrote, did this talk was for reference for myself. This slide is one of those references for myself of where you can actually find the default locations, mostly the binaries, as we'll get to later when I show you the wrapper scripts. You can, the wrapper scripts are all in user slash bin, but if you actually need the real PGCTL or something like that, this is where it's actually located at. They do have a different major version number. So if you have 9.4, 9.5, and 9.6 are installed at the same time, they all go in their same, in their own folder. So you can have them all installed at the same time. This, this folder is actually pretty important. If you ever install extensions, and you need to know where to put the files yourself, that is the folder where that would go. And for config file, normally by default, in like the default Postgres install, the config files are in the data directory. Debian is very strict on their file hierarchy. They want all config files in the etsy folder. So they have all of these files located in the etsy folder with the 9.6 and then a cluster name, which I'll show you later. As well, the log files are usually in the data directory, on Debian, they're in var.log, or var slash log. So to have the service automatically start up, there is a very simple file. It's located in this directory, sorry, this directory, the etsy Postgres.com directory. There is a start.comp file. There's only one value you have to put in there. Auto will automatically start the service when the server starts. Manual lets you still use the wrapper scripts to start the cluster, but does not automatically start the cluster when the server starts. And disabled, disables the wrapper scripts from working and disables it from starting. You can still manually start the server yourself if you know how to with PGCTL and that kind of stuff, but it stops the services and stuff from being able to start the cluster. Default access for the database. There's a system user called Postgres, as well as a role in the database called Postgres, which is the super user. This is the default pghba.conf right here. Basically what this means is only local system users can log in via socket with no password. And you have to have a matching role in the database to your system user, that's what peer means. So if you're the Postgres user, you can log into the Postgres database without a password. If you're your user, you cannot log into the Postgres database without a password. And for all other new roles via TCP, it requires a password. So for any external connections, you need a password. And by default, it does not allow remote connections into the database. By default, it only allows local connections. If you've seen news recently about how MongoDB installations and some other database, their default configuration leaves them open to the world. Postgres' default configuration is not to be open to the world. And this, that last one in the Postgresql.conf is how it does that. By default, when it's either commented out or the default value is local host, so only local network and socket connections are allowed. So this is the specialty thing with Debian as it has these wrapper scripts. So the create cluster is pretty much a replacement for initDB. It automatically creates new data directories, automatically picks the next available port available and sets up a new cluster for you, starts it up, sets the services up, and everything's all up and running with that one command. Easily supports multiple major versions and multiple minor, multiple clusters on the same minor version as well. This is just basically a replacement for pgctl to, and I'll show you a little bit later the command line options for it. There is a wrapper for upgrading and I highly recommend not using it, especially if you've never run pgupgrade. Because if everything, if it works and it just works, it's fine. If it doesn't work and you've never done pgupgrade and you don't know how pgupgrade works, you have no idea what it did and you have no idea what went wrong. It's good to use if you know what it does and how to debug things. If you've never done it, I don't recommend using it at all. So my recommendation is to use pgcreatecluster to create your new clusters and then manually edit ports and all that kind of stuff around it to do your pgupgrading. LSClusters just basically lists all the clusters that the wrapper scripts are managing for you. Obviously rename, rename's a cluster for you and then there's a PSQL, it's actually a wrapper. So actually let me do switch out here and do a little bit of a demo here to show how it works. So this is a, we can see that, this is a clean Debian install. So if you actually look for, you can see the latest version of Postgres available is all nine four and there's not really too much else Postgres server related. So if we go over here, basically they give you this nice little command right here to add the repo to your system pretty easily. So that just basically made this pgdl list and so I've added the app repo for you there. Okay, there we go. So now if we look at Postgres packages now you can see there's a whole bunch of other stuff available now. Goes all the way back to eight dot four for packages that are available. So if we go ahead and install, thankfully Wi-Fi's cooperating today. You can see now it's setting up a cluster for you. Do change to the Postgres user. So if I try to log into the Postgres line out myself to the database says I don't have a role named Keith in the database, it won't let me log in. If I try to log in as the Postgres user, peer authentication failed because that's the default that set up, you have to have the same, you have to be that user to log in as that user. So I have 962 up and running just with a single package install. And so if you do a pgls clusters, see this is how the cluster management works. It has the major version number than the name of the cluster's main port 532. So if I do, let's see, pg6, I call it test. Now we have a new cluster. So it should start up by itself eventually. But now you can see it automatically picked the next port and you have a new one up and running. If you set that install and go back to the talk here. So one of the other things you can do, and this is pretty much in general for any package that Demi manages that has a system called update alternatives. So if you see that the psql is actually a wrapper script that's actually, if you install 9.5, 9.6 and 10 all at the same time, psql will automatically always be with the latest version associated with the latest version of Postgres. So this is a way you can manage it with this update alternatives command. If you do this get selections, you can see that there's two alternatives that Demi manages for you. This first one is basically the server and stuff and this pgsql is all like the commands like pgjump and itdb and all those commands are all managed by that alternative. So if you wanted to see what, if you had 9.6 and 9.5 installed and you wanted to see what was available for the psql alternative, you can see there's 9.5 and 9.6 are both there available to you. If you actually want to see what they manage, you can give a display and it'll show you everything that it actually manages. So if you actually want to change this, you can use the config option and then give it the alternative you want to change. So there's options. You can actually pick the one that starred is the current one and is also, there's also one that's always set to automatic. So to automatically always choose the latest. That's the one that's automatically chosen. So it goes by these priority lists. So it just uses the psql version as a priority. So it's easier to see what it is. 9.6 is a higher number than 9.5. So that's the one that's automatically picked when you install the new version. If you want to go change 9.5 if you want to, you can just use selection one and change those as needed. So you can see it automatically set up a 9.5 cluster for us, also called main. So as long as the major version is different, you can have the same name on these. Managing multiple databases on Debian is very, very easy because of this. It does abstract a lot of things for you that you don't have to manage on your own anymore. But once you are familiar with how all that stuff works, it makes managing all this stuff easier. Makes doing upgrades a lot easier. Makes getting test instances up and running very, very easy. Good old system D. So the PGCTL cluster actually redirects to the system control for the control cluster for actually starting and stopping your instances. Actually redirects to using system D CTL. So system D is actually aware of starting and stopping the services. Make sure you are on the latest version of Debian if you need to use system D with Postgres. The early versions of Debian 8, system D was not aware of Postgres services. So if you stopped a cluster without system D, system D still thought it was running. If you started the cluster without system D, system D had no idea that it was running. And it caused all kinds of confusion and trying to actually get it, tell it to start and stop the right way was confusing, especially before 9.6. When the default for the, if you ever do a stop command for PGCTL, the default used to be a smart shutdown which would wait for all connections to start to disconnect before it would actually shut down the database. When system D was not aware of that and there was no way to tell system D to shut down the Postgres with the fast option which forces all things to disconnect. So if you ever tried to use system D to shut down Postgres, it would never shut down if you had an active connection. It was not fun to manage. So, and then if you did shut it down, you had to then go somehow tell system D the Postgres was shut down. They fixed it all with the latest versions of Debian. They've gotten system D integrated with the wrapper scripts and the Postgres services. So if you have to do this, just highly recommend you're on this latest version of Debian. Any questions about Debian or Ubuntu Postgres management? Next, I'm gonna talk about CentOS. I know the latest version of CentOS is actually seven but I actually, I haven't run CentOS seven with any clients so I'm not quite as familiar with it and seven actually now uses system D as well. So I don't know of all the idiosyncrasies but I still have a lot of clients on six and I think a lot of other people I have talked to were still on six. So that's pretty much what, the way this is presented is for CentOS six. Obviously things will change for seven. One thing I don't think it changed was seven and I think eight four is still the default package. So you definitely do not want to be using the OS provided package for on CentOS systems. Just like Debian, there is a Postgres community that maintains repositories for them. So it's not quite like the Debian one where there's just one repo. You've installed one repo and they're all available to you. There is actually a specific repo for each major version as you can see here and for each different version of Red Hat or CentOS. So you just have to make sure you grab the right one for that and also they include some similar third party tools the same way the app repo does. So if you need like PG Bouncer and PostGIS and all that kind of stuff this is a great way to get the packages for that. So this is actually the opposite of Debian. The client package is the one without the special name on there. So if you actually need the server you have to install the server package. If you just need the client do the one without the name. The server one does install the client. Same, there's a contrived package the same way. And the development package for compiling yourself. It does not have separate packages for libpq. I believe those are included in the server. You know the server or the development package. I don't remember. And there are no wrapper scripts for CentOS you're just pretty much, there is one, I'm sorry, I'll get to that later. There's no cluster management wrapper scripts like there is for Debian. There are still wrapper scripts for doing managing multiple versions. So default instance is not created upon installation. So you have to actually do that yourself. But a service is set up for it. So and the service actually has an NADB command for it. So using the service to initialize a cluster will install the default system for you in the default locations. But this only manages one instance for that major version. If you need to do multiple instances, I'll get to that a little bit later. So if you need to do additional instances you have to use the normal NADB binary yourself to make more instances. There's nothing to manage it for you like there was in Debian. So data directories, mostly similar. Data directory has its own major version. The config files are located in the data directory unlike Debian. So this is the default. As well as the log files are also in the data directory which is usually the default if you're compiling from source. One thing that throws people off though is there is a separate startup log if you use the service. So if your server doesn't start it's usually not gonna be in the Postgres log because the service command redirects the things before the database actually starts to this startup log. So if it doesn't start you have to go look at that log file and not in the PG log data folder in your data directory. So that throws me off, still throws me off sometimes. This is pretty similar to CentOS as far as the defaults. Ident and peer in practice do the same thing. You have to have the same system user as the database user to log into the database. But it also if you, getting into what an IDENT server is is beyond this talk. But this also allows you to use an IDENT server to log in as well. The thing is for default TCP connections is to contact the IDENT server so it's not using a password authentication by default for remote connections either. So you have to add that in. But thankfully the default is to still not allow remote connections in by default. So you have to change that. There's an update alternatives on CentOS just like there is on Debian. It's got slightly different command line options. You can see all of the alternatives that are available. So if you go to our level alternatives on CentOS you can see there's actually many things it manages. But you can see that each binary has its own individual alternative. So unlike with Debian where you just update the PSQL alternative package to update all the binaries. If you need to update the default version binaries on CentOS you have to do it for each individual command like PSQL, PGDOM, NetDB. All of those are all alternatives. So you kind of have to, it's a little bit more of a pain to manage but it's more customizable. One thing that's also a little bit different too is when you run the config command there's no option to choose the automatic one. In the config you actually have to pass the dash dash auto command to have it automatically pick whatever the highest priority alternative is. In this case it's nine five and nine six. So the star is the current selection and the plus is what auto is set to. So since there's no cluster management scripts there's no simple way to have multiple versions or multiple clusters running on CentOS like there was with Debian. But it's not actually not that bad. You basically just, well prior to 9.0 there actually was no way to do this because the packages all install the binaries all to the same place. There was no major version folder for the binaries. So you could not have multiple major versions prior to Postgres 9.0 on any CentOS. But as of 9.0 every package goes into its own major version folder. But so to make multiple services it's basically just making a copy of the entity file. So if you could call up Postgres QL dash nine six main nine six tests just name it whatever you want. And these are, there's quite a lot more in the file than just these things but these are the main things that and it's kind of hard to see here. See, I can't make it any bigger unfortunately. But the main one are like the data directory the PG data directory the PG log directory. You can customize where it's putting the PID files. The other, the one thing that throws people off and it threw me off for a while too is if you scroll down in the service script there is this overrides section. And I guess it's been like a standard thing in CentOS and Red Hat to you have the service file that pretty much controls most of it but then there's this override which overrides the data directory in the port. So you can set the port and the data directory in the config file but then if you look down further there's this override and if that exists it overrides whatever you put there. Also if you set the port here this overrides whatever port you set in the Postgres QL.com file. So things to be aware of that you go and change the port in your Postgres QL.com and it doesn't change anything when you start and stop the service. That's because the service is the one that's actually defining the port. So just look over the service script carefully and make sure it's doing what you want. You don't have to do this override but it is there in almost every service file on CentOS that I've seen. So it's all depending on whether somebody actually decides they wanna use it or not. That's it for CentOS. Run a little bit short on time so I'm gonna skip the demos unless people really wanna see them. Oh yeah, sure. If you compile from source yourself. No. No. And actually I actually do go over compiling from source at the end for a little bit but the source does come with some example in its scripts for you but it doesn't automatically install them. If you use a compile from source you pretty much you're telling it where the binaries go and you're responsible for setting up the service and stuff yourself. Yeah, yeah. Yep, sure, nope. Yeah, yeah, yeah. Honestly, and if you're doing this for production systems I recommend just going with the package if you can. It's because they make their own, there's repositories that keep the most recent versions out pretty much and keep them up to date. For production systems where you need to keep things consistent there's honestly no reason not to use the package. That's a bit beyond me. I don't know if you can customize where the package is putting things. So, they're, I think so. I don't really know the ins and outs of how you can tell Yum the word to put things but maybe. But yeah, if you have to put it in your own custom place there's no way around that. Yeah. So I don't actually run FreeBSD for any clients. I just, I run FreeBSD myself for my own servers. So I figured I'd look in to see how Postgres manages FreeBSD and share that with people as well. So on FreeBSD there's two ways to install software. PKG is like pretty much the way Yum and Apget are on the other, on Debian and CentOS. But FreeBSD also has the port system which custom compiles the software during ad installation kind of like Gen2 and that kind of stuff. Actually I prefer using ports myself just because it kept up, kept more up to date. As this example shows FreeBSD 11 is actually the most recent version but back on 10.3 package still only has 9.5 as the latest available version. But if you install from ports on any version of FreeBSD 9.6 is available. Actually they may even make 10 available in development for some, on some port trees. But either way package or port, the installation result is the same. So either way you do it, thankfully it's consistently the same for both. Four simple packages, server, client, contriven, docs. There's not anything more than that. Most of the extra stuff you see on the other operating systems is either in call put in server or client. So kind of have to look and see what you need. Most of the time I just install both the server and client and then I have everything I need. Does not create a default cluster on installation by default so just like CentOS. And there's a service system or FreeBSD revolves around this rfc.com file in Etsy. There's also one in user local Etsy to for most custom things. And each software package has its own thing that'll tell you as part of the setup of how to actually start the service using FreeBSD. And for PostgreSQL you add this command to the rfc.com and that automatically starts any PostgreSQL services you have defined. The package does have a, the service command does have an NITDB just like CentOS did. And that'll make things in the default locations which I'll show you in a second and you can pretty much start and stop the service like you would normally on any system. So one nice thing about the first, the first time I did this talk was actually or actually second time I did this talk was in at PGCon and thankfully if you know who Dan Langwell is he's a big BSD guy. He's one of the people that came to my talk and realized how bad Postgres package management is on FreeBSD. You cannot install multiple, and you still can't. You cannot install multiple major versions of the packages at the same time. Ports are packaged, it just doesn't work. But at least they're getting there. So as of nine six, like before that it used to be just be, there's one data directory. Now it actually defines a nine six data directory. Things still aren't fixed as far as the binaries and stuff, it still all puts them in the same location. So still working on getting things fixed. The one thing that I don't like about it is it defaults to doing syslog. If you use this login, that's your preferred logging method, that's fine, but most people don't. So it's recommended to go in and change the default logging directory to scder, you can look in the Postgresql.com for what that means, but that just basically allows you to define where the logging is done yourself. The default users in access, this is actually, if you compile Postgres from source, this is the default hba.conf you get. So all local users, socket and TCP, are able to log into the database without a password, no matter what, to all databases. So but that is a default, okay, thank you. That is a default for Postgres, source and compile as well. So it's not unusual for that to be, but it's still only allowing local connections. So as long as your system's not compromised, allowing anybody to locally log into the database usually isn't a bad thing. But it is good to be aware of this, if it's a multi-user system that you don't want everybody logging into the database, you definitely want to go in and change this. So multiple major and minor version packages are not supported at the same, oh actually that was one of the things they did too. So prior to 9.6, the system user was pgsql, which really confused a lot of people because it's the only system that doesn't have Postgres as a system user. So and basically whatever user initializes the database, so if my username's Keith, if I do an intdb, the role that's created in that cluster is your system username. So the other ones, the Postgres system user is the one that initializes the database, so there's a Postgres role in the database. For EBSD, the role is called pgsql, so the default role in the database is pgsql. So they're actually changed that in 9.6, so the default system user is now Postgres and the default role is now Postgres. So thankfully I'm starting to make things more consistent. So using, as I said, you can't have multiple major versions installed and because of that, the only officially supported way to do upgrades in FreeBSD is to pgdump, shut down the database, install the new package which uninstalls your old package so you no longer have it available and then start out the new cluster. So if things don't go right, you're kind of in a bit of a bind there. So the easiest way to do it on FreeBSD now is to actually just install the source yourself to some custom location, mainly create the new data directory structure, run pgupgrade yourself and then install the new packages. So that way you can, at least, you still have your old cluster, you can go back to it, nothing's overwritten, you can go roll back if you need to. So for right now, if you run FreeBSD, I would actually recommend and you need multiple clusters or if you need to be able to easily do upgrades, you can't have a lot of downtime for upgrades, I recommend not using the packages, like you're saying, install from source and just manage it yourself for FreeBSD at this time until they get multiple major version support included. As I said, and actually, if you're using the packages, like I said, there's an initdbservice command. Actually, I have to update this, this is not true as of 9.6 anymore, then it doesn't create a version data directory as of 9.6, it actually does do that now. There actually are, if you decide to have the data directory in a different location or the binaries are in a different location, that rc.com file where you defined to start up the service, there's this file in most FreeBSD ports, if you go into the ports tree and look at this, there's this .in file, it'll have different options that you can put in the rc.conf that are available for that package, so for Postgres you can define in rc.conf where the data directory is, any special flags you always want to pass to the CTL command and any other initdb flags you always want to send, but rc.conf does not support multiple cluster definitions, so you can't define the data directory more than one data directory here, there's no way to do that via rc.conf, so if you have to run multiple clusters, but there is still a way to run multiple instances on FreeBSD and it's pretty much the same way for CentOS did. You make a copy of, so the service command, the service looks in a local, user local at CD, rc.d for a service file, all you do is make a copy of that file, it starts up every file it finds in that rc.d service folder, so if you have multiple clusters defined there, the service system will automatically start them up for you, so it is possible to run multiple clusters, just takes more effort just the way CentOS currently does right now, and there's a bit beyond this talk right now too, but a lot of people actually also use just run Postgres in a JL and then you can run as many as you want on as many different JLs as you want on the same system. They're all kind of, their own little independent systems. Any questions about FreeBSD? All right, lastly, compiling from source, so if none of the packages options work out for you, Postgres compiling from source is actually one of the most easiest packages to, software packages to compile from source that I've come across, so actually if you're comfortable with doing this, I don't see any reason not to, but if you have to manage many, many systems and keep them all consistent, obviously the packages are much more easy to do that with, but if you have to compile from source, Debian just requires these three packages. Build Essential basically puts all the, all the compilers and everything installed for you, and then Postgres itself needs Reline and Zlib. For CentOS, there's this group install called Development Tools, which is the same thing as Build Essential that installs all your basic compilers and all that kind of stuff for you, and again, it also needs Reline and Zlib. FreeBSD, the only thing, the only package that I needed to install that wasn't there was Gmake, because you need GNUmake for Postgres, you can't use the make that BSD comes with, so that's the only thing that was required on FreeBSD, and if you're actually pulling things from the source Git repo, you'll see these warnings about needing Bison and Flex, I think it's for like a document compilation and stuff like that, so you don't need the development packages for that, you just need the normal Bison and Flex packages if you're doing the Git repo. Some useful compilation options. I always recommend this first one. It's not there, but it's not on by default. The distribution packages and stuff usually have all of these set already, so you don't have to go and go back and recompile them to get these options, but if you're compiling from source yourself, these are not by default. Postgres does not compile with OpenSSL, so if you need that, definitely turn that flag on, and if you need any other authentication mechanisms, they actually have their own compile flag that you have to set. There's three languages that come with Postgres, as far as external languages, Perl, Python, and Tickle, so if you need any of those, you get to set that flag. If you're doing development on Postgres, I highly recommend setting both debug and assert, especially debug, because if you come across a problem and you have to talk to hackers, they won't even help you if you have no debug output, so I highly recommend turning that one on. And then to actually compile and make it, there's the special flag to make called World that actually, if you just do make, that compiles none of the contrib modules, and you can go back and compile each contrib module you need on an individual basis if you want, but I find it's just easier if you give it World. It compiles all the contrib modules for you automatically, or you can just go straight to make, there's install-world that compiles it and installs all the contrib modules for you in one step. The Postgres source does come with some sample service startup scripts for most operating systems. I actually don't recommend using those though. What I would recommend is installing the package and use the service script that the package makes, because it's much more extensive, and these are not really tailored to keep up with new operating system options that are available in services and that kind of stuff. They do their best to keep up with it, but that's not their primary job, that she was the job of the operating system maintainer, so I'd recommend looking at the startup scripts that the package is installed and use those versus using these that come with the source. And you can configure where the binaries are installed. I recommend doing just the major version, so I usually install the opt, is where I usually install custom software locations. If you do it for each minor version, you run into the problem that your extension source is not, like if you use other third party extensions, those are located in that binary installation directory, so if you have each minor version going into its own folder, whenever you upgrade a new minor version, your extension libraries and files are no longer available in that new folder, but if you install them, if you install the new minor versions, just overwrite the current location, which is the major version number, which right now is like the first two numbers, but as a 10, there'll just be one version number, so. And then from there, you can just do a, like if you want to just, like if you set your path to always look at the latest, so you have PSQL in your path so you don't have to do the full thing, you can just do a sim link for like, this is a PostgresQL95, then you can just point your sim link to opt slash PSQL slash bin, and then whenever you update the Postgres to the new major version, update the sim link. Data directory should also be versioned, so you can easily do PG upgrade and have a 95 directory, then a 96 directory, you can have the cluster in the one, but the thing with that is, do not have that major version on a different mount point, so you can have, thank you, you can have like the PG data directory, that be a mount point, but then make folders for 95 and 96, don't make them their own mount points, because then PG upgrade, there's a link option to PG upgrade that allows it to do hard links and significantly speed up your database upgrade, like I did a one terabyte upgrade in 45 seconds using the link option, but it has to be on the same mount point, you can't do link across mount points, so that's just a tip for when you're making your own custom data directory, just have the major version number be a folder and not a mount point, that's it. Go back to the beginning here, I'll give you the way where these slides are located. Any questions? Yeah, yeah. So for upgrade, what is the best way to upgrade, so like having use for this, and PG dump sort of thing? I mean, if you have the time for a PG dump and restore, that is always the best way to do an upgrade, in my opinion, but most people don't have that time for an outage, so like I said, make sure the current data directory and the new data directory are on the same mount point and then just use PG upgrade to go from one to the other and then you can use the link option and keep things going pretty, excuse me, keep things going pretty quick. I will say that upgrade did only take 45 seconds, but when you do a PG upgrade, the statistics are not up to date on the new cluster, so you have to run an analyze on the new cluster for it's actually useful, that took another hour after that, so upgrade's not quite as fast as it could be, but even if you do a PG dump, you still have to do the analyze anyway, so yeah, sure.