On 04/10/10 10:56, Tom Lane wrote:
> Craig Ringer writes:
>> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
>> been able to get a backtrace yet. I thought it'd be trivial given the
>> ease of reproducing the crash - but the process that's crashing isn't
>> the backend r
> It'd be really helpful if you could provide the contents of the Windows
> error log from when you attempted to start the service before making the
> change. You can get to the Event Viewer in the Start menu on Win7.
Any luck finding this?
--
Craig Ringer
Tech-related writing: http://soapyfro
Craig Ringer writes:
> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
> been able to get a backtrace yet. I thought it'd be trivial given the
> ease of reproducing the crash - but the process that's crashing isn't
> the backend running the query.
> It looks like it's o
On 10/03/2010 05:11 PM, Andrea Peri wrote:
Hi, thx for response.
>Does that include PostGIS datatypes?
yes, but after some email with the guys of Posgis team , I think the
problem is related to postgres.
(see this thread on postgis ML):
http://postgis.refractions.net/pipermail/postgis-users/2
On 4/10/2010 4:41 AM, Andrea Peri 2007 wrote:
Hi,
I have some update on the crash of pg9.0.
seem that PG9 will crash even on windows 32bit.
Yes, it will. I've just been able to reproduce it here with your script,
on 32-bit win7. I should be able to report where it's crashing shortly.
I gav
Hi,
I have some update on the crash of pg9.0.
seem that PG9 will crash even on windows 32bit.
But meanwhile in win7-64 bit crash always at first try, in win7 32bit it
crash
from first and second time after restart.
As report here from Postgis Team.
http://postgis.refractions.net/pipermail/p
Tom Lane wrote:
> Hm ... seems to me that is a network security problem, not our problem.
> Who's to say one of the spoofed packets won't pass verification?
The packets are signed with a shared key. Passing verification means
either the attacker knows the key, or the attacker has broken MD5 in
>Truly, the most helpful thing at this point would be to collect a
backtrace showing where in the postgresql server it crashed.
>There are instructions on how to do that here:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>In your case, a
The following bug has been logged online:
Bug reference: 5690
Logged by: Tony marston
Email address: t...@marston-home.demon.co.uk
PostgreSQL version: 9.0
Operating system: Windows XP
Description:pg_upgrade fails
Details:
I am trying to upgrade from version 8.4 to 9
Magnus Hagander writes:
> On Sun, Oct 3, 2010 at 00:52, Tom Lane wrote:
>> [ scratches head ... ] I don't see the problem.
> I think he's referring to the ability to flood the postgresql server
> with radius packets with spoofed IP source, correct?
Hm ... seems to me that is a network security
Magnus Hagander wrote:
> I think he's referring to the ability to flood the postgresql server
> with radius packets with spoofed IP source, correct?
Yes. Or, with any number of other "bad" packets.
> If we then looped
> until we got one that validated as a proper packet, we'd still be able
> t
Tom Lane wrote:
> [ scratches head ... ] I don't see the problem. AFAICS the "verify
> packet" code is just looking at local storage. Where is the spoofing
> possibility, and why would delaying the socket close accomplish
> anything?
Looking at local storage isn't the issue. There is no buff
Hi, thx for response.
>Does that include PostGIS datatypes?
yes, but after some email with the guys of Posgis team , I think the problem
is related to postgres.
(see this thread on postgis ML):
http://postgis.refractions.net/pipermail/postgis-users/2010-October/027841.html
The postgis team was
13 matches
Mail list logo
