Download from Enterprise DB, gui is the one to go for, remember xhost on linux
1. Install. For prod you should indicate that data files are stored independently of the source tree. A ‘Cluster’ is not a classic Cluster IE: a Server Cluster, just means all the databases on this particular box.
2. Explore the footprint of the install. ‘\\bin\ contains utilities like psql.exe (terminal monitor). \\data\ contains all databases and 3x config files & pg_log/ (log files), pg_xlog/ (write ahead log folder). postmaster.opts (startup options)
3. Provide access to internal docs via web-browser bookmark eg: file:///C:/Program%20Files/PostgreSQL/9.5/doc/postgresql/html/index.html
4. Add \\bin file to path – for psql.exe etc (eg: C:\Program Files\PostgreSQL\9.5\bin). posqlgresql clients default to submitting the current logged-in users name as the DB user name (eg: “psql” without -U will assum user is windows-user).
5. Add system variable ‘PGUSER=postgres’ workaround so psql etc wont try to login to utilities as o/s-user
For Rob & Karl – Triggers run outside of transactions. An insert that fires a trigger may be rolled back, but the trigger rolls on.
Triggers introduce a long-term maintenance headache. You can read a stored-procedure from top to bottom and imagine you understand what it does. But unless you examine every tables it touches – you don’t. Little bits of code may be running silently which augment or even reverse some of the logic within the stored-procedure.
Triggers are used by lazy developers to ‘bolt on’ new features to applications, rather than track-down all the code that could insert/update/delete from a table and add the code (or a link to it) there.
This would be forgivable if the application code was closed or propitiatory, but never when the application is open to the application developer, who just cannot be bothered to integrate code changes properly, and cares not-a-jot about long-term maintenance headaches (slow breaths, slow breaths :))
Scripting languages are wonderful things. They use subsets of English and are therefore easy to learn (EG: update, delete, get, put).
However capitalization is totally redundant. A capital letter marks the beginning of a sentence, but scripts do not use sentences.
One alphabet is enough (a to z) who needs another one (A to Z) that is completely equivalent?
Imagine responding to the adhoc query “Please email me a list of most ordered items over Christmas” with “in what font?” lol
Although … one trick that I have used over the years, with having two alphabets, is to temporarily change the capitalization of text to double-check for myself that Replication etc is actually working (before the days of tracer-token poo sticks). Changing the data look without changing the data value.
Another sneaky trick is making mass changes to data whilst adding a flag (to only the changed data). For example changing every field containing ‘unsubscribe’ to ‘uNsubscribe’, or ‘yes’to ‘yEs’.
And then repeating with un-flagged fields until only ‘unsuscribe’ or ‘Yep’ remain (lol).
This (typical DBA belt & braces) method almost always guarantees you will not induce any unintended processing errors further down the line, as the data always remains the same length, type and meaning.
Autonomy, Mastery, and Purpose.
- To prioritize their own time.
- To master their profession.
- To do important work that matters.
In a SQL deadlock graph the direction of the arrows is an interesting thing.
With my mechanistic head on, I am imagining it as …
- Spid-a requested a lock, and then got a lock (a two-way trip)
- Spid-b requested a lock, and then got a lock (arrow ends-up pointing at spid)
- Spid-a requested a lock, and is waiting (a one-way thing)
- Spid-b requested a lock, and is waiting (arrow pointing away from spid)