Re: [GENERAL] Is there a way to start postgresql v907 as non daemon process
Karthik wrote: > I have observed by default posgresql 8.x onwards starts as daemon process. Is there a way to avoid > it. I want it to run as normal process. The parent of the server process should be the process that > starts the server instead of being PID 1 ( init ). Till 7.4.2 ( Which was the older version used by us > ) was using running in normal mode. The same behavior is necessary as we have our watchdog failing to > identify that it server is actually running. > > ( Transcript to help you what I am talking about ) > > c670e04:rkananth 16] /usr/local/bin/postgres --version > postgres (PostgreSQL) 9.0.7 > > c670e04:rkananth 11] postgres -D /data/db/postgres > c670e04:rkananth 12] ps -A | grep post > 65165 ?? Ss 0:00.01 /usr/local/bin/postgres > 65167 ?? Ss 0:00.00 postgres: writer process(postgres) > 65168 ?? Ss 0:00.00 postgres: wal writer process(postgres) > 65169 ?? Ss 0:00.00 postgres: autovacuum launcher process (postgres) > 65170 ?? Ss 0:00.00 postgres: stats collector process (postgres) > 65224 0 S+ 0:00.00 grep post > > c670e04:rkananth 14] ps -p 65165 -o ppid > PPID > 1 > > c670e04:rkananth 15] ps 1 > PID TT STAT TIME COMMAND > 1 ?? SLs0:00.17 /sbin/init -- > > I would be happy to provide further information if required. If you really want that, start the PostgreSQL server this way: $ postgres -D /data/directory & But can't you teach your watchdog to read the postgresql.pid file? Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Is there a way to start postgresql v907 as non daemon process
Thank you Laurenz, Even executing $ postgres -D /data/directory Used to start server in deamon mode, the reason was the postgres.conf was having "silent_mode = on" ( freebsd port used to do this ). Got this solved by sending "silent_mode=off" command line. With this my problem is solved. Trying to train my watch dog to look into postmaster.pid is also good idea but I do not want to work on that as it is working fine. Regards Karthik On 5/25/12 1:50 PM, "Albe Laurenz" wrote: >Karthik wrote: >> I have observed by default posgresql 8.x onwards starts as daemon >process. Is there a way to avoid >> it. I want it to run as normal process. The parent of the server >process should be the process that >> starts the server instead of being PID 1 ( init ). Till 7.4.2 ( Which >was the older version used by us >> ) was using running in normal mode. The same behavior is necessary as >we have our watchdog failing to >> identify that it server is actually running. >> >> ( Transcript to help you what I am talking about ) >> >> c670e04:rkananth 16] /usr/local/bin/postgres --version >> postgres (PostgreSQL) 9.0.7 >> >> c670e04:rkananth 11] postgres -D /data/db/postgres >> c670e04:rkananth 12] ps -A | grep post >> 65165 ?? Ss 0:00.01 /usr/local/bin/postgres >> 65167 ?? Ss 0:00.00 postgres: writer process(postgres) >> 65168 ?? Ss 0:00.00 postgres: wal writer process(postgres) >> 65169 ?? Ss 0:00.00 postgres: autovacuum launcher process >(postgres) >> 65170 ?? Ss 0:00.00 postgres: stats collector process >(postgres) >> 65224 0 S+ 0:00.00 grep post >> >> c670e04:rkananth 14] ps -p 65165 -o ppid >> PPID >> 1 >> >> c670e04:rkananth 15] ps 1 >> PID TT STAT TIME COMMAND >> 1 ?? SLs0:00.17 /sbin/init -- >> >> I would be happy to provide further information if required. > >If you really want that, start the PostgreSQL server this way: > >$ postgres -D /data/directory & > >But can't you teach your watchdog to read the postgresql.pid file? > >Yours, >Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Naming conventions
On 25/05/2012 02:21, Bruce Momjian wrote: > On Wed, May 16, 2012 at 10:08:03AM +0100, Raymond O'Donnell wrote: >> On 15/05/2012 22:50, Scott Briggs wrote: >>> So this is purely anecdotal but I'm curious, what's with all the >>> different naming conventions? There's psql (for database >>> connections), pgsql (used for some dirs like /usr/pgsql-9.1 and this >>> mailing list), postgres (user and other references), and postgresql >>> (startup scripts). > > Uh, the original Berkeley project name was postgres, pgsql is used as a > short-hand for PostgreSQL, and psql is short for 'PostgreSQL SQL > Monitor'. > >> ... and don't forget (maybe oddest of all) libpq! :-) > > libpq originally supported Postgres QUEL: > > http://en.wikipedia.org/wiki/QUEL_query_languages > Good to know all this... it might be worth adding it to the website or the wiki for the benefit of us blow-ins. :-) Ray. -- Raymond O'Donnell :: Galway :: Ireland r...@iol.ie -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Usability write-up - looking at Pg, especially PgAdmin-III and Pg on Windows, from an inexperienced user PoV
Hi all I just had the ... pleasure ... of using Windows with Pg again and was in a usability review frame of mind. I landed up trying to restore my database using PgAdmin-III, and was astonished at how difficult and painful it was. The issues weren't all PgAdmin-III either, there are a few Pg-on-Windows issues and a few plain warts in terms of PostgreSQL usability in general. It felt like my first experience with Oracle (ie: screaming, pain and confusion) not the smooth and pleasurable experience I've come to be so used to with Pg. I was sufficiently surprised by some of the issues that I've written up a post on the matter. I intended it to be a few usability notes, though it's turned into a bit more than that. I think it's really imporant to highlight these issues, because if this had been my first experience with PostgreSQL I would have walked away and never, ever, ever come back. It might be premature to post this before I've reviewed and re-edited the post, but hey, a few flames won't hurt. I'm trying to be constructive in the following, just also trying to express the frustration that someone new to Pg would experience. http://blog.ringerc.id.au/2012/05/postgresql-usability-pgadmin-iii-and-pg.html Brief summary of pain points: - The need to back up globals separately even when using a custom-format dump is a giant wart. GIANT. The need to restore them using a completely separate procedure because you can't use pg_restore just makes it even uglier. - Encoding/locale name mismatches between Windows and Linux are really unpleasant, esp when they prevent the restore of backups w/o workarounds! Big, big wart here. - The "restore" dialog in PgAdmin-III needs a lot of love. Harder to access than it should be, some things very counter-intuitive, blocks UI while restore in progress, can't cope with "backups" that're really SQL scripts at all. No interpretation of error codes is offered, which is particularly important because 0-is-success isn't obvious to most people. Messages windows aren't updated until the command completes. The cancel button stays enabled after the command finishes and should be "Abort" not "Cancel" anyway. No interpretation or hints gets presented for common errors. It doesn't exclude mutually exclusive options. Etc etc. Again, see post. - Running a script from PgAdmin-III is way, way too hard. In fact, as far as I can tell, you just can't invoke psql with a script w/o bypassing PgAdmin-III and using the cmdline. Obvious on Linux, but who wants to use a Windows command line? - The PgAdmin-III editor can't stream a file to a Pg backend, it has to load the whole lot into RAM, and it doesn't understand psql syntax even enough to say "whoops, \connect is only supported by psql, did you mean to run this as a script in psql?". It also silently wraps everything in a single transaction, like it or not. - The PgAdmin-III manual contrasts with the excellent quality and coverage of the main PostgreSQL docs. Well, the page on the "Restore" command at least was ... unhelpful. Yes, I'll be submitting improvements. - Pg's habit of continuing after the first error is really hard on newbies. This isn't so much something I ran into during this write-up as something I've been noticing on Stack Overflow. LOTS of people are confused because they see the last error, not the first error that's the cause. It's a lot like gcc - the first error is that you forgot to close a double quote, the rest is garbage you should ignore. A solution to this is needed from a usability standpoint, but is difficult because so much existing code relies on psql in particular continuing after errors. I'd propose having psql cache the first error (ie:non-zero SQLSTATE response) it gets in memory, and emit that when it exists, eg: The first error was: ERROR: role "postgres" already exists ... in response to the command: CREATE ROLE postgres;" Anway, I hope my rant/critique/whine is helpful. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Usability write-up - looking at Pg, especially PgAdmin-III and Pg on Windows, from an inexperienced user PoV
On Fri, May 25, 2012 at 12:56 PM, Craig Ringer wrote: > I just had the ... pleasure ... of using Windows with Pg again and was in a > usability review frame of mind. I landed up trying to restore my database > using PgAdmin-III, and was astonished at how difficult and painful it was. > The issues weren't all PgAdmin-III either, there are a few Pg-on-Windows > issues and a few plain warts in terms of PostgreSQL usability in general. Agreed on all points, I've had to help people using pgAdmin with many of the problems you point out. Note that the pgadmin-hackers list is also relevant. Together with an earlier study about common PostgreSQL pitfalls, I've created an article on the wiki: https://wiki.postgresql.org/wiki/Usability_reviews However, I suspect posting long rants like this won't get us very far. Instead, I think these problems should be posted one by one, with proposed solutions, so they can be discussed in detail without distractions. Once there seems to be a consensus for a solution, add a TODO list item -- I suspect most of these items are quite easy to solve in code, once it's clear *how* to address them. And the TODO list has been short of simple items recently. Regards, Marti -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Usability write-up - looking at Pg, especially PgAdmin-III and Pg on Windows, from an inexperienced user PoV
On 25/05/2012 6:55 PM, Marti Raudsepp wrote: Together with an earlier study about common PostgreSQL pitfalls, I've created an article on the wiki: https://wiki.postgresql.org/wiki/Usability_reviews However, I suspect posting long rants like this won't get us very far. Instead, I think these problems should be posted one by one, with proposed solutions, so they can be discussed in detail without distractions. Once there seems to be a consensus for a solution, add a TODO list item -- I suspect most of these items are quite easy to solve in code, once it's clear *how* to address them. And the TODO list has been short of simple items recently. You're quite right. FWIW, it wasn't intended to be a long rant - I started out writing a point-by-point review of a few usability issues - though it certainly turned into a long rant as I started seeing more and more issues. It's my intention to break that down into specific problem areas and points, I just thought it was worth getting a few initial impressions too. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1
On Thu, May 24, 2012 at 12:57 PM, Tom Lane wrote: > Lonni J Friedman writes: >> On Thu, May 24, 2012 at 12:34 PM, Tom Lane wrote: >>> Can you correlate the performance hit with any specific part of >>> autovacuum? In particular, I'm wondering if it matters whether vacuum >>> is cleaning tables or indexes --- it alternates between the two, and the >>> access patterns are a bit different. You could probably watch what the >>> autovac process is doing with strace to see what it's accessing. > >> Is there something specific I should be looking for in the strace >> output, or is this just a matter of correlating PID and FD to >> pg_class.relfilenode ? > > Nah, just match up the files it touches with pg_class.relfilenode. Seems to be slower across the board regardless of what is being vacuumed (tables or indices). For example, i have a relatively small table (currently 395 rows, rarely has any inserts or deletes). vacuuming just the table (not indices) takes on average 4s with the khugepaged defragmenter on, and less than 1s with it off. vacuuming just the indices takes on average 2s with the khugepaged defragmenter on, and less than 1s with it off. The much larger tables (thousands to millions of rows), I see similar performance (although they take even longer to complete with & without the khugepaged defragmenter enabled). -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] configuring library path for debian build of postgres 9.2
I'm trying to build postgres 9.2 beta1 on debian stable from sources, in a way that plays nicely with the debian cluster management stuff. If I configure with libdir=/usr/lib/postgres everything works but the shared libraries end up in the wrong place (ie just where I specified). If I configure with libdir=/usr/lib/postgresql/9.2, which is where I want the libraries to go, psql complains: $ /usr/lib/postgresql/9.2/bin/psql: symbol lookup error: /usr/lib/postgresql/9.2/bin/psql: undefined symbol: PQconnectdbParams Here is my configure command: $ ./configure --build=i486-linux-gnu --prefix=/usr --includedir=/usr/include/postgresql/9.2 --mandir=/usr/share/postgresql/9.2/man --infodir=/usr/share/postgresql/9.2/info --sysconfdir=/etc/postgresql-common --localstatedir=/var --libexecdir=/usr/lib/postgresql/9.2 --libdir=/usr/lib/postgresql/9.2 --srcdir=. -docdir=/usr/share/doc/postgresql-doc-9.2 --datadir=/usr/share/postgresql/9.2/ --bindir=/usr/lib/postgresql/9.2/bin --enable-nls --enable-integer-datetimes --enable-thread-safety --enable-debug --disable-rpath --with-perl --with-python --with-pam --with-krb5 --with-gssapi --with-openssl --with-libxml --with-libxslt --with-ldap --with-ossp-uuid --with-gnu-ld --with-system-tzdata=/usr/share/zoneinfo CFLAGS='-g -O2 -g -Wall -O2 -fPIC' LDFLAGS=' -Wl,--as-needed' I'd appreciate any suggestions. In the short term I can live with the libraries being in the wrong place for one postgres version but it isn't viable in the longer term. Ultimately I'd like to be able to build a debian-compatible postgres cluster directly from the repository. Thanks. __ Marc signature.asc Description: This is a digitally signed message part
Re: [GENERAL] configuring library path for debian build of postgres 9.2
On 05/25/2012 03:05 PM, Marc Munro wrote: > I'm trying to build postgres 9.2 beta1 on debian stable from sources, in > a way that plays nicely with the debian cluster management stuff. > > > I'd appreciate any suggestions. Take a look at this?: http://www.piware.de/2012/05/packages-for-postgresql-9-2-beta-1-now-available/ > Thanks. > > __ > Marc -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PG vs MSSQL language comparison ?
Hi, I'm not into comparing which DBMS is better as we all know ... kind of ... well ... I'd like to find ressources to look up how one can do X in MSSQL when one knows how it is done in PG's SQL and the other way around. regards Andreas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PG vs MSSQL language comparison ?
On 26/05/2012 00:04, Andreas wrote: > Hi, > > I'm not into comparing which DBMS is better as we all know ... kind of ... > well ... > > I'd like to find ressources to look up how one can do X in MSSQL when one > knows how it is done in PG's SQL and the other way around. > > regards > Andreas Hi Andreas, It's a little out of date (I've been meaning to update it for about 2 years now) and has some gaps, but try the Database Rosetta Stone. http://www.grantondata.com/community/dbrosettastone.html Let me know if you spot anything missing you'd like updated. Ciao Fuzzy :-) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
