On Sun, Oct 3, 2010 at 00:52, Tom Lane wrote:
> "Alan DeKok" writes:
>> CheckRADIUSAuth() in src/backend/libpq/auth.c is subject to spoofing attacks
>> which can force all RADIUS authentications to fail.
>> ...
>> The source IP/port/RADIUS ID && authentication vector fields are checked
>> *after*
On 2/10/2010 9:08 PM, Andrea Peri wrote:
Hi,
I'm using usually
Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.
Now I try-ing the last
Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).
I experience a
crash of Postgres while it is running a huge load of data.
Do
"Alan DeKok" writes:
> CheckRADIUSAuth() in src/backend/libpq/auth.c is subject to spoofing attacks
> which can force all RADIUS authentications to fail.
> ...
> The source IP/port/RADIUS ID && authentication vector fields are checked
> *after* the socket is closed. This allows an attacker to "ra
Mark Kirkwood writes:
> In function open,
> inlined from main at test_fsync.c:66:
> /usr/include/bits/fcntl2.h:45: error: call to __open_too_many_args
> declared with attribute error: open can be called either with 2 or 3
> arguments, not more
Interesting --- it's certainly wrong, but I d
"Peter Ajamian" writes:
> From what I can understand, the UPDATE is trying to lock the index before
> locking the table.
That is not the case, as study of the source code will prove to you.
I think what probably happened here is that the UPDATE was part of
a transaction that already had some rel
The following bug has been logged online:
Bug reference: 5689
Logged by: Peter Ajamian
Email address: pe...@pajamian.dhs.org
PostgreSQL version: 8.4.4
Operating system: CentOS 5.5
Description:UPDATE locks index before table resulting in deadlock
Details:
I got this
Hi,
I'm using usually
Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.
Now I try-ing the last
Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).
I experience a
crash of Postgres while it is running a huge load of data.
This is the report of log.
2010-10-01 22:38:
