Bhushan Verma wrote:
>>> Is it a particular one, or does it crash at random?
>
> its crash at random.
Random segfaults easily by application bugs ( memory corruption,
accessing uninitialized memory and dereferencing pointers there, etc )
or hardware issues like bad CPU/CPU cache/memory, overheat
Meredith L. Patterson wrote:
Magnus Hagander wrote:
this has implications for storing passwords as MD5 hashes. My
That would be the only system use of MD5. What implications are those?
We might want to consider using a safer hash for the password storage at
some point, but from what I ga
Theo Schlossnagle wrote:
> Tom Lane wrote:
>
>> There is no reason for the i386 or AMD64 code to be different from what's
>> already tested on Linux --- the hardware's the same and the OS surely
>> doesn't make a difference at this level.
>
> On linux you use gcc, which allows for inline assembly
The amd64 spintlock instructions use no AMD-specific features. It's
base intel 64bit instruction set. We ship a product with similar such
spin locks and have never had an issue across a large variety of
chipsets (Intel, AMD, and virtualized).
In short, if you can actually run 64bit code,
На Tue, 23 Jun 2009 11:13:21 -0400
Tom Lane записано:
> > 2009-06-23 20:43:42 YEKST WARNING: database "testing" must be vacuumed
> > within 10532638 transactions
> > 2009-06-23 20:43:42 YEKST ааааЁааааа: To avoid a database shutdown,
> > execute a full-database VACUUM in "testing".
>
>
I've just compiled and run the 8.4.RC2 code. For both of the following
queries I get "0009-03-01"
SELECT to_date(' 2009 03', ' MM') as extraspace; --returns
"0009-03-01"
SELECT to_date('2009 03', ' MM') as bogusspace; --returns "0009-03-01"
Was it the intention to imitate Oracle behavi
Andrew Chernow wrote:
>
>> The only issue now is a small leak of memory in a function that is only
>> called a fixed (and very small) number of times per process. Given this,
>> I'm inclined to say we should put it on hold for 8.5. Thoughts?
>>
>>
>
> Doesn't sound urgent to me. If it were my de
The only issue now is a small leak of memory in a function that is only
called a fixed (and very small) number of times per process. Given this,
I'm inclined to say we should put it on hold for 8.5. Thoughts?
Doesn't sound urgent to me. If it were my decision, I'd punt it to 8.5.
Hard to k
Andrew Chernow wrote:
>>
>> Attached is a mix of our two patches. How does that look to you?
>>
>
> looks good.
The next obvious question is, is this something we care to backpatch (at
this point, 8.4 is considered backpatch from that perspective), or
should we hold for 8.5?
The only issue now i
Attached is a mix of our two patches. How does that look to you?
looks good.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hi
Thanks one again for your response.
>>You still haven't posted the offending query,
I am running on shell script that contains various select statment,
one of the example is as follows;
--
SELECT PageIndex,
(SUM(ConnectDoneTime - StartTime) * 100) / SUM(EndTime - StartTime)
AS "
Jim Michaels wrote:
The following bug has been logged online:
Bug reference: 4876
Logged by: Jim Michaels
Email address: jmich...@yahoo.com
PostgreSQL version: 8.3.7-1
Operating system: windows XP Pro SP3
Description:author of MD5 says it's seriously broken - hash
co
Andrew Chernow wrote:
>
>>
>> How about something like this? I switched to using LocalAlloc() in all
>> places to be consistent, instead of mixing heap and local. (Though per
>> doc, LocalAlloc is actually a wrapper for HeapAlloc in win32).
>
> Our patches crossed. Although, in my patch I left t
Bhushan Verma wrote:
>>> postmaster -D /var/lib/pgsql/data
> I am using the same command as you said.
I'm afraid I'm out of ideas on how to get the core dump then.
You could also try attaching gdb to the backend process before it
crashes, and get the backtrace from there. Something along the line
Magnus Hagander wrote:
> Using MD5 for passwords doesn't, afaik, actually require
> collision-resistance. It requires resistance against preimage-attacks,
> which there are none for MD5. At least not yet.
Marc Stevens et al have a chosen prefix attack on MD5 (similar to a
second preimage attack, bu
Richard Tector wrote:
> The following bug has been logged online:
>
> Bug reference: 4877
> Logged by: Richard Tector
> Email address: rich...@tector.org.uk
> PostgreSQL version: 8.3.7
> Operating system: FreeBSD 7.2-RELEASE-p1
> Description:LDAP auth allows empty pass
The following bug has been logged online:
Bug reference: 4877
Logged by: Richard Tector
Email address: rich...@tector.org.uk
PostgreSQL version: 8.3.7
Operating system: FreeBSD 7.2-RELEASE-p1
Description:LDAP auth allows empty password string
Details:
In general the
Bhushan Verma wrote:
>> The core file is generated in the data directory. I believe the default
>> location on Fedora is /var/lib/pgsql/dat
>
> Yes I also think the same.
> But there is no core file in /var/lib/pgsql/dat on my system.
> I am trying to find out why this is not generating core while
2009/6/24 Jeremy Ford :
> I've just compiled and run the 8.4.RC2 code. For both of the following
> queries I get "0009-03-01"
>
> SELECT to_date(' 2009 03', ' MM') as extraspace; --returns
> "0009-03-01"
> SELECT to_date('2009 03', ' MM') as bogusspace; --returns "0009-03-01"
>
> Was it
>The core file is generated in the data directory. I believe the default
>location on Fedora is /var/lib/pgsql/dat
Yes I also think the same.
But there is no core file in /var/lib/pgsql/dat on my system.
I am trying to find out why this is not generating core while log message
"LOG: server proces
Bhushan Verma wrote:
> I have searched for the core file for this pid.
> Is there any spcefic path for the postgres executable?
>
> I have already checked for ulimit -c unlimited etc.
> On my system core file for some other application are generating properly.
The core file is generated in the da
Jim Michaels wrote:
> The following bug has been logged online:
>
> Bug reference: 4876
> Logged by: Jim Michaels
> Email address: jmich...@yahoo.com
> PostgreSQL version: 8.3.7-1
> Operating system: windows XP Pro SP3
> Description:author of MD5 says it's seriously br
Hi,
Thanks for your response.
I am not able to find out the core file.
but in log file its giving the message like:
LOG: server process (PID 29225) was terminated by signal 11: Segmentation
fault
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitia
Thanks for your response.
As follows is log details
ERROR: table "transactionrecord_5917" does not exist
STATEMENT: drop table TransactionRecord_5917;
ERROR: table "pagerecord_5917" does not exist
STATEMENT: drop table PageRecord_5917;
ERROR: table "urlrecord_5917" does not exist
STATEMENT:
On Wednesday 24 June 2009 04:59:05 Jim Michaels wrote:
> If you are looking for hash collision protection, start looking at SHA-256
> or SHA-512.
Well, are we looking for that? We are not using MD5 for digital signatures.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
25 matches
Mail list logo
