Rural Hunter wrote:
I'm seeing connection hang issue these days. many concurrent
connections are hanging on db. They basically do the same thing:
update different rows in same table. The sql itself should run very
fast as it's updating just one row based on an unique key.
update article
Hi!
I don't see a WHERE clause, so it looks like you're updating the
whole table each time.
it's got a substr(pg_stat_activity.current_query,1,30) in it, so we shall
hardly see anything about the WHERE clause, but we'd really need to have
more info about it.
Bèrto
--
yes, it's truncated. the full sql is like this:
update article set
tm_update=$1,rply_cnt=$2,read_cnt=$3,tm_last_rply=$4 where
title_hash=$5
the title_hash is unique.
I dig another case more and found something interesting. it's actually
waiting for a lock of type transactionid. I ran the
Hi all,
I have a requirement for PG (9.1) to run without any open port at all.
Everything is fine, but the stats collector seems to be unable to work
unless the port is left open on the fw. Is there any way to tell the stats
they should use a unix socket in instead? Google did not offer much on
Rural Hunter ruralhun...@gmail.com writes:
yes, it's truncated. the full sql is like this:
update article set
tm_update=$1,rply_cnt=$2,read_cnt=$3,tm_last_rply=$4 where
title_hash=$5
the title_hash is unique.
I dig another case more and found something interesting. it's actually
waiting
Hi,
I dig another case more and found something interesting. it's actually
waiting for a lock of type transactionid. I ran the query below 3
Normal. That's the kind of lock you are waiting for when some other
transaction has touched the same rows for update that you are
attempting.
well, thanks. I checked the application and found there was a bug
causing many queries were updating the same row. However, those updates
are just single statement, no multi-statement transaction involved. So
I still have this question:
same statement A,B,C,D update same row. The start order is
Rural Hunter ruralhun...@gmail.com wrote:
I still have this question:
same statement A,B,C,D update same row. The start order is
A-B-C-D. From what I've gotten, B/C/D got the lock before A.
Why did that happen?
Did you do anything to prevent it from happening? If not, the OS
scheduler
=?UTF-8?B?QsOocnRvIMOrZCBTw6hyYQ==?= berto.d.s...@gmail.com writes:
I have a requirement for PG (9.1) to run without any open port at all.
That's a pretty stupid requirement. The stats collector socket is bound
to itself, so it's inaccessible from anywhere else (on machine or off)
regardless of
Hi!
That's a pretty stupid requirement. The stats collector socket is bound
to itself, so it's inaccessible from anywhere else (on machine or off)
regardless of firewall settings. There's no need to worry about it,
and no there is not a provision for doing it via unix socket instead.
On Wed, Dec 21, 2011 at 9:21 AM, Bèrto ëd Sèra berto.d.s...@gmail.comwrote:
Hi!
That's a pretty stupid requirement. The stats collector socket is bound
to itself, so it's inaccessible from anywhere else (on machine or off)
regardless of firewall settings. There's no need to worry about
Hi!
Can you create a virtual network interface, assign an address to it and
have PostgreSQL listen to it in addition to the socket? I'm thinking not
the eth0:X type but potentially what VirtualBox (vboxnet0), VMware (vmnet0)
or other virtualization products do using brctl.
This might
Hi all,
I need to convert my database from codification WIN1252 to UTF8,
I've try to use pg_dump -U postgres -h 192.168.0.192 -E UTF8 -v -F p -f
bkp.sql database
but I have to following erro:
pg_dump: SQL command failed
pg_dump: Error message from server: ERRO: caracter 0x8d da codificação
Hi, everyone
I've got 32,404 rows of data in a staging table (marcxml_import) that I'm
trying to get into my production table (biblio.record_entry) in my database
(evergreen). When trying to do so, I'm getting the following error:
evergreen=# INSERT INTO biblio.record_entry (marc,
On 12/21/11 12:34 PM, Elliot Voris wrote:
Hi, everyone
I've got 32,404 rows of data in a staging table (marcxml_import) that I'm
trying to get into my production table (biblio.record_entry) in my database
(evergreen). When trying to do so, I'm getting the following error:
evergreen=# INSERT
hmmno I didn't do anything. is the lock priority decided by OS not
the DB? I'm confused here. B/C/D started several mins later than A here
while the update statement takes no more than 1 second. of coz there
are hundreds of connections trying to acquire the lock during that
time.
Rural Hunter wrote:
Kevin Grittner wrote:
Rural Hunter wrote:
I still have this question:
same statement A,B,C,D update same row. The start order is
A-B-C-D. From what I've gotten, B/C/D got the lock before A.
Why did that happen?
Did you do anything to prevent it from happening? If not,
-Original Message-
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Maurício Cruz
Sent: 21 December 2011 21:08
To: pgsql-admin@postgresql.org
Subject: [ADMIN] win1252 to UTF8
Hi all,
I need to convert my database from codification WIN1252 to
18 matches
Mail list logo
