Re: Question: PostgreSQL on Amazon linux EC2

[Christopher Browne]

On Mon, 6 Jul 2020 at 15:55, Ajay Patel  wrote:

> Hi Postgres team,
>
> I would like to know if PostgreSQL can be installed and used without any
> issues on Amazon Linux EC2 machines.
>
> https://www.postgresql.org/docs/11/supported-platforms.html
>
> I was going through the documentation and couldn't find very specific
> details related to support.
>
> Any input will be much helpful.
>

 In a way, this is not a whole lot different from asking,

"I would like to know if PostgreSQL can be installed and used without any
issues on Dell server machines."

In that case, there could be questions about whether there are good drivers
for disk controllers that would vary from model to model, and some things
like that.  But there are few up-front answers the way there used to be for
how to handle (say) different versions of AIX.

Amazon EC2 provides virtualized "gear" that simulates x86-64 hardware
reasonably decently; there can certainly be performance issues relating to
how fast their simulated disk is, and how fast their simulated network is.

But there are no highly-specific-to-EC2 details related to hardware
support, as you noticed on that web page.

If you do not have performance or load requirements that are so high that
they point at edge cases where the EC2 virtualized environment starts to
break down, then it's probably mostly smooth sailing.

You need to be aware that they do not promise super-high-availability, so
you should be sure to keep good backups lest your server gets dropped on
the floor and you lose all your data.  I'm not sure there's good stats just
yet as to how often that happens.  But it isn't difficult to provision a
pgbackrest server that will capture backups into S3 cloud storage to help
protect from that.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: New 'pg' consolidated metacommand patch

[Christopher Browne]

On Wed, 27 May 2020 at 16:49, Isaac Morland  wrote:

> On Wed, 27 May 2020 at 16:00, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>
>> Also consider some practical concerns with the command structure you
>> describe: Tab completion of commands wouldn't work anymore, unless you
>> supply custom tab completion setups.  The direct association between a
>> command and its man page would be broken.  Shell scripting becomes more
>> challenging:  Instead of writing common things like "if which
>> pg_waldump; then" you'd need some custom code, to be determined.  These
>> are all solvable, but just a sum of slight annoyances, for no real
>> benefit.
>>
>
> I don’t think the man page concern is justified. We could have a “help”
> subcommand, just like git; “git help add” is (to a casual observer;
> probably not precisely) the same as “man git-add”.
>

There's some very small gulf in between the concerns...

- On the one hand, git (and systems with similar "keyword" subsystems) have
arrived at reasonable solutions to cope with various of the systematic
issues, so that these shouldn't be considered to be gigantic insurmountable
barriers.

Indeed, some of these tools present systematic solutions to additional
matters.  I was very pleased when I found that some of the Kubernetes tools
I was working with included subcommands to configure my shell to know how
to do command completion.  Seems like a fine thing to me to have that
become systematically *easier*, and I think that would be a good new
subcommand...  "pg completion bash" and "pg completion zsh" would be mighty
fine things.

- On the other hand, mapping old commands that are names of programs onto
"pg subcommands" is some additional effort, and we haven't yet started
bikeshedding on the favoured names :-)

I have lately noticed some interesting looking apps wandering about that
briefly attracted my attention, but, which, due to being painfully
different from the existing commands and tools that I have already learned,
and have "muscle memory" for, am loath to leave.   I'll throw out 4
examples, 3 of them personal:
a) nnn is a terminal-based file manager.  It has some nifty features
surrounding the concept that you can set up custom file filters to look for
sorts of files that you find interesting, and then offers customizable UI
for running favorite actions against them.  I'm 25 years into using Emacs
Dired mode; as neat as nnn seems, it's not enough of an improvement to be
worth the pain in the neck of relearning stuff.
b) 3mux is a redo of tmux (which was a redo of GNU Screen), and has key
mappings that make it way easier for a new user to learn.  I'm 20-ish years
into Screen/Tmux; I wasn't looking for it to be easier to learn, because I
did that quite a while ago.
c) Kakoune is a vi-like editor which rotates from vi's "verb/object"
approach to commands to a "object/verb" approach, for apparent more
efficiency.  I think I already mentioned that my "muscle memory" is biased
by Emacs features...  I'm not adding a "rotated-vi-like" thing into my mix
:-(
d) systemd is a Controversial System; the folk that seem particularly irate
about it seem to be "Old Bearded Sysadmins" that hate the idea of redoing
their understandings of how Unix systems initialize.  Personally, my
feelings are ambivalent; I'm using it where I find some use, and have not
been displeased with my results.  And since modern systems now have USB and
network devices added and dropped on a whim, there's a critical need for
something newer with more dynamic responses than old SysV Init.  But I
certainly "get" that some aren't so happy with it, and I'm not thrilled at
the ongoing scope creep that never seems to end.

There is merit to having a new, harmonious set of "pg commands."  But it's
eminently easy to get into trouble (and get people mad) by changing things
that have been working fine for many years.  Half the battle (against the
"getting people mad" part) is making sure that it's clear that people were
listened to.  Listening to the community is one of the important things to
do :-).
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: Just for fun: Postgres 20?

[Christopher Browne]

On Wed, 12 Feb 2020 at 08:28, Alvaro Herrera 
wrote:

> marcelo zen escribió:
> > I'd rather have releases being made when the software is ready and not
> when
> > the calendar year mandates it.
> > It seems like a terrible idea.
>
> But we do actually release on calendar year.  While it seems not
> unreasonable that we might fail to ship in time, that would likely lead
> to one month, two months of delay.  Four months?  I don't think anybody
> even imagines such a long delay.  It would be seen as utter,
> unacceptable failure of our release team.
>

All said, I think there's some merit to avoiding a PostgreSQL 13 release,
because
there's enough superstition out there about the infamous "number 13."

Perhaps we could avert it by doing an "April Fool's Postgres 13" release?
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

[Christopher Browne]

On Fri, Jun 14, 2019, 3:12 PM Tom Lane  wrote:

> A possibly better idea is to push back on tzdb's choice to unify
> these zones.   Don't know if they'd listen, but we could try.  The
> UCT symlink hasn't been out there so long that it's got much inertia.


One oddity; AIX had a preference for CUT with fallbacks to CUT0 and UCT
back when we had AIX boxes (5.2 or 5.3, if my memory still works on this).

We wound up setting PGTZ explicitly to UTC to overrule any such fighting
between time zones.

There may therefore be some older history (and some sort of inertia) in AIX
land than meets the eye elsewhere.

That doesn't prevent it from being a good idea to talk to tzdb maintainers,
of course.

Re: Syntax diagrams in user documentation

[Christopher Browne]

On Thu, 28 Mar 2019 at 17:56, Peter Geoghegan  wrote:

> SQLite has a bubble generator tool that they use to generate syntax
> diagrams for their documentation:
>
>
> https://www.sqlite.org/docsrc/doc/tip/art/syntax/bubble-generator.tcl?mimetype=text/plain
>
> I think that the results are rather good. See, for example, the INSERT
> documentation:
>
> https://www.sqlite.org/lang_insert.html
>

neato!

(And no coincidence that GraphViz has a command by that name...
https://www.graphviz.org/pdf/neatoguide.pdf)

An especially cool idea if we could automatically dig input directly from
src/backend/parser/gram.y
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: Contributing with code

[Christopher Browne]

On 2 January 2018 at 17:52, Peter Eisentraut
 wrote:
> On 12/31/17 22:43, Craig Ringer wrote:
>> I'd rather rename it the "stuck, hard and abandoned projects list" ;)
>
> That might actually be useful.

Yep, agreed.  Though it might do better to describe it in *slightly*
more positive terms, and/or to explain the matter in a bit more
detail...

"TODO notes...   This page has collected together a variety of
proposed projects to enhance PostgreSQL.  Newcomers should beware; the
fact that these proposals have not been implemented should be taken to
indicate that they represent approaches that are difficult, have
gotten stuck, or even that have been abandoned due to having drawbacks
exceeding the imagined advantages.  Be sure to discuss proposals on
the pgsql-hackers list before getting too far into implementation,
otherwise there is considerable risk of wasting effort on a patch that
is likely to be rejected."

-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"