I'm using PostgreSQL 10 server version locally for educational purposes, and one of my tasks is to force a PANIC Error on this version just to test how is reported in the log files.
I've edited the /etc/postgresql/10/main/postgresql.conf and modified the following lines:
log_min_messages = PANIC
log_min_error_statement = PANIC
Following PostgreSQL's lastest documentation it specifies that:
PANIC Reports an error that caused all database sessions to
abort.
I wanted to know if there was an easy way to trigger this kind of error and get it to be printed on the log files.
I searched a bit, but didn't find anything that could work easily.
Setting those two parameters to PANIC is not a good idea. Leave them at ERROR or WARNING, PANIC messages will be logged anyway.
There are many ways to provoke a panic. You could for example remove write permissions on the pg_wal directory or other important data structures. Then create some data modification activity (or call pg_switch_wal a couple of times).
Related
Why did I get below error? This error doesn't always happen. It occurred only once. This error came from ResultSet.next(). I am doing some research about it but I couldn't find the main reason. Here is the link that I found for same SLQCODE and SQLSTATE.
DB2 SQL Error: SQLCODE=-1476, SQLSTATE=40506, SQLERRMC=-293, DRIVER=3.63.123
at com.ibm.db2.jcc.am.fd.a(fd.java:666)
at com.ibm.db2.jcc.am.fd.a(fd.java:60)
at com.ibm.db2.jcc.am.fd.a(fd.java:127)
at com.ibm.db2.jcc.am.vn.b(vn.java:4031)
at com.ibm.db2.jcc.t4.db.h(db.java:286)
at com.ibm.db2.jcc.t4.db.a(db.java:244)
at com.ibm.db2.jcc.t4.db.c(db.java:31)
at com.ibm.db2.jcc.t4.r.a(r.java:32)
at com.ibm.db2.jcc.t4.j.Zb(j.ja
DB2 version: DB2 v10.1.0.4
OS: Linux
The underlying error (that caused the rollback) is the -293, which corresponds to SQL0293N (error accessing container). You need to check the details at this link of the documentation.
Don't ignore this error-message, you want to find root cause, from database diagnostics files.
It may be that the issue is only with one specific container that gets occasionally accessed. Or it may have been a temporary issue according to how the container is implemented (file-system, raw, san, device etc).
If your Db2-server has good alerting at operating-system, file-system, and Db2-level then there may have been alerts about the underlying issue.
If the Db2-server runs on Linux/Unix/Windows, then search in the diagnostics files for references to the -1476 and then find other preceding messages. That usually gives more details. You can use the timestamp of the error message to narrow down the diagnostics location where you may find more details. If you find that information, edit your question to include it. You might also add details of the Db2-server version and the operating system on which it runs.
I've an foswiki installation which is really slow (~ 60 seconds for a uncached page). I've tried to profile the installation with NYTProf, according to http://foswiki.org/Support/NYTProfDebugging with the following command:
> sudo -u www-data NYTPROF="file=/tmp/nytprof.out:addpid=1:endatexit=1" perl -wTd:NYTProf view -topic Some.Topic -username MyUsername
The script fails with an exit code 141 when I run it with profiler. If I run it without profiler (remote d:NYTProf) it exits successful and producing output.
After the profiling I've gotten a bunch of profile files in my /tmp directory:
nytprof.out.[841-1860]
But when I try to merge these files, I've get an error for the first file:
> nytprofmerge nytprof.out.*
Profile data incomplete, inflate error -5 ((null)) at end of input file, perhaps the process didn't exit cleanly or the file has been truncated (refer to TROUBLESHOOTING in the documentation)
I can merge the files without the first file, but the results are useless and shows only 87 calls to Foswiki::Sandbox::CORE:open and that's it.
Do I have any chance got get an valid profiling result? Or is there an other tool, that I can use in this case?
I'm not sure why you can't get NYTProfiler to work, we've used it to figure out some performance issues in Foswiki 2.0.2, which have been partially addressed in Foswiki 2.0.3. There are a couple of issues going on, but one major cause is our conversion to UNICODE internally, and some Perl regex issues in perl versions before 5.20. https://rt.perl.org/Public/Bug/Display.html?id=66852
Foswiki 2.0.3 made the following performance updates:
Changed some heavily called internal functions from regular expressions, to index()
Changed EditRowPlugin to generate less html that requires processing by regular expressions in the rendering module.
Made some other improvements to reduce excessive re-reading of topics.
If 2.0.3 doesn't significantly help, Check to see if the problem pages have large tables in them. If so, you might try disabling the EditRowPlugin and use EditTablePlugin.
Other than that, you might try our official support channel #foswiki on IRC, http://irclogs.foswiki.org/
The script fails with an exit code 141 when I run it with profiler.
That suggests the process received a SIGPIPE signal. The sigexit option may help.
If I run it without profiler ... it exits successful and producing output.
You're using sudo so permissions might be an issue, but that's just a guess. You'll need to dig deeper to confirm if a SIGPIPE is being received and why.
I'm not familiar with foswiki. Perhaps someone in that community could be more helpful.
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.
I am in the middle of developing a C extension library for PostgreSQL. I am using a lot of ereport() calls to help with future debugging.
A typical example of usage in my code would be something like this:
ereport(NOTICE, (errmsg("[%s]: Returned nonzero result (%d).", (const char*)__FUNCTION__, ret)) );
However, when I look in /var/log/postgresql/postgresql-8.4-main.log my messages do not seem to be appearing there - only messages from what I assume is the db server daemon.
So, where are my log messages being stored?
BTW, I am running PG 8.4 on Ubuntu Linux (10.0.4)
By default, logging of non-critical messages is not enabled on fresh installs. You configure it by setting log_destination and logging_collector.
PostgreSQL has several logging levels, and by default, NOTICE level is not saved to log files (even when they are enabled) . This is configured by log_min_messages setting. However NOTICE it emitted to client by default. This is configured by client_min_messages setting.
So if you want these to be stored in log files, you will have to either change NOTICE to WARNING in your code, or set log_min_messages = notice.
See this http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html
and maybe this http://www.depesz.com/index.php/2011/05/06/understanding-postgresql-conf-log/
I came across this error that is apparently pretty common among Linux Systems.
"Too many files Open"
In my code I tried to set the Python open file limit to unlimited and it threw an error saying that I could not exceed the system limit.
import resource
try:
resource.setrlimit(resource.RLIMIT_NOFILE, (500,-1))
except Exception as err:
print err
pass
So...I Googled around a bit and followed this tutorial.
However, I set everything to 9999999 which I thought would be as close to unlimited as I could get. Now I cannot open a session as root on that machine. I can't login as root at all and am pretty much stuck. What can I do to get this machine working again? I need to be able to login as root! I am running Centos 6 and it's as up to date as possible.
Did you try turning it off and on?
If this doesn't help you can supply init=/bin/bash as kernel boot parameter to enter a root shell. Or boot from a live cd and revert your changes.
After performing an 'strace su -', I looked for the 'No such file or directory' error. When comparing the output, I found that some of those errors are ok, however, there were other files missing on my problem system that existed on a comparison system. Ultimately, it led me to a faulty line in /etc/pam.d/system-auth-ac referencing an invalid shared object.
So, my recommendation is to go through your /etc/pam.d config files and validate the existence of the shared object libraries, or, look in /var/log/secure and it should give some clue to missing shared objects as well.