Re: Updating the intro for packages - improve usability, reduce new user confusion
Re: Dmitry Igrishin 2018-11-29 > Could you help me please to package it for Debian? I'll happy to do it! The starting point would be https://www.debian.org/doc/manuals/maint-guide/ If you have any questions, I'd be glad to help. Christoph
Objects without schema
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/ddl-schemas.html Description: In the last section of the document it says 'If you need to work with those systems, then maximum portability would be achieved by not using schemas at all.'. But how do we achieve this? If I am not mistaken, all objects(like tables) created in the database need to be created under one schema. Thanks, Joby
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
Re: Updating the intro for packages - improve usability, reduce new user confusion
чт, 29 нояб. 2018 г. в 13:28, Steve Atkins : > > > > > On Nov 29, 2018, at 10:17 AM, Steve Atkins wrote: > > > > > > > >> On Nov 29, 2018, at 9:36 AM, Christoph Berg wrote: > >> > >> Re: Dmitry Igrishin 2018-11-29 > >> > Could you please add the reference to the Pgfe client library to the > documentation? > The patch is provided. > >> > >>> diff --git a/doc/src/sgml/external-projects.sgml > >>> b/doc/src/sgml/external-projects.sgml > >>> index 347b830..c74e391 100644 > >>> --- a/doc/src/sgml/external-projects.sgml > >>> +++ b/doc/src/sgml/external-projects.sgml > >>> @@ -83,6 +83,13 @@ > >>> > >>> > >>> > >>> + Pgfe > >>> + C++ > >>> + An API inspired by libpq > >>> + >>> url="https://github.com/dmitigr/pgfe;> > >> > >> Has that been around long enough, and is widely used, so it qualifies > >> for mentioning here? I've never heard of it, and it's not packaged for > >> Debian. > > > > No. It's been discussed at least once before that I've noticed, and IIRC > > the conclusion was "add it to the wiki", which I did in May. > > > > https://wiki.postgresql.org/wiki/Client_Libraries > > And while it looks like it has the potential to become a decent enough > library it's > own documentation says that it's beta-quality, has an unstable API and isn't > ready to be used in production. All these problems are problems of Pgfe, rather than PostgreSQL. Anyway, let the up to the user to decide what to use and what not. He or she knows it better. The problem of PostgreSQL, as this topic suggest, that things related to PostgreSQL (including client interfaces) "relegates in the dark corners of notes and appendices". But sometimes the situation is even worse, because that related things is in the dark corners of Internet and not even mentioned in the documentation at all!
Re: Updating the intro for packages - improve usability, reduce new user confusion
> On Nov 29, 2018, at 10:17 AM, Steve Atkins wrote: > > > >> On Nov 29, 2018, at 9:36 AM, Christoph Berg wrote: >> >> Re: Dmitry Igrishin 2018-11-29 >> Could you please add the reference to the Pgfe client library to the documentation? The patch is provided. >> >>> diff --git a/doc/src/sgml/external-projects.sgml >>> b/doc/src/sgml/external-projects.sgml >>> index 347b830..c74e391 100644 >>> --- a/doc/src/sgml/external-projects.sgml >>> +++ b/doc/src/sgml/external-projects.sgml >>> @@ -83,6 +83,13 @@ >>> >>> >>> >>> + Pgfe >>> + C++ >>> + An API inspired by libpq >>> + https://github.com/dmitigr/pgfe;> >> >> Has that been around long enough, and is widely used, so it qualifies >> for mentioning here? I've never heard of it, and it's not packaged for >> Debian. > > No. It's been discussed at least once before that I've noticed, and IIRC > the conclusion was "add it to the wiki", which I did in May. > > https://wiki.postgresql.org/wiki/Client_Libraries And while it looks like it has the potential to become a decent enough library it's own documentation says that it's beta-quality, has an unstable API and isn't ready to be used in production. Cheers, Steve
Re: Updating the intro for packages - improve usability, reduce new user confusion
> On Nov 29, 2018, at 9:36 AM, Christoph Berg wrote: > > Re: Dmitry Igrishin 2018-11-29 > >>> Could you please add the reference to the Pgfe client library to the >>> documentation? >>> The patch is provided. > >> diff --git a/doc/src/sgml/external-projects.sgml >> b/doc/src/sgml/external-projects.sgml >> index 347b830..c74e391 100644 >> --- a/doc/src/sgml/external-projects.sgml >> +++ b/doc/src/sgml/external-projects.sgml >> @@ -83,6 +83,13 @@ >> >> >> >> + Pgfe >> + C++ >> + An API inspired by libpq >> + https://github.com/dmitigr/pgfe;> > > Has that been around long enough, and is widely used, so it qualifies > for mentioning here? I've never heard of it, and it's not packaged for > Debian. No. It's been discussed at least once before that I've noticed, and IIRC the conclusion was "add it to the wiki", which I did in May. https://wiki.postgresql.org/wiki/Client_Libraries Cheers, Steve
Re: Return codes for archive and restore commands
On Thu, Nov 29, 2018 at 5:40 AM Stephen Frost wrote: > > Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Wed, Nov 28, 2018 at 11:00:31AM +, PG Doc comments form wrote: > > > For the archive command: > > > <=128 There are not errors in the PostgreSQL log (messages with severity > > > equal or higher than ERROR). Firstly 3 messages of type LOG about fault, > > > then WARNING about this and pause for 1 minute, then repeated. > > > >=129 FATAL error in the PostgeSQL log. The message about stoping an > > > >archive > > > process, but not the database. Repeated after roughly 16 seconds. > > > > This code is around for some time, and comes from this commit: > > commit: 3ad0728c817bf8abd2c76bd11d856967509b307c > > author: Tom Lane > > date: Tue, 21 Nov 2006 20:59:53 + > > committer: Tom Lane > > date: Tue, 21 Nov 2006 20:59:53 + > > On systems that have setsid(2) (which should be just about everything except > > Windows), arrange for each postmaster child process to be its own process > > group leader, and deliver signals SIGINT, SIGTERM, SIGQUIT to the whole > > process group not only the direct child process. This provides saner > > behavior > > for archive and recovery scripts; in particular, it's possible to shut down > > a > > warm-standby recovery server using "pg_ctl stop -m immediate", since > > delivery > > of SIGQUIT to the startup subprocess will result in killing the waiting > > recovery_command. Also, this makes Query Cancel and statement_timeout apply > > to scripts being run from backends via system(). (There is no support in > > the > > core backend for that, but it's widely done using untrusted PLs.) Per gripe > > from Stephen Harris and subsequent discussion. > > > > The relevant part if pgarch_archiveXlog() in pgarch.c, and this part > > is most relevant: > > * Per the Single Unix Spec, shells report exit status > 128 when a > > * called command died on a signal. > > > > > In this case PostgreSQL tries confirm rules for return codes of a unix > > > shell. A unix shell return 126 in the case of "command not executable", > > > 127 > > > in the case "command not found", 128+# of signal in the case if > > > application > > > interrupted by uncatched signal. > > > > If you were to rewrite those paragraphs or make them more precise, how > > would you actually shape your suggestions? I personally quite like the > > current formulations, but I am rather used to it to be honest. > > This is another example, at least imv, of why we really need to move > away from archive_command as an interface for doing WAL archiving. +1 > > Having discussed this quite a bit lately with David Steele and Magnus, > it's pretty clear that we need to completely rip out how this works > today and rewrite it based around an extension model where a background > worker can start up and essentially take the place of the archiver > process, with flexibility to jump forward through the WAL stream, > communicate clearly with other processes, handle failure to do so > gracefully based on the specific cases, etc. > > We could then possibly write an extension to be included that mimics > what archive_command does today, but imv we should immediately consider > it deprecated and encourage people to move off of it. > > Thanks! > > Stephen -- Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: First SVG graphic
On Wed, Nov 28, 2018 at 8:33 PM 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? First of all, I am BIG + for having diagrams in our documentation. I once estimated the number of diagrams in our official documentation and it was only 50 or so, that means, it is possible to make them more or less centralized, at least for the initial version. If Jurgen+ agree to work on this I would be happy to help them in the parts I was working on. For the initial version we could even provide the generated images along with SVG-source files. > > Jürgen Purtz > > -- Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: Updating the intro for packages - improve usability, reduce new user confusion
чт, 29 нояб. 2018 г. в 12:36, Christoph Berg : > > Re: Dmitry Igrishin 2018-11-29 > > > > Could you please add the reference to the Pgfe client library to the > > > documentation? > > > The patch is provided. > > > diff --git a/doc/src/sgml/external-projects.sgml > > b/doc/src/sgml/external-projects.sgml > > index 347b830..c74e391 100644 > > --- a/doc/src/sgml/external-projects.sgml > > +++ b/doc/src/sgml/external-projects.sgml > > @@ -83,6 +83,13 @@ > > > > > > > > + Pgfe > > + C++ > > + An API inspired by libpq > > + https://github.com/dmitigr/pgfe;> > > Has that been around long enough, and is widely used, so it qualifies > for mentioning here? I've never heard of it, and it's not packaged for > Debian. I've released Pgfe in May 2018. I don't know how widely it's used. I think it should be just mentioned in the documentation to let the users decide to use it or to not. It's open source and anyone can contribute or file a bug or feature request. So, I don't see problem here. Could you help me please to package it for Debian? I'll happy to do it!
Re: Updating the intro for packages - improve usability, reduce new user confusion
Re: Dmitry Igrishin 2018-11-29 > > Could you please add the reference to the Pgfe client library to the > > documentation? > > The patch is provided. > diff --git a/doc/src/sgml/external-projects.sgml > b/doc/src/sgml/external-projects.sgml > index 347b830..c74e391 100644 > --- a/doc/src/sgml/external-projects.sgml > +++ b/doc/src/sgml/external-projects.sgml > @@ -83,6 +83,13 @@ > > > > + Pgfe > + C++ > + An API inspired by libpq > + https://github.com/dmitigr/pgfe;> Has that been around long enough, and is widely used, so it qualifies for mentioning here? I've never heard of it, and it's not packaged for Debian. Christoph
Re: Updating the intro for packages - improve usability, reduce new user confusion
чт, 29 нояб. 2018 г. в 12:25, Dmitry Igrishin : > > чт, 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. diff --git a/doc/src/sgml/external-projects.sgml b/doc/src/sgml/external-projects.sgml index 347b830..c74e391 100644 --- a/doc/src/sgml/external-projects.sgml +++ b/doc/src/sgml/external-projects.sgml @@ -83,6 +83,13 @@ + Pgfe + C++ + An API inspired by libpq + https://github.com/dmitigr/pgfe;> + + + node-postgres JavaScript Node.js driver
Re: Updating the intro for packages - improve usability, reduce new user confusion
чт, 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.
