[BUGS] BUG #4872: Geometric function problem
The following bug has been logged online: Bug reference: 4872 Logged by: Nick Roosevelt Email address: nro...@thepinc.com PostgreSQL version: 8.2.5 Operating system: Linux Description:Geometric function problem Details: I am getting bad results for distance between point and lseg. As you can see below, the first result is correct, and the second is clearly not. nroose_dev=> select version(); version --- PostgreSQL 8.2.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13) (1 row) nroose_dev=> select point(0,0) <-> lseg(point(10,-100),point(10,450)); ?column? -- 10 (1 row) nroose_dev=> select point(0,0) <-> lseg(point(10,-100),point(11,450)); ?column? -- 100.498756211209 (1 row) nroose_dev=> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Integrity check
Hello, Please can you assist on following questions. * do you any tool to check postgreSQL database integrity check? * how do we confirm that dump file is proper data? * do you any doc to check the integrity of psql db? Venkat Prasad CREDIT SUISSE SCM Systems Support The signature level 4 Changi Business Park Singapore 486066 Phone +65 6306 0310 == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==
Re: [BUGS] BUG #4866: ECPG and BYTEA
Rick Levine wrote: > ECPG does not handle BYTEA columns properly. When I encode a unsigned char > array using PQescapeByteaConn and send it to the server, it is not stored as > the original bytes, but rather is stored as the escaped string (much > larger). Yeah, that's clearly not the right way to do it. You could just use libpq PGExecParams for those queries. I understand that you'd want to stick to the ECPG way of doing things, but that's a good work-around. > We know the coder knows the size of the buffer, but ECPG doesn't, so the > best solution (to my mind) would be to allow the coder to tell ECPG the > buffer size directly. A clean way to do this would be to allow an indicator > variable containing the size, e.g. > > EXEC SQL BEGIN DECLARE SECTION; > unsigned char bytea_hostvar[1024]; > int hostvar_ind = 1024; > EXEC SQL END DECLARE SECTION; > > EXEC SQL AT :connection INSERT INTO Btable > (index, bytea_col) > VALUES > (:index_var, :bytea_hostvar:hostvar_ind); > > I'm just sayin... ;) Yeah, that seems like a clean way to do it. Any idea how this is done in other databases with embedded C support, like DB2 / Informix? Or SQL spec, if it has anything to say about this. It would be good to stay compatible. (I've added this to the TODO list) -- 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] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> Lars Kanis wrote: >>> Maybe version 2 (my initial patch) could be an alternative ? > >> Well, based on the "we don't know which different versions of openssl >> it'll break with", version 2 is no better than version 3 :( > > Yeah, if we do anything I think it should be more like #3. > > I think all or most back releases of openssl are available from > openssl.org. If someone had time to do a test compile of the proposed > patch against all of 'em (or at least all the ones we still claim to > support), it would salve my worries at least a bit. I'm not sure if > that's a big task or not, though. I ran a build with OpenSSL 0.9.8 (default on my machine) and 0.9.7. AFAICS, only 0.9.8 is supported at all these days. There is no point in running against <0.9.7, since there was no engine support in that. I tried 0.9.7m, 0.9.7c, 0.9.8g (Ubuntu) and 0.9.8b just to be sure. But they do seem to have a policy similar to our own - no features in backbranches. I only tested building (make clean, re-configure, make in pg) and it worked fine. Default configuration on OpenSSL. This is certainly not an exhaustive test, but I think it does a fair job of bracketing the possible versions with issues. //Magnus -- 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 #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote:
> Magnus Hagander writes:
>> On 22 jun 2009, at 18.05, Tom Lane wrote:
>>> I'm also a bit concerned about wrapping a struct
>>> field inside such an #if, as that's likely to cause hard-to-debug
>>> problems if two compilations read libpq-int.h with different #define
>>> environments.
>
>> Since it's a pointer we could just declare it as void, no? Or even #if
>> between void and "real" pointer. Wouldn't that be safe?
>
> Yeah, on reflection I think it'd be safe to do
>
> #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
> ENGINE *ptr;
> #else
> /* dummy field to keep struct the same if OpenSSL version changes */
> void*ptr;
> #endif
>
> (probably that #if should get wrapped up in an additional #define
> instead of being duplicated in several places...)
Attached is an updated patch that does both of these.
>> (we already have a similar issue with the whole #ifdef use_ssl, don't
>> we? But having one isn't an excuse to create another of course…)
>
> That's controlled by an entry in pg_config.h, though, and won't change
> if someone happens to update their openssl install and then recompile
> only parts of libpq.
True, agreed.
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/interfaces/libpq/fe-secure.c
--- b/src/interfaces/libpq/fe-secure.c
***
*** 31,36
--- 31,37
#include "libpq-fe.h"
#include "fe-auth.h"
#include "pqsignal.h"
+ #include "libpq-int.h"
#ifdef WIN32
#include "win32.h"
***
*** 62,68
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L)
#include
#endif
! #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
#include
#endif
--- 63,69
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L)
#include
#endif
! #ifdef USE_SSL_ENGINE
#include
#endif
***
*** 661,667 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
*/
if (conn->sslkey && strlen(conn->sslkey) > 0)
{
! #if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined(OPENSSL_NO_ENGINE)
if (strchr(conn->sslkey, ':')
#ifdef WIN32
&& conn->sslkey[1] != ':'
--- 662,668
*/
if (conn->sslkey && strlen(conn->sslkey) > 0)
{
! #ifdef USE_SSL_ENGINE
if (strchr(conn->sslkey, ':')
#ifdef WIN32
&& conn->sslkey[1] != ':'
***
*** 669,683 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
)
{
/* Colon, but not in second character, treat as engine:key */
- ENGINE *engine_ptr;
char *engine_str = strdup(conn->sslkey);
char *engine_colon = strchr(engine_str, ':');
*engine_colon = '\0'; /* engine_str now has engine name */
engine_colon++; /* engine_colon now has key name */
! engine_ptr = ENGINE_by_id(engine_str);
! if (engine_ptr == NULL)
{
char *err = SSLerrmessage();
--- 670,683
)
{
/* Colon, but not in second character, treat as engine:key */
char *engine_str = strdup(conn->sslkey);
char *engine_colon = strchr(engine_str, ':');
*engine_colon = '\0'; /* engine_str now has engine name */
engine_colon++; /* engine_colon now has key name */
! conn->engine = ENGINE_by_id(engine_str);
! if (conn->engine == NULL)
{
char *err = SSLerrmessage();
***
*** 690,696 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
return 0;
}
! *pkey = ENGINE_load_private_key(engine_ptr, engine_colon,
NULL, NULL);
if (*pkey == NULL)
{
--- 690,711
return 0;
}
! if (ENGINE_init(conn->engine) == 0)
! {
! char *err = SSLerrmessage();
!
! printfPQExpBuffer(&conn->errorMessage,
! libpq_gettext("could not initialize SSL engine \"%s\": %s\n"),
! engine_str, err);
! SSLerrfree(err);
! ENGINE_free(conn->engine);
! conn->engine = NULL;
! free(engine_str);
! ERR_pop_to_mark();
! return 0;
! }
!
! *pkey = ENGINE_load_private_key(conn->engine, engine_colon,
NULL, NULL);
if (*pkey == NULL)
{
***
*** 700,705 client_cert_cb(SSL *ssl, X509 **x509, EVP_PKEY **pkey)
--- 715,723
libpq_gettext("could not read private SSL key \"%s\" from engine \"%s\": %s\n"),
engine_colon, engine_str, err);
SSLerrfree(err);
+ ENGINE_finish(conn->engine);
+ ENGINE_free(conn->engine);
+ conn->engine = NULL;
free(engine_str);
ERR_pop_to_mark();
return 0;
***
*** 1217,1222 close_SSL(PGconn *conn)
--- 1235,1249
X509_free(conn->peer);
conn->peer = NULL;
}
+
+ #ifdef USE_SSL_ENGINE
+ if (conn->engine)
+ {
+ ENGINE_finish(conn->engine);
+ ENGINE_free(conn->engine);
+ conn->engine = NULL;
+ }
+ #endif
}
/*
*** a/src/interfaces/libpq/libpq-int.h
--- b/src/interfaces/libpq/libpq-int.h
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
At present, a specific error, crash or trouble seems not to have happened. The reason its not crashing is that most, if not all, windows allocation functions know which addresses belong to them. FreeSid is actually documented as returning NULL on success. On failure it returns the address you tried to free. Although the FreeSid call causes no harm because its defensive, there is still the issue of leaking the TOKEN_USER structure. -- 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] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Am Dienstag, 23. Juni 2009 14:17:15 schrieben Sie: > Attached is an updated patch that does both of these. It works for me, but I could test it only with OpenSSL 0.9.8g. Moreover I tested the SSL-renegotiation, and it works quite fine with an engine too - as long as I don't pull the smartcard with the auth-key out of the reader :) regards Lars Kanis signature.asc Description: This is a digitally signed message part.
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Magnus Hagander writes: > Attached is an updated patch that does both of these. This looks reasonably sane to me, and I'm satisfied with the testing that's been done. No objection from here. regards, tom lane -- 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 #4874: vacuum doest work
The following bug has been logged online: Bug reference: 4874 Logged by: Roman Galeev Email address: i...@ncom-ufa.ru PostgreSQL version: 8.1 Operating system: Debian Sarge Description:vacuum doest work Details: I've constantly got messages like this: 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. I've issued vacuum, vacuum full, vacuum freeze several times. The only change I see is decreasing number of transactions. -- 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:
> TAKATSUKA Haruka wrote:
>> Hi.
>>
>> We found the unbalance of xxAlloc and xxFree at AddUserToDacl() in
>> src/port/exec.c (of current HEAD code).
>>
>> psidUser is a pointer of the element of a TOKEN_USER structure
>> allocated by HeapAlloc(). The FreeSid() frees a SID allocated by
>> AllocateAndInitializeSid(). I think that it is correct to use
>> HeapFree(GetProcessHeap(), 0, pTokenUser).
>>
>> At present, a specific error, crash or trouble seems not to have
>> happened.
>>
>>
>> src/port/exec.c:748 AddUserToDacl()
>> src/port/exec.c:841 GetUserSid()
>> pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(),
>> HEAP_ZERO_MEMORY, dwLength);
>>
>> src/port/exec.c:807 AddUserToDacl()
>> FreeSid(psidUser);
>
> I quickly poked around and found what I believe to be two memory issues.
>
> 1. GetUserSid() uses HeapAlloc() to allocate a TOKEN_USER, but never
> calls HeapFree() if the function succeeds. Instead, it pulls out the
> token's SID and returns it. This is a memory leak.
>
> 2. The SID returned by GetUserSid() is incorrectly being passed to
> FreeSid() within AddUserToDacl()'s cleanup section. This memory belongs
> to the TOKEN_USER allocated by HeapAlloc() in GetUserSid(), it cannot be
> passed to FreeSid.
>
> Quick question, Why HeapAlloc and LocalAlloc. Why not use malloc?
>
> One solution would be to return a copy of the SID from GetUserSid and
> HeapFree the TOKEN_USER.
>
> Replace GetUserSid() line 869
>
> *ppSidUser = pTokenUser->User.Sid;
> return TRUE;
>
> With the below (error checking excluded)
>
> DWORD len = GetLengthSid(pTokenUser->User.Sid)
> *ppSidUser = (PSID) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
> CopySid(len, *ppSidUser, pTokenUser->User.Sid);
>
> // SID is copied, free TOKEN_USER
> HeapFree(GetProcessHeap(), 0, pTokenUser);
> return TRUE;
>
> Also, AddUserToDacl() line 807
>
> FreeSid(psidUser) should be HeapFree(GetProcessHeap(), 0, psidUser)
>
> in order to work with my suggested changes in GetUserSid().
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).
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/port/exec.c
--- b/src/port/exec.c
***
*** 804,810 AddUserToDacl(HANDLE hProcess)
cleanup:
if (psidUser)
! FreeSid(psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
--- 804,810
cleanup:
if (psidUser)
! LocalFree((HLOCAL) psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
***
*** 822,827 cleanup:
--- 822,830
* GetUserSid*PSID *ppSidUser, HANDLE hToken)
*
* Get the SID for the current user
+ *
+ * The caller of this function is responsible for calling LocalFree() on the
+ * returned SID area.
*/
static BOOL
GetUserSid(PSID *ppSidUser, HANDLE hToken)
***
*** 838,844 GetUserSid(PSID *ppSidUser, HANDLE hToken)
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwLength);
if (pTokenUser == NULL)
{
--- 841,847
{
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER)
{
! pTokenUser = (PTOKEN_USER) LocalAlloc(LPTR, dwLength);
if (pTokenUser == NULL)
{
***
*** 859,872 GetUserSid(PSID *ppSidUser, HANDLE hToken)
dwLength,
&dwLength))
{
! HeapFree(GetProcessHeap(), 0, pTokenUser);
pTokenUser = NULL;
log_error("could not get token information: %lu", GetLastError());
return FALSE;
}
! *ppSidUser = pTokenUser->User.Sid;
return TRUE;
}
--- 862,895
dwLength,
&dwLength))
{
! LocalFree(pTokenUser);
pTokenUser = NULL;
log_error("could not get token information: %lu", GetLastError());
return FALSE;
}
! /*
! * Need to copy the data to a separate buffer, so we can free our buffer
! * and let the caller free only the sid part.
! */
! dwLength = GetLengthSid(pTokenUser->User.Sid);
! *ppSidUser = (PSID) LocalAlloc(LPTR, dwLength);
! if (!*ppSidUser)
! {
! LocalFree(pTokenUser);
! log_error("could not allocate %lu bytes of memory", dwLength);
! return FALSE;
! }
! if (!CopySid(dwLength, *ppSidUser, pTokenUser->User.Sid))
! {
! LocalFree(*ppSidUser);
! LocalFree(pTokenUser);
! log_error("could not copy SID: %lu", GetLastError());
! return FALSE;
! }
!
! LocalFree(pTokenUser);
return TRUE;
}
--
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
DWORD len = GetLengthSid(pTokenUser->User.Sid)
*ppSidUser = (PSID) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
CopySid(len, *ppSidUser, pTokenUser->User.Sid);
I attached a patch for this. Although, I did not use CopySid. Instead,
I changed GetUserSid to GetTokenUser. AddUserToDacl() is the only
function making use of GetUserSid(), so this change won't break
anything. The benefit to this approach over my first suggestion is that
it avoids an unneeded HeapAlloc(sid), CopySid(sid) ... and its cleaner.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/port/exec.c
===
RCS file: /projects/cvsroot/pgsql/src/port/exec.c,v
retrieving revision 1.63
diff -C6 -r1.63 exec.c
*** src/port/exec.c 11 Jun 2009 14:49:15 - 1.63
--- src/port/exec.c 23 Jun 2009 14:57:46 -
***
*** 53,65
static int validate_exec(const char *path);
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
/*
* validate_exec -- validate "path" as an executable file
*
* returns 0 if the file is found and no error is encountered.
--- 53,65
static int validate_exec(const char *path);
static int resolve_symlinks(char *path);
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser);
#endif
/*
* validate_exec -- validate "path" as an executable file
*
* returns 0 if the file is found and no error is encountered.
***
*** 694,706
ACCESS_ALLOWED_ACE *pace;
DWORD dwNewAclSize;
DWORD dwSize = 0;
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;
BOOL ret = FALSE;
/* Get the token for the process */
--- 694,706
ACCESS_ALLOWED_ACE *pace;
DWORD dwNewAclSize;
DWORD dwSize = 0;
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;
BOOL ret = FALSE;
/* Get the token for the process */
***
*** 741,761
AclSizeInformation))
{
log_error("could not get ACL information: %lu", GetLastError());
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);
if (pacl == NULL)
{
log_error("could not allocate %lu bytes of memory", dwNewAclSize);
--- 741,764
AclSizeInformation))
{
log_error("could not get ACL information: %lu", GetLastError());
goto cleanup;
}
! /* Get the user token for the current user. This provides us with the
! * user's SID which 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);
if (pacl == NULL)
{
log_error("could not allocate %lu bytes of memory", dwNewAclSize);
***
*** 782,794
log_error("could not add ACE: %lu", GetLastError());
goto cleanup;
}
}
/* 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;
}
/* Set the new DACL in the token */
--- 785,797
log_error("could not add ACE: %lu", GetLastError());
goto cleanup;
}
}
/* 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;
}
/* Set the new DACL in the token */
***
*** 800,813
goto cleanup;
}
ret = TRUE;
cleanup:
! if (psidUser)
! FreeSid(psidUser);
if (pacl)
LocalFree((HLOCAL) pacl);
if (ptdd)
LocalFree((HLOCAL) ptdd);
--- 803,816
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
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. -- 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] BUG #4872: Geometric function problem
"Nick Roosevelt" writes: > I am getting bad results for distance between point and lseg. As you can > see below, the first result is correct, and the second is clearly not. Hmm ... what it looks like to me is that there's an ancient thinko in dist_ps_internal(). It's trying to calculate the slope of the perpendicular to the given line segment, and it gets it wrong. The segment's own slope would be deltaY / deltaX, so the slope of the perpendicular should be the negative inverse of that, ie -deltaX / deltaY, but what it was actually calculating was -deltaY / deltaX. So it was getting the wrong answers for any situation where the given line segment's slope wasn't +1/-1 (or 0 or infinite, which are correctly special-cased). Depressingly, fixing this changes none of the regression test outputs; apparently all the test cases involving distances were one of the special cases. But it's really amazing no one complained of this before ... regards, tom lane -- 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 #4874: vacuum doest work
"Roman Galeev" writes: > I've constantly got messages like this: > 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. regards, tom lane -- 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 #4873: docs: no link from dml-update to sql-update
The following bug has been logged online: Bug reference: 4873 Logged by: Brad Bowman Email address: postg...@bereft.net PostgreSQL version: 8.3 Operating system: n/a Description:docs: no link from dml-update to sql-update Details: There seems to be an oversight in the dml-update document. http://www.postgresql.org/docs/8.3/interactive/dml-update.html doesn't link to http://www.postgresql.org/docs/8.3/interactive/sql-update.html while both dml-insert and dml-delete do link to their respective pages. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Password problem
Hi i downloaded the program but i cant install cause i need a password. so i create onw buy nothing, wrong password wrong password, 8 months ago y install it the but now i cant remenber the password, i installed in otrer computer? why cant i installed here? Please help me
Re: [BUGS] BUG #4869: No proper initialization of OpenSSL-Engine in libpq
Tom Lane wrote: > Magnus Hagander writes: >> Attached is an updated patch that does both of these. > > This looks reasonably sane to me, and I'm satisfied with the testing > that's been done. No objection from here. Applied. //Magnus -- 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 #4866: ECPG and BYTEA
This is how Oracle does it. The equivalent data type to BYTEA in Oracle is RAW. You can use a host variable to specify the length as well. EXEC SQL BEGIN DECLARE SECTION; unsigned char *bytea_hostvar; EXEC SQL VAR bytea_hostvar IS RAW(1024); EXEC SQL END DECLARE SECTION; ANSI SQL 92 specifies the BIT [VARYING] type, but no mention of a byte data type. ANSI SQL 92, section 11.28, specifies a CREATE CHARACTER SET You might be able to shoehorn raw bytes in with that, but it wouldn't be very intuitive, to say the least. It doesn't solve the basic problem of conveying a buffer size to the embedded language parser for a data type without a length specified in the schema. I ended up using Postgres' BIT data type, which works just fine, but really expands the data passed between client and server. From: Heikki Linnakangas To: Rick Levine Cc: pgsql-bugs@postgresql.org Date: 06/23/2009 04:09 AM Subject: Re: [BUGS] BUG #4866: ECPG and BYTEA Rick Levine wrote: > ECPG does not handle BYTEA columns properly. When I encode a unsigned char > array using PQescapeByteaConn and send it to the server, it is not stored as > the original bytes, but rather is stored as the escaped string (much > larger). Yeah, that's clearly not the right way to do it. You could just use libpq PGExecParams for those queries. I understand that you'd want to stick to the ECPG way of doing things, but that's a good work-around. > We know the coder knows the size of the buffer, but ECPG doesn't, so the > best solution (to my mind) would be to allow the coder to tell ECPG the > buffer size directly. A clean way to do this would be to allow an indicator > variable containing the size, e.g. > > EXEC SQL BEGIN DECLARE SECTION; > unsigned char bytea_hostvar[1024]; > int hostvar_ind = 1024; > EXEC SQL END DECLARE SECTION; > > EXEC SQL AT :connection INSERT INTO Btable > (index, bytea_col) > VALUES > (:index_var, :bytea_hostvar:hostvar_ind); > > I'm just sayin... ;) Yeah, that seems like a clean way to do it. Any idea how this is done in other databases with embedded C support, like DB2 / Informix? Or SQL spec, if it has anything to say about this. It would be good to stay compatible. (I've added this to the TODO list) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com The following line is added for your protection and will be used for analysis if this message is reported as spam: (Raytheon Analysis: IP=64.18.2.219; e-from=heikki.linnakan...@enterprisedb.com; from=heikki.linnakan...@enterprisedb.com; date=Jun 23, 2009 8:09:36 AM; subject=Re: [BUGS] BUG #4866: ECPG and BYTEA)
Re: [BUGS] BUG #4873: docs: no link from dml-update to sql-update
"Brad Bowman" writes: > There seems to be an oversight in the dml-update > document. > http://www.postgresql.org/docs/8.3/interactive/dml-update.html > doesn't link to > http://www.postgresql.org/docs/8.3/interactive/sql-update.html > while both dml-insert and dml-delete do link to their > respective pages. Hmm ... I don't think there was any specific intention to have such a link, but it does seem like a reasonable thing to add. Will do. regards, tom lane -- 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 #4876: author of MD5 says it's seriously broken - hash collision resistance problems
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) 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. this has implications for storing passwords as MD5 hashes. My recommendation is to ditch MD5 and go with SHA-512. it takes up more space, but it has greater collision resistance. it requires 64 bytes storage per binary hash. I have implemented SHA-512 as GPL'd code that you may use at http://jesusnjim.com/code/sha512.html it compiles with gcc (djgpp, MinGW), and Borland C++, and probably Microsoft Visual C++. With gcc, make sure that you do not use optimization level above -O, because -O2 and -03 generate bad code and will give you incorrect results (the results will not match that of the fips pdf document). one possibility is that you could make the MD5 function actually return a SHA-512 hash. another possibility is that you could replace it with sha1. sha256 only takes up one line of space-separated hexadecimal. sha512 takes up 2 lines. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] psql: FATAL: the database system is in recovery mode
Hi All, 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 On Fedora core-4[FC49] Machine: $ rpm -qa|grep postgres postgresql-server-8.0.3-1 postgresql-libs-8.0.3-1 postgresql-odbc-08.00.0100-1 postgresql-jdbc-8.0.3-1 postgresql-docs-8.0.3-1 postgresql-tcl-8.0.3-1 postgresql-test-8.0.3-1 postgresql-devel-8.0.3-1 postgresql-8.0.3-1 gnucash-backend-postgres-1.8.11-3 freeradius-postgresql-1.0.2-2 postgresql-python-8.0.3-1 postgresql-contrib-8.0.3-1 postgresql-pl-8.0.3-1 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 psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode psql: FATAL: the database system is in recovery mode 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. Can anyone please help me in this regards. -- With Regards, Bhushan
Re: [BUGS] psql: FATAL: the database system is in recovery mode
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 -- 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: > 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
