Tom Lane wrote:
I think you're getting bit by a standard beginner gotcha: commenting out
an entry in postgresql.conf will not change the state of a running
postmaster. (A comment is a no-op, eh?) You need to put in a
non-comment entry that sets the desired state.
This was indeed the case. I
On Postgres 7.4.1
I've been experiencing some strangeness with the logging settings in
postgresql.conf.
I turned on statement logging (and duration), issued a "pg_ctl reload"
and got it working (logging to sys log and standard out). Now however,
when i try to turn it off, it won't turn off,
Tom Lane wrote:
No, the locks would be held till end of transaction. It is a little odd
that you have so many conflicts, though, unless the referenced table is
pretty small and/or this loop manages to touch a large fraction of the
possible keys.
Ah, well, if the locks are held to the end of th
Tom Lane wrote:
SELECTs don't lock any rows. INSERTs don't create any lockable rows
in themselves (other backends can't even see the rows yet). If that's
all that your transaction is doing, then I think the only explanation
is that the INSERTs are in a table that has foreign keys (correct?)
an
Tom Lane wrote:
No, the ShareLock is the means used when transaction A needs to wait for
transaction B to complete --- it tries to take a share lock on xact B's
XID, which of course is blocked as along as B is holding its
ExclusiveLock. This is used when there is a row-update conflict, ie,
A wan
Recently we discovered that a stored procedure that we run locks some
table(s) and prevents some SQL from running.
We discovered this because doing a simple grep against postgres
processes revealed several processes "WAITING":
-- snip --
00:04:31 postgres: dataman our_db 10.0.0.103 INSERT wai
Markus Wollny wrote:
We're getting "incomplete startup packet" messages in our logfiles due
to some sort of system probe run by our service provider which checks if
PG is still running. In our case they're harmless of course. Are you
sure that you're not running something along those lines, to
Tom Lane wrote:
It's impossible to believe that that's even slightly related.
"Incomplete startup packet" means that you've got broken client-side
software, or perhaps that something is portscanning you. You sure you
weren't seeing those beforehand?
I'm not certain I wasn't seeing those befo
Some time ago, I accidentally did a kill -9 on the postmaster (yes, I
know, I know), when trying to kill -9 one of the child processes (er,
yeah, probably bad too). This turned out to be pretty bad for us. It put
the database in a bad state. I had to run some kind of hacky command (I
don't reca
