Re: Logging (was Re: [GENERAL] PostgreSQL 7.0-2 RPMset released.)
On Mon, 22 May 2000 00:19:45 -0400 Tom Lane wrote: > There needn't be a lot of code involved, we just need a > well-thought-out spec for how it should work. Comments anyone? I run postmaster under Dan Bernstein's "daemontools", which include logging facilities: http://cr.yp.to/daemontools.html The summary of this setup is that postmaster runs in the forground writing error messages to standard error, and standard error is a pipe to another process. The second process is responsible for selecting messages to write, writing them, and rotating the log file. More traditional Unix solutions would involve teaching postmaster what the name of its log file is, and to reopen it on receipt of some signal. Usually SIGHUP is used since SIGHUP is unlikely to be useful to a daemon running in the background. There are issues for logging errors that many applications handle badly. What happens when: o there is an I/O error writing to a log file? o the log file is at maximum size? o the filesystem the log file is in is full? o a write to a log file blocks? To take a not random example, syslogd is OK for log file rotation but makes a mess and a muddle of things otherwise including the points I list. Regards, Giles
Logging (was Re: [GENERAL] PostgreSQL 7.0-2 RPMset released.)
Lamar Owen <[EMAIL PROTECTED]> writes: > The real problem with redirecting the postmaster output is the issue > of log rolling, which is impossible to do in the 'classic' > stderr/stdout redirect UNLESS you throw down postmaster when rolling > the log (unless you know a trick I don't). Yes. I think ultimately we will have to do some logging support code of our own to make this work the way we want. My thought at the moment is there's nothing wrong with logging to stderr, as long as there's some code somewhere that periodically closes stderr and reopens it to a new log file. There needn't be a lot of code involved, we just need a well-thought-out spec for how it should work. Comments anyone? regards, tom lane
Re: Re: [GENERAL] Does Psql support Chinese?
> I'm Sorry. I can't reach your page because my network only allows email to the world. Oh, how can you get PostgreSQL sources from the Internet?:-) Anyway, I will send you the image by a private mail. -- Tatsuo Ishii
Re: [GENERAL] PostgreSQL 7.0-2 RPMset released.
On Sun, 21 May 2000, Thomas Good wrote: > On the GENERAL list the issue of firing up a server, and the silent flag > used by the default redhatter 'postgresql' script in init.d came up. Yes, I read the thread. I didn't write the original initscript -- but hopefully have changed it to more your liking (see below). > I redirect output to /var/lib/pgsql/postlog after I rm the -S from the > call to the server...not having pg complain when I screw up my CGI > scripts is no good to me. > If I were to have a vote, I'd urge whomever to add a comment to 'postgresql > the script' to offer logging in the manner described above. The 7.0 RPM's /etc/rc.d/init.d/postgresql script uses pg_ctl, rather than directly starting postmaster (and has since 7.0beta2, IIRC) -- and the PGDATA/postmaster.opts.default (which, by default, only has '-i' -- no -S) file is used for postmaster startup options, rather than passing them on the command line. The changelog notice for this was buried back in the beta cycle release announcements -- I should have duplicated all notices for the 7.0-1 release announcement. More documentation will be written as I have time (or input to README.rpm, or patches to README.rpm). Look at the new initscript, then let me know about possible improvements (of which I am sure improvements can be made!). Currently stderr and stdout from pg_ctl are piped to /dev/null, but that is easy enough to change. And, by changing the PGDATA/pg_options file's contents, you can turn on syslog -- edit /etc/syslog.conf to get syslogging working -- just watch out for long queries! Logging is one of the hot issues in the RPMset right now, as the comments about syslog in the -2 release announcement show. The real problem with redirecting the postmaster output is the issue of log rolling, which is impossible to do in the 'classic' stderr/stdout redirect UNLESS you throw down postmaster when rolling the log (unless you know a trick I don't). I am trying to get _real_ logging, by way of syslog, rather than with redirects -- however, the redhat syslog dies under long queries (such as the one issued by psql in response to a \d directive). Since some things were missed in the beta cycle's announcements (which only were sent to pgsql-hackers), notice that the new 7.0 RPMset will create a new PGDATA in /var/lib/pgsql/data instead of /var/lib/pgsql. There are other changes -- read /usr/doc/postgresql-7.0/README.rpm and the pgsql-hackers archives on the subject. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: Re: [GENERAL] Does Psql support Chinese?
>Thank U for your reply. >When I mean input chinese in the psql client ,I just want to build a database > with the chinese instance or the chinese table name.So an example is : [Chinese text snipped] Can you check to see if the result is correct or not? Seems works fine for me. Please look at: http://www.sra.co.jp/people/t-ishii/tmp/gb.jpg -- Tatsuo Ishii
Re: Re: [GENERAL] Does Psql support Chinese?
Thank U for your reply. When I mean input chinese in the psql client ,I just want to build a database with the chinese instance or the chinese table name.So an example is : " ר¼Ãû ×÷Çú×÷´Ê Çú³¤"
Re: [GENERAL] rules on INSERT can't UPDATE new instance?
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > I thought an INSERT rule with an UPDATE action would work on the same > > table, but that fails. Seems the rule is firing before the INSERT > > happens. > > Yes, a trigger is the right way to do surgery on a tuple before it is > stored. Rules are good for generating additional SQL queries that will > insert/update/delete other tuples (usually, but not necessarily, in > other tables). Even if it worked, a rule would be a horribly > inefficient way to handle modification of the about-to-be-inserted > tuple, because (being an independent query) it'd have to scan the table > to find the tuple you are talking about! > > The reason the additional queries are done before the original command > is explained thus in the source code: > >* The original query is appended last if not instead >* because update and delete rule actions might not do >* anything if they are invoked after the update or >* delete is performed. The command counter increment >* between the query execution makes the deleted (and >* maybe the updated) tuples disappear so the scans >* for them in the rule actions cannot find them. > > This seems to make sense for UPDATE/DELETE, but I wonder whether > the ordering should be different for the INSERT case: perhaps it > should be original-query-first in that case. > Thanks, Tom. I was writing the Trigger section of my book the past few days, and this helped me define when to use rules and when to use triggers. -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[GENERAL] Re: [HACKERS] Re: MySQL crashme test and PostgreSQL
> Hi, > > Bruce Momjian: > > Also, I have heard about the hit squads attacking MySQL. I never > > condone inaccuracy or attacks, but I can understand why it is happening. > > > You _are_ doing your side of the story a disservice, you know that? Hey, I am not saying I like it happening. All I am saying is that I can understand why it is happening. Certainly MSSQL and Oracle are the real products we need to compete against. > > > For years, I believe the deceptiveness of the MySQL crashme test has > > hampered acceptance of PostgreSQL. And our response was to just reply > > with our opinion when asked about it. > > Yeah, I can see that. > > Let me tell you up front that your opinion is not at all helpful to > either the cause of PostgreSQL or to the problems between you and the > MySQL people, especially when stated like this. > > > This is the Internet. The right thing to do if somebody spreads bad > information (a biased, inaccurate, wrong, deceptive, what-have-you) > crash-me test would be to write your own test which either prefers > PostgreSQL, or is reasonably neutral. We have better things to do than compete against deceptive tests. We just work to make are our product better and better. Making another crashme test is not going to make PostgreSQL a better piece of software. -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [GENERAL] fmgr_info error
Louis-David Mitterrand <[EMAIL PROTECTED]> writes:
> After creating a trigger on an insert I get this error:
> auction=> insert into bid values('mito',3,354);
> NOTICE: you bid the exact increment of 5
> ERROR: fmgr_info: function 38667: cache lookup failed
> And the insert is not performed as it should. What does this error mean?
Offhand I'd guess that you deleted and recreated the function, but
didn't delete and recreate the trigger definition, so it's still
pointing at the now-gone version of the function.
This could stand to be cleaned up :-( ... but right now you have
to remake triggers referencing a function whenever you remake
the function.
regards, tom lane
Re: [GENERAL] crash on \copy
Louis-David Mitterrand <[EMAIL PROTECTED]> writes: > Is this a known problem? > template1=> \copy > psql: xstrdup: cannot duplicate null pointer (internal error) > styx:~% > using PG 7.0-beta5 on Linux Seems to be fixed in 7.0 release: regression=# \copy \copy: arguments required regards, tom lane
Re: [GENERAL] Re: MySQL crashme test and PostgreSQL
> That's easy: > > MySQL has type mediumint > PostgreSQL has transactions > > MySQL allows 'and' as string markers > PostgreSQL has views > > MySQL has case insensitive compare > PostgreSQL has referential integrity > > MySQL has support for -00-00 dates > PostgreSQL has subqueries > > MySQL has 'drop table if exists' > PostgreSQL has multiversion concurrency control > > etc. > > See? Equal. I hope my sarcasm is not too overstated. It took me a minute to figure this out. Wow, that was funny. I am still laughing. -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[GENERAL] INSERT WITH SELECT help
I am new to SQL so bare with me here.
I have set up a contact database. The PRIMANY KEY is person.per_id
All the other tables REFERENCE the person.per_id key. Now I want to be
able
to INSERT INTO the address table based on person.per_id by name without
having to know the value of person.per_id. Something like, I know this
does not work
but you will get the idea of what I need.
INSERT INTO address
(per_id,street,city,state,zip)
VALUES ('('SELECT per_id FROM person WHERE first ='somename')','200 some
street',
'Tampa','FL','33654');
Can somthing like this be done ? Any help would be great.
Re: [GENERAL] Columns in pg_shadow?
Peter Eisentraut <[EMAIL PROTECTED]> writes: usecatupd: Ability to change system tables? >> Since there's no really convenient interface for twiddling this flag, >> I doubt anyone actually bothers to change it. It starts out the same >> as one's usesuper flag, and probably stays that way... > Also note that once you unset this flag you can't set it again because you > no longer have write access to pg_shadow. Yeek. Gun ... foot ... shoot ... I suppose you'd still have the rights to create new users, so you could create a new superuser and then log in as him to fix the problem. regards, tom lane
Re: [GENERAL] crash on \copy
Louis-David Mitterrand writes: > Is this a known problem? Yes. Use the final release. > > template1=> \copy > psql: xstrdup: cannot duplicate null pointer (internal error) > styx:~% > > using PG 7.0-beta5 on Linux > > -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
[GENERAL] Re: [HACKERS] Postgresql OO Patch
Chris writes: > I.e. "SELECT * FROM foobar*" becomes "SELECT * FROM foobar", and > "SELECT * from foobar" becomes "SELECT * FROM ONLY foobar". This aspect of the patch I wholeheartedly agree on. The rest I'm not sure about -- yet. :) > Benefits: > *) SQL3 says it. That is unfortunately false for the patch in general. -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [GENERAL] Columns in pg_shadow?
Tom Lane writes: > > usetrace: > Searching through the sources shows that this flag is not used anywhere. > The catalogs.sgml doc file defines it as "can user set trace flags?" > but whatever code it controlled must be long dead... Remnants of a three-quarters baked pg_options implementation I suppose. > > usecatupd: > > Ability to change system tables? > Since there's no really convenient interface for twiddling this flag, > I doubt anyone actually bothers to change it. It starts out the same > as one's usesuper flag, and probably stays that way... Also note that once you unset this flag you can't set it again because you no longer have write access to pg_shadow. -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
[GENERAL] crash on \copy
Is this a known problem? template1=> \copy psql: xstrdup: cannot duplicate null pointer (internal error) styx:~% using PG 7.0-beta5 on Linux -- Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.fr
[GENERAL] fmgr_info error
After creating a trigger on an insert I get this error:
auction=> insert into bid values('mito',3,354);
NOTICE: you bid the exact increment of 5
ERROR: fmgr_info: function 38667: cache lookup failed
And the insert is not performed as it should. What does this error mean?
TIA
--
Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.fr
Re: [GENERAL] RPM troubleshoot
If you are trying to install the most recent version, you could try rpm -Uvh Depending on what distribution you are using and how it is configured, Postgresql may be installed. However, on earlier version of RedHat (can't quite remember which), although postgresql was installed, it took a bit of tweaking the system startup scripts, environment variables, create the user postgres, and run initdb to get it working. Some people found it confusing. I talked to guy in town who said he was in a discussion on the internet where the concluded the earlier RPMS were broken for RedHat. They weren't, but the initialization process was confusing people. Conclusion: Even if postgresql is installed on your system from a previous version, re-install it with the new rpms. It's easier to get running, and works much better. Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer > Original Message > Date: Fri, 19 May 2000 23:19:25 PDT > From: "santosh behera" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > Hi everybody, > Can any body help me is troubleshooting my PostgreSQL installation > !.when > giving rpms postgr*.rpm it replies postgreSQL already installed. > No > daemon of postmaster is running. > Please help me how i can be sure if at all this is installed and start > a > session .
Re: [GENERAL] PostgreSQL 7.0-2 RPMset released.
On Sat, 20 May 2000, Lamar Owen wrote:
> The 7.0-2 RPMset fixes the following:
> 1.) SPI headers are now the 7.0 set, and not the 6.5.3 set;
> 2.) pg_options default to NOT enable syslog, or extended query logging, as
> syslogd has some issues with long queries (such as issued by psql's \d
> command!);
> 3.) Alpha patches have returned!
>
> As usual, read '/usr/doc/postgresql-7.0/README.rpm' for more information.
Lamar,
On the GENERAL list the issue of firing up a server, and the silent flag
used by the default redhatter 'postgresql' script in init.d came up.
I redirect output to /var/lib/pgsql/postlog after I rm the -S from the
call to the server...not having pg complain when I screw up my CGI
scripts is no good to me.
If I were to have a vote, I'd urge whomever to add a comment to 'postgresql
the script' to offer logging in the manner described above.
I do this on BSD, UnixWare and Linux (a few flavours) and have never had
a problem. Other than with my own code!
To be a bit clearer (tough this early): I rm the -S muzzle, >> stdout and
stderr to /var/lib/pgsql/postlog, then run the whole enchilada in the
background ( 2>&1 &' ). This works well.
I call the script from rc.local and I still get the [OK] in brilliant green
followed by the pid. Nothing appears broken *and* I get a log full of
insensitive complaints about my programming skills. Who could ask for
more? Here is what I do:
su -l postgres -c '/usr/bin/postmaster -i -D/var/lib/pgsql >>
/var/lib/pgsql/postlog 2>&1 &'
Cheers,
Tom
> **initdb required for those still running releases prior to 7.0RC5!***
>
> Users running 6.5.x (or earlier!) need to thoroughly read and understand the
> README.rpm before installing (it is available on the ftp site as README in the
> RPM distribution directory, as well as in the 'unpacked' subdirectory).
>
> The spec file for this release, as well as all patches and supplemental
> programs are available in the 'unpacked' subdirectory.
>
> RPMset's are available at:
> ftp://ftp.postgresql.org/pub/binary/v7.0/redhat-RPM
>
> Further information available at http://www.ramifordistat.net/postgres, as
> usual; or by e-mail at [EMAIL PROTECTED] (i prefer RPM questions to go
> to the list instead of directly to me).
>
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>
---
North Richmond Community Mental Health Center
---
Thomas Good, MIS Coordinatortomg@ { admin | q8 } .nrnet.org
Phone: 718-354-5528
Fax: 718-354-5056
---
North Richmond Systems PostgreSQL s l a c k w a r e
Are Powered By: RDBMS |-- linux
---
Re: [GENERAL] Does Psql support Chinese?
> > I want to build a database in chinese. > > But when I input chinese in the linux psql client , it doent's display well. > > So how can I solve it? > > Does your cat command show your Chinese texts correctly? If not, that > might not be a PostgreSQL problem. > > BTW, what kind of encoding are you using for your Chinese texts? Sorry, I lost your reply mail but I recall that you could show Chinese character on your Linux. If so, can you send me the actual Chinese text? (shorter one is preferable, say 10 bytes are enough). -- Tatsuo IShii
