Monday, February 18

Tag: git

Maintaining feature branches and submitting patches with Git

Eisentraut's PlanetPostgreSQL
I have developed a particular Git workflow for maintaining PostgreSQL feature branches and submitting patches to the pgsql-hackers mailing list and commit fests. Perhaps it's also useful to others. This workflow is useful for features that take a long time to develop, will be submitted for review several times, and will require a significant amount of changes over time. In simpler cases, it's probably too much overhead. You start as usual with a new feature branch off master git checkout -b reindex-concurrently master and code away. Make as many commits as you like for every change you make. Never rebase this branch. Push it somewhere else regularly for backup. When it's time to submit your feature for the first time, first merge in the current master branch, fix any (more…)

Testing new PostgreSQL versions without messing up your existing install

Craig's PlanetPostgreSQL
People are often hesitant to test out a new PostgreSQL release because they're concerned it'll break their current working installation. This is a perfectly valid concern, but it's easily resolved with a few simple protective measures: Build PostgreSQL from source as an unprivileged user Install your PostgreSQL build within that user's home directory Run PostgreSQL as that user, not postgres Run on a non-default port by setting the PGPORT env var If you take these steps the install its self cannot interfere at all. Starting and running the new PostgreSQL can only interfere by using too many resources (shared memory, file descriptors, RAM, CPU, etc) and you can just stop the new version if it causes any issues. The shared memory improvements in 9.3 make the shared memory (more…)