Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
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 changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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: drop table URLRecord_5917; LOG: server process (PID 29225) was terminated by signal 11: Segmentation fault LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing FATAL: the database system is in recovery mode LOG: database system was interrupted; last known up at 2009-06-23 12:49:49 IST FATAL: the database system is in recovery mode FATAL: the database system is in recovery mode LOG: database system was not properly shut down; automatic recovery in progress FATAL: the database system is in recovery mode LOG: redo starts at 0/185239F8 FATAL: the database system is in recovery mode FATAL: the database system is in recovery mode FATAL: the database system is in recovery mode LOG: record with zero length at 0/185A67FC LOG: redo done at 0/185A67D0 LOG: last completed transaction was at log time 2009-06-23 14:49:10.37602+05:30 FATAL: the database system is in recovery mode LOG: autovacuum launcher started LOG: database system is ready to accept connections With Regards, Bhushan On 6/24/09, Craig Ringer wrote: > > Bhushan Verma wrote: > > > server closed the connection unexpectedly > > This probably means the server terminated abnormally > > before or while processing the request. > > connection to server was lost > > > Look in the PostgreSQL server logs for more information. It's probably > in /var/log/postgresql or something like that - it depends on exactly > how the distro packaged PostgreSQL. > > -- > > Craig Ringer > -- With Regards, Bhushan
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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; reinitializing FATAL: the database system is in recovery mode LOG: database system was interrupted; last known up at 2009-06-23 12:49:49 IST FATAL: the database system is in recovery mode FATAL: the database system is in recovery mode 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. With Regards, Bhushan On 6/24/09, Heikki Linnakangas wrote: > > Bhushan Verma wrote: > > I am doing some database related queries and this is working fine at > fedora > > core 4. > > But the same database queries giving the FATAL error on fedora 9. > > > > If I restarts the database on fedora core 9 then this is perfectlry > working > > without giving any error. > > > > My postgres version is > > On Fedora core-9[FC9] Machine: > > $ rpm -qa|grep postgres > > postgresql-server-8.3.1-1.fc9.i386 > > postgresql-devel-8.3.1-1.fc9.i386 > > postgresql-python-8.3.1-1.fc9.i386 > > postgresql-8.3.1-1.fc9.i386 > > postgresql-libs-8.3.1-1.fc9.i386 > > > It probably won't solve this problem, but you need to upgrade. The > latest 8.3 release is 8.3.7. See > http://www.postgresql.org/support/versioning > > > > On Fedora core-4[FC49] Machine: > > $ rpm -qa|grep postgres > > postgresql-server-8.0.3-1 > > > ... > > Same here. Latest 8.0 minor release is 8.0.21 > > > > Problem is: > > > > server closed the connection unexpectedly > > This probably means the server terminated abnormally > > before or while processing the request. > > > > connection to server was lost > > > > psql: FATAL: the database system is in recovery mode > > > ... > > > > > server closed the connection unexpectedly > > This probably means the server terminated abnormally > > before or while processing the request. > > connection to server was lost > > psql: FATAL: the database system is in recovery mode > > > > -- > > > > Is this database bug or there is any versioning incopatability. > > > You'll have to give more details or no-one will be able to help you. > Please share the query that caused the crash, and CREATE statements of > all the tables involved in the query. Is there any triggers or anything > else involved? > > Can you get a core dump and post stack trace from it? Something along > the lines of: > 1. ulimit -c unlimited > 2. pg_ctl start > 3. > 4. gdb /usr/bin/postgres /core > 5. bt > > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > -- With Regards, Bhushan
Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
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 > collision resistance problems > Details: > > If you are looking for hash collision protection, start looking at SHA-256 > or SHA-512. > > "In any case, you may not want to be using md5 (at least for > applications requiring collision-resistance), as it is > seriously broken. Use SHA-256 instead." - Ronald Rivest (author of MD5) We are talking about two different uses here, I think. 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. The other use is for hashes in the application, for users of pgcrypto. pgcrypto already provides SHA-256 and SHA-512 for this use. > I was using MD5 in my zapdupes program and was told by the author of MD5, > and switched to SHA-512, because of the size of the files I was dealing > with. since you have BLOBs, I suggest you do the same. There is no hashing of the BLOBs unless you build that into your application, in which case it's your responsibility to use a secure algorithm. PostgreSQL just stores it. > 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 gather it's not really urgent for *that* use. What would be more urgent is to provide a secure hashing *function* to end users that doesn't rely on pgcrypto. But there is a solution for this available today for those who need it - install pgcrypto. > I have implemented SHA-512 as GPL'd code that you may use at PostgreSQL is a BSD project and we have no use for GPL code. We also already have implementations of SHA256 and SHA512 that are BSD licensed in our codebase. > one possibility is that you could make the MD5 function actually return a > SHA-512 hash. That seems like a horrible idea. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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 data directory. I believe the default location on Fedora is /var/lib/pgsql/data -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql: FATAL: the database system is in recovery mode
>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 process (PID 14255) was terminated by signal 11: Segmentation fault" is wriiten in the log file. With Regards, Bhushan On 6/24/09, Heikki Linnakangas wrote: > > 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 data directory. I believe the default > location on Fedora is /var/lib/pgsql/data > > > -- > > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > -- With Regards, Bhushan
Re: [BUGS] BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
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 intention to imitate Oracle behavior for these two cases in this
> release? (8.3.7 returns "0009-03-01" as well)
I think, at this stage (so close to release) we're just trying to keep
up a reasonable compatibility with 8.3 and earlier. The fact that the
"bogus space" case doesn't match the Oracle behaviour might be fertile
ground for future improvement in the 8.5 cycle.
Thanks for testing!
Cheers,
BJ
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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 log message > "LOG: server process (PID 14255) was terminated by signal 11: Segmentation > fault" is wriiten in the log file. Perhaps the ulimit is not in effect after all? Try starting postmaster directly, without pg_ctl: ulimit -c unlimited postmaster -D /var/lib/pgsql/data -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4877: LDAP auth allows empty password string
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 client libraries for PostgreSQL error if an empty password is used. The JDBC drivers do not, and this has uncovered a problem with the server's LDAP authentication code. When authenticating against Active Directory using the method: ldap "ldap://osiris.capl.local/dc=capl,dc=local;CAPL\"; Authentication is successful with both the correct password and an empty password, so long as a valid user is supplied. Using a non-existent username or an incorrect password correctly produces an error and the logon fails. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4877: LDAP auth allows empty password string
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 password string > Details: > > In general the client libraries for PostgreSQL error if an empty password is > used. The JDBC drivers do not, and this has uncovered a problem with the > server's LDAP authentication code. > > When authenticating against Active Directory using the method: > ldap "ldap://osiris.capl.local/dc=capl,dc=local;CAPL\"; > Authentication is successful with both the correct password and an empty > password, so long as a valid user is supplied. Using a non-existent username > or an incorrect password correctly produces an error and the logon fails. Since this is a security related report, it should have been reported to secur...@postgresql.org, as specified on the web form you used. For this reason, we will follow this up on that forum, and post a public followup once the issue has been investigated. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
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, but slightly weaker) which they've successfully used to forge root CA certs, using a cluster of PS3s. Cf. their presentation at 25c3 last December. >> 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 gather it's not really urgent for *that* use. > It would be a lot more urgent if we weren't salting, but IIRC we are. Cheers, --mlp -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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 lines of: postmaster -D /var/lib/pgsql/data psql postgres ... ps ax | grep postgres # check the PID of the backend process psql is connected to. gdb gdb> attach gdb> cont gdb> bt You still haven't posted the offending query, BTW. Is it a particular one, or does it crash at random? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
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 the allocation scheme
> alone since I wasn't sure if someone wanted that way. I'd suggest
> malloc and free if your going to change it. The only time I use an MS
> allocater is when a win32 api function specifically states it must be used.
Attached is a mix of our two patches. How does that look to you?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/port/exec.c
--- b/src/port/exec.c
***
*** 56,62 static int resolve_symlinks(char *path);
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetUserSid(PSID *ppSidUser, HANDLE hToken);
#endif
/*
--- 56,62
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser);
#endif
/*
***
*** 697,703 AddUserToDacl(HANDLE hProcess)
DWORD dwTokenInfoLength = 0;
HANDLE hToken = NULL;
PACL pacl = NULL;
! PSID psidUser = NULL;
TOKEN_DEFAULT_DACL tddNew;
TOKEN_DEFAULT_DACL *ptdd = NULL;
TOKEN_INFORMATION_CLASS tic = TokenDefaultDacl;
--- 697,703
DWORD dwTokenInfoLength = 0;
HANDLE hToken = NULL;
PACL pacl = NULL;
! PTOKEN_USER pTokenUser = NULL;
TOKEN_DEFAULT_DACL tddNew;
TOKEN_DEFAULT_DACL *ptdd = NULL;
TOKEN_INFORMATION_CLASS tic = TokenDefaultDacl;
***
*** 744,758 AddUserToDacl(HANDLE hProcess)
goto cleanup;
}
! /* Get the SID for the current user. We need to add this to the ACL. */
! if (!GetUserSid(&psidUser, hToken))
{
! log_error("could not get user SID: %lu", GetLastError());
goto cleanup;
}
/* Figure out the size of the new ACL */
! dwNewAclSize = asi.AclBytesInUse + sizeof(ACCESS_ALLOWED_ACE) + GetLengthSid(psidUser) -sizeof(DWORD);
/* Allocate the ACL buffer & initialize it */
pacl = (PACL) LocalAlloc(LPTR, dwNewAclSize);
--- 744,762
goto cleanup;
}
! /*
! * Get the user token for the current user, which provides us with the
! * SID that is needed for creating the ACL.
! */
! if (!GetTokenUser(hToken, &pTokenUser))
{
! log_error("could not get user token: %lu", GetLastError());
goto cleanup;
}
/* Figure out the size of the new ACL */
! dwNewAclSize = asi.AclBytesInUse + sizeof(ACCESS_ALLOWED_ACE) +
! GetLengthSid(pTokenUser->User.Sid) -sizeof(DWORD);
/* Allocate the ACL buffer & initialize it */
pacl = (PACL) LocalAlloc(LPTR, dwNewAclSize);
***
*** 785,791 AddUserToDacl(HANDLE hProcess)
}
/* Add the new ACE for the current user */
! if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, psidUser))
{
log_error("could not add access allowed ACE: %lu", GetLastError());
goto cleanup;
--- 789,795
}
/* Add the new ACE for the current user */
! if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, pTokenUser->User.Sid))
{
log_error("could not add access allowed ACE: %lu", GetLastError());
goto cleanup;
***
*** 803,810 AddUserToDacl(HANDLE hProcess)
ret = TRUE;
cleanup:
! if (psidUser)
! FreeSid(psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
--- 807,814
ret = TRUE;
cleanup:
! if (pTokenUser)
! LocalFree((HLOCAL) pTokenUser);
if (pacl)
LocalFree((HLOCAL) pacl);
***
*** 819,846 cleanup:
}
/*
! * GetUserSid*PSID *ppSidUser, HANDLE hToken)
*
! * Get the SID for the current user
*/
static BOOL
! GetUserSid(PSID *ppSidUser, HANDLE hToken)
{
DWORD dwLength;
- PTOKEN_USER pTokenUser = NULL;
if (!GetTokenInformation(hToken,
TokenUser,
! pTokenUser,
0,
&dwLength))
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwLength);
! if (pTokenUser == NULL)
{
log_error("could not allocate %lu bytes of memory", dwLength);
return FALSE;
--- 823,853
}
/*
! * GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser)
! *
! * Get the users token information from a process token.
*
! * The caller of this function is responsible for calling LocalFree() on the
! * returned TOKEN_USER memory.
*/
static BOOL
! GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser)
{
DWORD dwLength;
+ *ppTokenUser = NULL;
if (!GetTokenInformation(hToken,
TokenUser,
! NULL,
0,
&dwLength))
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! *ppTokenUser = (PTOKEN_USER) LocalAlloc(LPTR, dwLength);
!
Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
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 collision resistance problems Details: If you are looking for hash collision protection, start looking at SHA-256 or SHA-512. I personally avoid using sha256 and sha512 because they have proven to be cpu hogs, profilers show them sucking the life out of my applications ... adding large amounts of latency. If you use these, make sure their use is rather small; ie. not for lots of files or blobs. If you realy need good collision detection, I would recommend combining two algorithms into a single hash, like crc32+md5 or md5+sha1. The chances of a collision on both algorithms on the same message becomes far more unlikely. Also, they end up being more efficient than sha256 by itself. -- 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
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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 "ConnectTimePct", (SUM(WriteCompleTime - ConnectDoneTime) * 100) / SUM(EndTime - StartTime) AS "RequestSentTimePct", (SUM(FirstByteRcdTime - WriteCompleTime) * 100) / SUM(EndTime - StartTime) AS "FirstByteTimePct", (SUM(EndTime - FirstByteRcdTime) * 100) / SUM(EndTime - StartTime) AS "DownloadTimePct" FROM UrlRecord_$1 WHERE EndTime <> 0 AND ConnectDoneTime <> 0 AND WriteCompleTime <> 0 AND FirstByteRcdTime <> 0 GROUP By PageIndex ORDER By PageIndex; --- I want to tell you that its happening after sometime ie at random. time is not fixed. >>Is it a particular one, or does it crash at random? its crash at random. On 6/24/09, Heikki Linnakangas wrote: > > 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 lines of: > > > postmaster -D /var/lib/pgsql/data > > psql postgres ... > ps ax | grep postgres # check the PID of the backend process psql is > connected to. > gdb > gdb> attach > gdb> cont > > gdb> bt > > > You still haven't posted the offending query, BTW. Is it a particular > one, or does it crash at random? > > > -- > > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > -- With Regards, Bhushan
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
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
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
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 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? -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
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 keep that win32 acl stuff leak free. There is always a cleanup goto because you need 6 billion objects to answer any question :o -- 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
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
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 decision, I'd punt it to 8.5. Ok. Agreed then - added to the commitfest page. > Hard to keep that win32 acl stuff leak free. There is always a cleanup > goto because you need 6 billion objects to answer any question :o Yeah, true. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
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 behavior for these two cases in this
release? (8.3.7 returns "0009-03-01" as well)
The others in that set of queries all work as expected ("2009-03-01"):
SELECT to_date(' 2009 03', 'MM') as nospace; --returns "2009-03-01"
SELECT to_date(' 2009 03', ' MM') as monthspace; --returns "2009-03-01"
SELECT to_date(' 2009 03', ' MM') as bothspaces; --returns "2009-03-01"
cheers, jeremy.
On Tue, Jun 23, 2009 at 3:55 AM, Tom Lane wrote:
> Brendan Jurd writes:
> > Here's a one-line patch to fix a regression in the new from_char code
> > I introduced into 8.4.
>
> > Versions <= 8.3 skipped over any whitespace immediately preceding any
> > integer field, and this behaviour was lost in HEAD when my from_char
> > patch was committed back in September '08 [1].
>
> Applied along with some regression test additions. Thanks for the
> quick response.
>
>regards, tom lane
>
Re: [BUGS] BUG #4874: vacuum doest work
На 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". > > > but issuing vacuum does not help. > > You need to issue it as a superuser. It helped, thank's a lot. -- With best regards, Roman Galeev -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #2401: spinlocks not available on amd64
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, the CAS stuff should just work. On Jun 24, 2009, at 8:27 AM, Gregory Stark wrote: 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. So, the code is already very different. How does this interact with binary builds such as rpms? If someone installs an amd64 binary on an x86 machine or vice versa does this assembly do the right thing at all? Does it perform slowly? Ideally we would compile both and pick the right one at run-time but that might have annoying overhead if there's a branch before every pg_atomic_cas call. Perhaps a minimal thing to do would be to detect a mismatch on startup and log a message about it. -- Gregory Stark http://mit.edu/~gsstark/resume.pdf -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle p: +1.443.325.1357 x201 f: +1.410.872.4911 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #2401: spinlocks not available on amd64
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. So, the code is > already very different. How does this interact with binary builds such as rpms? If someone installs an amd64 binary on an x86 machine or vice versa does this assembly do the right thing at all? Does it perform slowly? Ideally we would compile both and pick the right one at run-time but that might have annoying overhead if there's a branch before every pg_atomic_cas call. Perhaps a minimal thing to do would be to detect a mismatch on startup and log a message about it. -- Gregory Stark http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
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 gather it's not really urgent for *that* use. It would be a lot more urgent if we weren't salting, but IIRC we are. If we really want something safer for system use in passwords, we ought to be using HMAC instead. I don't believe and weaknesses of MD5 have been found when it is used for HMAC. It has the added advantage that there is no direct storage of the password itself, even in hashed form. Joe -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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, overheating, etc. Are you having issues with any other applications? If you can afford the load, consider running something quite CPU/memory intensive for a while - say, a big compile job - and make sure it all goes smoothly. It'd also be interesting to know whether a separate PostgreSQL instance with a fresh database had issues, but that's probably not practical for you to test. Most likely it's some kind of corrupt database triggering a subtle bug somewhere in Pg, anyway... -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
