Re: doc: Document how to run regression tests with custom server settings
On Mon, 21 Jun 2021 at 15:43, tanghy.f...@fujitsu.com < tanghy.f...@fujitsu.com> wrote: > Hi > > I was doing regression testing according to the PG-doc at [1]. > The modification at 854434c5 seems not correct, could you please take a > check at it? > > >make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB" > > The above command reported an error like this: > failed: FATAL: parameter "log_checkpoints" cannot be changed now > > IMHO, as a sighup GUC, log_checkpoints can't be set in PGOPTIONS, is that > correct? > > >make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf" > > pg_regress: could not open "test_postgresql.conf" to read extra config: No > such file or directory > > I fixed above problem using command like this: > make check EXTRA_REGRESS_OPTS="--temp-config=$(pwd)/test_postgresql.conf" > > Maybe we can change doc description to tell user he/she should specify the > location of " test_postgresql.conf", thoughts? > > [1] https://www.postgresql.org/docs/devel/regress-run.html Yes, that'd make a lot of sense. PGOPTIONS is more suited for client settings. Willing to cook up a quick patch? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Updating the intro for packages - improve usability, reduce new user confusion
On Thu, 29 Nov 2018 at 17:23, Dmitry Igrishin wrote: > > чт, 29 нояб. 2018 г. в 07:35, Craig Ringer : > > > > TL;DR: It's time to update the docs to make package-based and > > installer-based PostgreSQL the assumed environment our users are > > working with. Or at least put it on an equal footing as a first-class > > citizen, not relegate it to the dark corners of notes and appendices. > > The same is true for client drivers. > Could you please add the reference to the Pgfe client library to the > documentation? > The patch is provided. Please don't hijack the thread. I don't want to devolve into a big argument about what does and does not merit explicit listing. I can't imagine anyone here objecting to our official, project-affiliated client drivers PgJDBC and psqlODBC, and if that's where the line is, whatever, that's better than some massive time wasting argument. Can we focus on the general issue I raised, not promoting random tools please? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Updating the intro for packages - improve usability, reduce new user confusion
CentOS or Fedora"
section of the distro-specific info in the manual. With, of course, a
note there saying that this applies if you installed from packages,
and xrefs for manual source installs and installer-binary installs.
We should have prominent links in the tutorial install section that link to:
* Linux: apt.postgresql.org and yum.postgresql.org
* the postgresql download page
* https://help.ubuntu.com/community/PostgreSQL for package-related
info on the Debian and Ubuntu variants
* https://fedoraproject.org/wiki/PostgreSQL for Fedora/RHEL/CentOS
package-related info
These are long lived, stable, well known links, and we're long past
the days where someone's reading the docs on a printout. Hell, most
people don't even realise we have docs packages rather than just the
website!
We should also have a short, simple "concepts" section in the tutorial
(or tweak the architecture fundamentals section) that explains a few
key points of frequent confusion:
* Explicitly mention that on most package installs you use `sudo -u
postgres psql` to get a "postgres" superuser shell. Give the Mac and
Windows equivalents too.
* Explain that PostgreSQL is a client/server system. The psql client
connects to a server, either on the same computer or elsewhere via a
network. The server is "postgres", the usual client is "psql" but
there are others.
* Explain that whenever we write "postgres=#" we mean "run this as a
postgres superuser"
* The "psql" shell is a separate program to the "sh" or "bash" shell.
It takes SQL commands and special backslash-commands. You cannot run
SQL on the system shell, and you cannot run system commands on the
psql shell.
* There are GUIs like PgAdmin4, OmniDB, HeidiSQL, DBeaver, etc that
some people will prefer. These tools may NOT support the psql
backslash commands the user manual describes. The manual is written
with the assumption that you use psql. In particular \COPY will NOT
work on many of them.
* The "createuser", "createdb" etc commands are command-line ("Command
Prompt", Terminal, etc) commands, NOT psql commands. They have sql
equivalents like CREATE USER, CREATE DATABASE, etc.
* Give a simple recipe for how to make your own user account with your
own db and set up peer auth for it, so you can get started simply,
like
sudo -u postgres psql -c "CREATE USER ${USER} WITH CREATEDB
CREATEROLE; CREATE DATABASE $user WITH OWNER ${USER};"
It's a shame we don't have an ALTER SYSTEM equivalent for pg_hba.conf,
but most packages ship with 'peer' enabled, so it should Just Work.
Anyway. I know that was long, but I wanted to actually explain WHAT I
want to change in the docs and HOW, not just "lets change some stuff
ok?".
I'll have extremely limited time to do this, but I hope to deliver a
stream of small and simple patches to do it piece-by-piece.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Re: First SVG graphic
On Thu, 29 Nov 2018 at 01:33, Jürgen Purtz wrote: > After one week no response at all? Neither positive nor negative. It > seems that the community has little interest in the SVG issue. Or in my > suggestion? > I'm excited you're doing it. I thought it was part of an existing/ongoing discussion and didn't really have much to say. I think it's a vital step forward and we really need to get some graphics into Pg. Personally I want to let go a bit of the diff-able, merge-able requirements and accept that not everything plays well when hand written. I got tired of the arguments that seemed to require that no tool written since 1972 could be used in our source tree lest SunOS 0.9.ancient have a fit, or someone find a (gasp) binary in a diff. So good on you for getting positive action rolling. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: Autocommit with Postgres 10
You are reading the documentation for the ECPG programming interface, not normal SQL or psql. Please see the manual for psql. https://www.postgresql.org/docs/current/static/app-psql.html
Re: why is there no CSVQL?
There are, it's called foreign data wrappers. Please use pgsql-general not the docs comment form for general Q
Re: Images in the official documentation
On 26 February 2018 at 12:16, Tom Lane <t...@sss.pgh.pa.us> wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: > > Yeah, I think it'd just effectively preserve the status quo by rendering > > anyone who's willing to add images and designs to the docs unable - or > > unlikely to be willing - to do so. > > This is an entirely reasonable complaint. But I don't see how we'd cope > with patches that rewrite an entire SVG file because the patch author's > WYSIWG editor emits its output in a style randomly different from the tool > the previous patch author used. It seems like such patches would be > effectively unreviewable, and certainly incapable of being merged. > Well, they definitely couldn't be merged in any situation entailing conflicts, no. Patch review would entail displaying the new and (if present) old SVGs, possibly in the context of a build of the docs, or possibly standalone. This is always going to be the case for anything but the most trivial SVG changes anyway. After all, even small textual changes can cause elements to overlap, break out of their expected bounaries, or otherwise look wrong. So IMO whether it's SVG or a raster image format, the net effect isn't that different: you have to review the rendered result not the source. Personally I'd just mark svg as binary in .gitattributes to stop it from spamming noise in diffs. Github offers a cool tool for side-by-side compares of svg diffs ( https://github.com/blog/1902-svg-viewing-diffing) but that likely won't help us much. There's diffsvg (https://github.com/jrsmith3/diffsvg), which I haven't tried but looks interesting. Combined with filters in .gitattributes this might offer improved visibility into change history if we really need it. Personally, I don't think images will be changing that often and they should just be tracked as blobs. > Maybe we could improve matters a bit by insisting that everyone use the > same version of the same SVG-editing tool. But that's not too practical. > Worse, from what I've seen, even that would not really fix the problem. > The tools simply don't give a damn about comparability of their dump > files. I don't blame their authors exactly (try diffing Postgres data > file changes :-() but that doesn't mean it isn't a problem for us. > > How can we resolve these issues? > Question the assumptions and requirements. Why do we actually _need_ diffable, mergeable images? Sure, it'd be *nice*, but what's the real world impact if we don't have it? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: Images in the official documentation
On 26 February 2018 at 04:12, Steve Atkins <st...@blighty.com> wrote: > > Writing SVG by hand maybe doesn't seem the best idea. > > I understand the attraction to people who want to store everything as > diffable text, but images of this sort are unlikely to get updated by > others, which means they're unlikely to be maintained as the things they're > intended to document change. It also means that the people best suited to > generating diagrams are the least likely to do so, and vice-versa. > > > Yeah, I think it'd just effectively preserve the status quo by rendering anyone who's willing to add images and designs to the docs unable - or unlikely to be willing - to do so. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
