![]() Server ~]$ ~]$ psql -c 'SELECT version()' She decides to run a quick sanity check: postgresql-11.8]$ cd ~]$ export ~]$ initdb ~]$ pg_ctl -D ~/test -l logfile start Success! She’s built and installed Postgres - she thinks. Her data analysis makes use of some old Perl modules so she makes sure to configure Postgres to build with PL/Perl. ![]() Not wanting to bother the lab’s resident gray-beard, she decides that she’ll build, install, and run Postgres in her home directory. She would like to use Postgres to help with her data analysis but she doesn’t have root access on the lab’s shared infrastructure. Our story begins with Cardenia, a graduate student in a research lab at university. Rather than getting bogged down in the particulars of our team’s use case, let us consider the following hypothetical scenario that highlights the key ideas and findings. And they need to be able to do this independently of where the Greenplum software has been installed on disk. This means that the binaries and libraries from the different Greenplum installations need to be able to load their associated shared-objects at runtime without accidentally loading a shared object from the other version. In order for the gpupgrade utility to successfully upgrade a cluster, it needs execute code from both major versions, potentially at the same time. This utility allows users to upgrade their Greenplum cluster from one major version to the next, in-place. Why were we looking at creating a relocatable build of Greenplum Server? The first beta version of gpupgrade was recently released. Our team was working on producing a relocatable build of Greenplum Server which led us to looking in to how to do relocatable builds of Postgres. Greenplum Server is based on Postgres and has inherited the upstream build system. ![]() As engineers on the Greenplum Release Engineering team, we recently had the opportunity to do an in-depth exploration of Postgres’ build system. ![]()
0 Comments
Leave a Reply. |