Re: [BUGS] Bug #922: PANIC: open of /scratch/production_2/pg_clog/0996 failed: No such file or directory
Andre Hackmann <[EMAIL PROTECTED]> writes: > If I vacuum before executing my index script (after my loading > script has terminated), or after other huge data movements, the server > doesn't crash. So, is this typical for hardware failures? Hm. If you can reproduce the problem on demand, I'd be very interested in looking at it with a debugger. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #922: PANIC: open of /scratch/production_2/pg_clog/0996
Hi, The server (IBM) is one year old (I think). Anyway, I found something like a workaround: If I vacuum before executing my index script (after my loading script has terminated), or after other huge data movements, the server doesn't crash. So, is this typical for hardware failures? Thanks, Andre. On Sun, 30 Mar 2003, Tom Lane wrote: > > I'd wonder about hardware problems, especially if this is a new server. > Messages of the above type are one of the most common consequences when > a data page has been trashed by hardware misfeasance. > > (While I wouldn't sit here and swear that it couldn't be a software > problem, all of the cases I've been able to examine seemed to be > hardware failures...) > > regards, tom lane > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] can you solve my problem
hi, i tried to execute psql template1.i got the problem below.plz help me out. [EMAIL PROTECTED] /]# su jat - [EMAIL PROTECTED] /]$ whoami jat [EMAIL PROTECTED] /]$ psql template1 psql: FATAL 1: user "jat" does not exist thank you. regards, himansu __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] [ Help ]
Hi, Everything my server output this message error: DEBUG: query: update gn_anuncio set qtdclk=qtdclk +1 where codanu=196789DEBUG: CommitTransactionCommand/iG/dbms/postgres/bin/postmaster: BackendStartup: pid 1136 user producao db producao socket 5FindExec: found "/iG/dbms/postgres/bin/postgres" using argv[0]/iG/dbms/postgres/bin/postmaster: reaping dead processes.../iG/dbms/postgres/bin/postmaster: CleanupProc: pid 1005 exited with status 0 not respond... after process die. What means this error ? Help me please !!! Tks. Ferreira, Osvâneo - iG [EMAIL PROTECTED] <>
Re: [BUGS] can you solve my problem
On Fri, 2003-03-28 at 16:06, himansu biswal wrote: > hi, > i tried to execute psql template1.i got the problem > below.plz help me out. > > [EMAIL PROTECTED] /]# su jat - > [EMAIL PROTECTED] /]$ whoami > jat > [EMAIL PROTECTED] /]$ psql template1 > psql: FATAL 1: user "jat" does not exist PostgreSQL users are not the same as local system users (a PostgreSQL server can be accessed from other machines, if you configure it so.) You need to create database users with the SQL command CREATE USER or the system command createuser. Look up their documentation to see how. You also need to look at access controls in $PGDATA/pg_hba.conf - see the Administrator's manual. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "If we confess our sins, he is faithful and just to forgive us our sins, and to cleanse us from all unrighteousness." I John 1:9 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug #929: Client connection to postgresql hangs indefinitely (under possibly pathological scenarios)
Claudio Natoli ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Client connection to postgresql hangs indefinitely (under possibly pathological scenarios) Long Description Configuration = WinNT 4.0.0 (build 1381 w/ SP6) Cygwin 1.3.22-1 w/ cygipc-1.13-2 Postgres 7.3.2-1 [PostgreSQL 7.3.2 on i686-pc-cygwin, compiled by GCC gcc (GCC) 3.2 20020927 (prerelease)] Note: Problem may be limited to Windows installation (cygipc?); have reproduced on "virgin" Win2K; have not been able to reproduce under Linux Steps to reproduce == With a running postmaster: * (A) Connect to some existing database with psql (eg. psql -d test_me) - leave this psql running * (B) In another window, issue a command like the following: psql -d test_me < test.sql > /tmp/out where test.sql is a file composed of many, many thousands of the following pair of statements: create table dud_table (f integer); drop table dud_table; Invariably, after some period of time, the second connection (B) will hang. Exiting (A) does not cause (B) to recover, although it does appear crucial to have a connection other than (B) open in order to exercise the bug. (B) will recover if the postmaster is shutdown. Note: There are many variation on this theme, such as starting (A) whilst (B) is running. FYI, encountered this when running unit-tests for our system (which connects to postgres via ODBC). One test, which drops and create a handful of tables along with various other database operations, occasionally hangs. Originally believed the problem to be in our system, then perhaps ODBC, before iterating to the minimalist example above. Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #929: Client connection to postgresql hangs indefinitely (under possibly pathological scenarios)
[EMAIL PROTECTED] writes: > where test.sql is a file composed of many, many thousands of the following pair of > statements: > create table dud_table (f integer); > drop table dud_table; > Invariably, after some period of time, the second connection (B) will > hang. It would help if you would quantify how many create/drop pairs it takes. > Note: Problem may be limited to Windows installation (cygipc?); have > reproduced on "virgin" Win2K; have not been able to reproduce under > Linux If you've tried and failed to reproduce on Linux then the most likely bet is that it's a Cygwin bug. But it would be good to try on some other Unixoid platforms before pointing a finger in that direction. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #929: Client connection to postgresql hangs indefi
> > where test.sql is a file composed of many, many thousands > of the following pair of statements: > > create table dud_table (f integer); > > drop table dud_table; > > Invariably, after some period of time, the second > connection (B) will > > hang. > > It would help if you would quantify how many create/drop > pairs it takes. [Lots. Ok, I know that doesn't help. =] The thing is, it happens occasionally. The more statements you throw at it, the more likely it is to hang before completing the file... As an attempt at quantification, I'll say this. We are currently using a test file with about 5000 pairs of create/drop. It (almost?) never makes it through a pass of this file. Your mileage may vary. > > Note: Problem may be limited to Windows installation (cygipc?); have > > reproduced on "virgin" Win2K; have not been able to reproduce under > > Linux > > If you've tried and failed to reproduce on Linux then the most likely > bet is that it's a Cygwin bug. But it would be good to try on some > other Unixoid platforms before pointing a finger in that direction. Absolutely. Certainly possible to imagine some form of race condition in cygipc being responsible, but I'm only guessing from the symptoms (not from any knowledge of the implementation of either postgres or cygwin/ipc). Cheers, Claudio Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #929: Client connection to postgresql hangs indefi nitely (under possibly pathological scenarios)
Claudio Natoli <[EMAIL PROTECTED]> writes: > As an attempt at quantification, I'll say this. We are currently using a > test file with about 5000 pairs of create/drop. It (almost?) never makes it > through a pass of this file. Your mileage may vary. FWIW, I ran 1 create/drop pairs through 7.3.2 (well, actually REL7_3 branch tip, but I'll be *real* surprised if it differs on this point) on HPUX 10.20. No sign of a problem. You did say you tried already on Linux, right? Which version exactly? Can someone try the experiment on some *BSD platform? Three data points would make me reasonably comfortable that it doesn't fail on Unixen, and then I'll say Cygwin gets the blame... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Bug #929: Client connection to postgresql hangs indefi
> You did say you tried already on Linux, right? Which version exactly? Red Hat Linux release 7.2 (Enigma) Kernel 2.4.7-10 > Can someone try the experiment on some *BSD platform? Three > data points would make me reasonably comfortable that it doesn't fail on > Unixen, and then I'll say Cygwin gets the blame... Sounds reasonable. I'd also like to get confirmation from another cygwin user too... any takers? Cheers, Claudio Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #928: server_min_messages (log_min_messages in CVS)
On Sun, 2003-03-30 at 19:20, Bruce Momjian wrote: > The issue was that you might want to increase server logging in certain > clients to help debug a problem. That seems a little obscure to me -- IMHO it's not really worth adding additional GUC complexity to account for it. Why not just use SUSET, and then consider how to change it if someone complains? Cheers, Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] Suggestion
hello, im using PostgreSQL 7.3.1 on i686-pc-linux-gnu, compiled by GCC 2.96. i have a suggestion for the name of this DBMS, and that it should not be PostgreSQL but it should be PregreSQL, as im feeling its a DBMS that perhaps might be used 100 years ago,,proof for this is its techniques for showing errors that if we have a 1400 lines sql query contain some error,,it give error as " parse error at or near " ,,now if that column is used at several places ,,we might have to browse the whole of the cream... this is one of example of the limit of stupidity this DBMS having,,, this used to waste the time that should be spent in development...so consider changing the name of this stupid DBMS,, regards Muhammad Umar Liaquat Database Administrator Vigilant Systems Limited. __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] [ADMIN] Can't connect to my postgresql
Daniel Rubio <[EMAIL PROTECTED]> writes: > Yes, there's a core in the data directory, here is the stack trace: > bash-2.03# pstack /apps/pgsql-7.3.2/data/core > core '/apps/pgsql-7.3.2/data/core' of 6308: > /apps/pgsql-7.3.2/bin/postmaster -D /apps/pgsql-7.3.2/da > 00123e24 user_group_bsearch_cmp (33d689, 0, , 0, 0, 0) + 10 > fef36048 bsearch (8, fffc, 0, 4, 0, 123e14) + 4c > 00123ecc get_user_line (33d689, a, 1, 2, 0, 8000) + 30 > 00122ccc md5_crypt_verify (33d558, 33d689, 32a188, 318249, 2b4198, > 2d0ea3) + 2c After staring at the code for awhile, the only scenario I can construct goes like this: 1. You had a $PGDATA/global/pg_pwd file when you started the postmaster. 2. For some reason, the file disappeared or became unreadable. 3. At the next SIGHUP, load_user() would delete user_lines and then exit, leaving user_sorted pointing at pfree'd memory. 4. The above crash is then exactly what one would expect. load_user and load_group are clearly buggy in that they don't take care to keep the data structures in sync after an open failure --- but I'm having a hard time concocting a reason why pg_pwd would disappear like that. Ideas anyone? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
