Hi,
I had a strange problem this morning - I started a long-running UPDATE
on a heavily indexed table with about 8m rows last night to test a
trigger-based queue (PgQ):
UPDATE eintrag SET mtime=mtime;
This took about 12 hours, during this time our nightly REINDEX script
ran (successfully).
Stephan Szabo schrieb:
AFAICS, our behavior follows SQL.
a NOT IN b is NOT(a IN b)
IN is defined in terms of = ANY.
a =ANY (b) is basically (by my reading of 8.8 anyway):
True if a = bi for some bi in b
False if b is empty or a <> bi for all bi in b
Unknown otherwise
Since a <> NULL returns u
;
The "\\xfc" in the output apparently causes pg_dump to write an "E"
before the string in the parentheses, causing the following error during
execution of the INSERT:
ERROR: type "e" does not exist
I'm not sure whether the "\\xfc" sequence was in t
Hi,
I'm not sure that this is not a configuration or networking issue (so
apologies if it is), but we seem to be getting rare (a few times/day)
failures with ident authentication because several clients attempt to do
it simultaneously over a high-latency connection (capitalized = edited
I
On Fri, 17 Jun 2011 19:51:59 +0200, Tom Lane wrote:
I looked at the glibc source code for getaddrinfo, and it looks like
they do reliably set sin_port to zero when no service argument is
provided, despite the above documentation statement. So that's why it
works for me. But still, if you're o
On Sat, 18 Jun 2011 04:55:59 +0200, Marinos Yannikos
wrote:
sysctl -w net.ipv4.tcp_tw_reuse=1
This fixed the issue apparently, so bind() seems to choose ports in
TIME_WAIT state for some reason with sin_port=0 and that caused it.
Regards,
Marinos
--
Sent via pgsql-bugs mailing list
