We have in our local network a server with a Postgres-Installation. Now, as some big inserts (needed days) were running, others had problems connecting via pgadmin. After opening the Server in pgadmin (that would showing the tables in the overview) pgadmin was trying and trying, without progress. As I understand that the inserts can slow down access to the same database, it shouldn't prevent them at all, am I right? So what's going wrong here?
We have a postgres-databse under windows, that is version 9.1. From that we want to dump the data and import under a Linux-server, that runs Postgres 8.4. The data include spatial data with Postgis.
The problem is, that the dump doesn't import, as it uses commands like 'CREATE EXTENSION ..' that can't be understand on the older Postgres. Is there a way to transfer the data between these databases?
I know I can list the triggers with \dft. But how can I see one concrete trigger? I want to know details like on which events the trigger is executed, which function is executed and so on.
In RFC 2822 (defining E-Mail) is defined, that no line SHOULD be longer than 78 chars (excluding CRLF) and MUST not longer than 998 characters. With quoted-printable longer lines will be broken into more lines, ending each with a '=' until the real linebreak is reached. Conforms a mail to the standard, if it contains lines longer than 78 (or 998) characters but is encoded with quoted-printable?
There are arguments, that this isn't compliant, because the receiving mail-client has longer lines after decoding the quoted-printable message.
EDIT: To clarify the question in the way as asked by David Cary: Yes, I mean the quote-printable encoded mail should be compatible to quoted-printable, means the lines are no longer than 76 characters. But the decoded messages may have longer lines than this limit. So my question is: Is client software implementing RFC 1521 supposed to handle indefinitely long lines after decoding quoted-printable text content? This is answered yes with both answers so far (thanks) with the restriction that it is discouraged by Netiquette (RFC 1855). But Netiquette even limits a line length to 65 characters, a limit nearly nobody adheres to.
I want to access Tomcat through the Apache-webserver using connectors. I sticked to the documentation: http://tomcat.apache.org/connectors-doc/generic_howto/quick.html I only modified it a little to match directory-structure used on my Debian-(Squeeze)-System.
So I added the following to /etc/apache2/httpd.conf:
# Load mod_jk module
# Update this path to match your modules location
#LoadModule jk_module libexec/mod_jk.so
# Declare the module for <IfModule directive> (remove this line on Apache 2.x)
#AddModule mod_jk.c
# Where to find workers.properties
# Update this path to match your conf directory location (put workers.properties next to httpd.conf)
JkWorkersFile /etc/apache2/workers.properties
# Where to put jk shared memory
# Update this path to match your local state directory or logs directory
JkShmFile /var/log/apache2/mod_jk.shm
# Where to put jk logs
# Update this path to match your logs directory location (put mod_jk.log next to access_log)
JkLogFile /var/log/apache2/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the timestamp log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# Send everything for context /examples to worker named worker1 (ajp13)
JkMount /tomcat7/* worker1
I commented out the loading of the module, because that already happens, after I installed mod_jk through the package-system (libapache2-mod-jk).
My workers.properties look like this:
# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
Tomcat 7 is installed directly from archive from Apache, because it is not a package in Squeeze. Tomcat 7 is running and reachable under it's own port (8180, to not collide with tomcat6 from the package-system). As far as I understand, I should see now the tomcat-site with http://host/tomcat7/. But I get a 404 instead. What is wrong?
After quanta hinted to set the log-level to debug (thanks) I did that and found the following error-message in mod_jk.log: 'jk_map_to_storage::mod_jk.c (3585): missing uri map for 176.9.9.55:/tomcat7/'. I googled for that and found http://old.nabble.com/mod_jk%2C-missing-uri-map-td23984359.html
So the options set in httpd.conf weren't used in VirtualHosts. I added 'JkMountCopy On' to my VirtualHost - and got first a Tomcat 404 (instead of the httpd 404). Problem here, that he tries to access the exact same URI mounted, so in my case /tomcat7. I used instead the name of the webapp as mount and everything is fine for me.
The Apache-webserver starts in out configuration a CGI-script for some requests. That is a shell-script, that basically starts a mapserver with some parameters. As the mapserver-process uses many resources, we want to limit the number of processes started at the same time.