Re: [BUGS] Possible regression: libpq + SSL aborts when user has no home directory
On Fri, Mar 4, 2011 at 00:58, Tom Lane wrote: > I wrote: >> Christian Kastner writes: >>> Using libpq 9.0.3, when an SSL connection is attempted from a client >>> whose EUID is not in a password database, the connection fails because >>> the home directory cannot be determined. With libpq 8.4.7, everything is >>> fine. > >> Hmm. Offhand I agree that that seems like an unnecessary regression. >> It should act just the same as if it could not find any of those files. >> A quick look with git blame suggests that this got broken in my >> commit 4ed4b6c54e5fab24ab2624d80e26f7546edc88ad, and I don't think >> that it was intentional. > >> One small problem is that if the sslmode is "verify-ca" or >> "verify-full", failure to find the root cert file is an error, >> and that error message normally includes the pathname at which >> the cert file was sought. What shall we print if we couldn't >> identify the home directory? > > Attached is an untested patch which I'd appreciate if you (or somebody > else who uses SSL connections more than I do) could test. I resolved > the last mentioned problem by printing "~/.postgresql/root.crt", which > is a bit of a Unix-ism but doesn't seem too unreasonable, and anyway we > weren't printing anything terribly useful before either. We could > change that message though if we wanted, since AFAICS the only way to > get there is pqGetHomeDirectory failure. So we could just print the > "could not get home directory" message instead. Thoughts? Is there any case when it would actually be realistic that we don't find the home directory, but the user can't figure out that's why it couldn't find the file? If so, the "could not get home directory" adds some more information... We can't exactly expect the end user to know that this is the only codepath that can lead to the error message... -- Magnus Hagander Me: 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 #5913: invalid page header
On 03/03/11 6:56 PM, Cristian Lazarte wrote: The following bug has been logged online: Bug reference: 5913 Logged by: Cristian Lazarte Email address: cristianlaza...@hotmail.com PostgreSQL version: 8.0.2 Operating system: WINDOWS XP Description:invalid page header Details: pg_dump problem invalid page header that isn't likely a bug in postgres. typically you get this error when one of your database files has been corrupted. but you really haven't given us much info to go on. postgres 8.0.2 is rather old, dating back to 2005, and while 8.0 was updated to 8.0.26 before being discontinued, IIRC, there was a fatal issue with 8.0 on MS Windows which was considered unrepairable, so all Windows support for 8.0 was dropped some time ago. Current versions are 8.4.7 and 9.0.3. -- 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 #5913: invalid page header
The following bug has been logged online: Bug reference: 5913 Logged by: Cristian Lazarte Email address: cristianlaza...@hotmail.com PostgreSQL version: 8.0.2 Operating system: WINDOWS XP Description:invalid page header Details: pg_dump problem invalid page header -- 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] Possible regression: libpq + SSL aborts when user has no home directory
On 03/04/2011 12:58 AM, Tom Lane wrote:
> I wrote:
>> Christian Kastner writes:
>>> Using libpq 9.0.3, when an SSL connection is attempted from a client
>>> whose EUID is not in a password database, the connection fails because
>>> the home directory cannot be determined. With libpq 8.4.7, everything is
>>> fine.
>
>> Hmm. Offhand I agree that that seems like an unnecessary regression.
>> It should act just the same as if it could not find any of those files.
>> A quick look with git blame suggests that this got broken in my
>> commit 4ed4b6c54e5fab24ab2624d80e26f7546edc88ad, and I don't think
>> that it was intentional.
>
>> One small problem is that if the sslmode is "verify-ca" or
>> "verify-full", failure to find the root cert file is an error,
>> and that error message normally includes the pathname at which
>> the cert file was sought. What shall we print if we couldn't
>> identify the home directory?
>
> Attached is an untested patch which I'd appreciate if you (or somebody
> else who uses SSL connections more than I do) could test.
I can confirm that this fixes the issue for me.
I tested this with psql and PGSSLMODE={disable,prefer,verify-ca}, with
various (or no) PGSSLROOTCERTs in the case of verify-ca. In all cases,
the result was the expected one.
> I resolved the last mentioned problem by printing
> "~/.postgresql/root.crt", which is a bit of a Unix-ism but doesn't
> seem too unreasonable, and anyway we weren't printing anything
> terribly useful before either. We could change that message though if
> we wanted, since AFAICS the only way to get there is
> pqGetHomeDirectory failure. So we could just print the "could not get
> home directory" message instead. Thoughts?
IMO your solution is fine. It clearly states that the certificate file
(at the default path) does not exist; whether this is because the file
itself or the home directory is missing appears to me as a trivial detail.
Thanks for the quick help!
Christian
--
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 #5851: ROHS (read only hot standby) needs to be restarted manually in somecases.
> -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Thursday, March 03, 2011 9:04 AM > To: mark > Cc: Fujii Masao; pgsql-bugs@postgresql.org > Subject: Re: [BUGS] BUG #5851: ROHS (read only hot standby) needs to be > restarted manually in somecases. > > On Tue, Feb 8, 2011 at 7:23 PM, mark wrote: > > (~two weeks and it dies) > > keepalives_idle=30 > > keepalives_interval=30 > > keepalives_count=30 > > Maybe something like this: > > keepalives_idle=60 > keepalives_interval=5 > keepalives_count=10 > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company Thank you ! Things have been more stable with regards to our WAN links. I am sure that won't last for very long and expect to find out sooner than later if these changes mitigate the issue I had been seeing. Again, thank you ~Mark -- 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] Possible regression: libpq + SSL aborts when user has no home directory
I wrote:
> Christian Kastner writes:
>> Using libpq 9.0.3, when an SSL connection is attempted from a client
>> whose EUID is not in a password database, the connection fails because
>> the home directory cannot be determined. With libpq 8.4.7, everything is
>> fine.
> Hmm. Offhand I agree that that seems like an unnecessary regression.
> It should act just the same as if it could not find any of those files.
> A quick look with git blame suggests that this got broken in my
> commit 4ed4b6c54e5fab24ab2624d80e26f7546edc88ad, and I don't think
> that it was intentional.
> One small problem is that if the sslmode is "verify-ca" or
> "verify-full", failure to find the root cert file is an error,
> and that error message normally includes the pathname at which
> the cert file was sought. What shall we print if we couldn't
> identify the home directory?
Attached is an untested patch which I'd appreciate if you (or somebody
else who uses SSL connections more than I do) could test. I resolved
the last mentioned problem by printing "~/.postgresql/root.crt", which
is a bit of a Unix-ism but doesn't seem too unreasonable, and anyway we
weren't printing anything terribly useful before either. We could
change that message though if we wanted, since AFAICS the only way to
get there is pqGetHomeDirectory failure. So we could just print the
"could not get home directory" message instead. Thoughts?
regards, tom lane
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 8f5ba529fcc01682e20fac5a7a189c4b76c4b2be..00dc259a4d7b097a1b20839fc990d2f977f108a2 100644
*** a/src/interfaces/libpq/fe-secure.c
--- b/src/interfaces/libpq/fe-secure.c
*** initialize_SSL(PGconn *conn)
*** 825,861
char homedir[MAXPGPATH];
char fnbuf[MAXPGPATH];
char sebuf[256];
bool have_cert;
EVP_PKEY *pkey = NULL;
/*
* We'll need the home directory if any of the relevant parameters are
! * defaulted.
*/
if (!(conn->sslcert && strlen(conn->sslcert) > 0) ||
!(conn->sslkey && strlen(conn->sslkey) > 0) ||
!(conn->sslrootcert && strlen(conn->sslrootcert) > 0) ||
!(conn->sslcrl && strlen(conn->sslcrl) > 0))
! {
! if (!pqGetHomeDirectory(homedir, sizeof(homedir)))
! {
! printfPQExpBuffer(&conn->errorMessage,
! libpq_gettext("could not get home directory to locate client certificate files\n"));
! return -1;
! }
! }
! else
! {
! homedir[0] = '\0';
! }
/* Read the client certificate file */
if (conn->sslcert && strlen(conn->sslcert) > 0)
strncpy(fnbuf, conn->sslcert, sizeof(fnbuf));
! else
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_CERT_FILE);
! if (stat(fnbuf, &buf) != 0)
{
/*
* If file is not present, just go on without a client cert; server
--- 825,861
char homedir[MAXPGPATH];
char fnbuf[MAXPGPATH];
char sebuf[256];
+ bool have_homedir;
bool have_cert;
EVP_PKEY *pkey = NULL;
/*
* We'll need the home directory if any of the relevant parameters are
! * defaulted. If pqGetHomeDirectory fails, act as though none of the
! * files could be found.
*/
if (!(conn->sslcert && strlen(conn->sslcert) > 0) ||
!(conn->sslkey && strlen(conn->sslkey) > 0) ||
!(conn->sslrootcert && strlen(conn->sslrootcert) > 0) ||
!(conn->sslcrl && strlen(conn->sslcrl) > 0))
! have_homedir = pqGetHomeDirectory(homedir, sizeof(homedir));
! else /* won't need it */
! have_homedir = false;
/* Read the client certificate file */
if (conn->sslcert && strlen(conn->sslcert) > 0)
strncpy(fnbuf, conn->sslcert, sizeof(fnbuf));
! else if (have_homedir)
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_CERT_FILE);
+ else
+ fnbuf[0] = '\0';
! if (fnbuf[0] == '\0')
! {
! /* no home directory, proceed without a client cert */
! have_cert = false;
! }
! else if (stat(fnbuf, &buf) != 0)
{
/*
* If file is not present, just go on without a client cert; server
*** initialize_SSL(PGconn *conn)
*** 1001,1011
strncpy(fnbuf, conn->sslkey, sizeof(fnbuf));
}
}
! else
{
/* No PGSSLKEY specified, load default file */
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
}
if (have_cert && fnbuf[0] != '\0')
{
--- 1001,1013
strncpy(fnbuf, conn->sslkey, sizeof(fnbuf));
}
}
! else if (have_homedir)
{
/* No PGSSLKEY specified, load default file */
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, USER_KEY_FILE);
}
+ else
+ fnbuf[0] = '\0';
if (have_cert && fnbuf[0] != '\0')
{
*** initialize_SSL(PGconn *conn)
*** 1060,1069
*/
if (conn->sslrootcert && strlen(conn->sslrootcert) > 0)
strncpy(fnbuf, conn->sslrootcert, sizeof(fnbuf));
! else
snprintf(fnbuf, sizeof(fnbuf), "%s/%s", homedir, ROOT_CERT_FILE);
! if (stat(fnbuf, &buf) == 0)
{
X509_STORE *cvstore;
-
Re: [BUGS] Mismapping of Mountain Time
Josh Berkus writes: >> It's not all that separate: per the Olsen database, >> >> Link America/Denver US/Mountain >> Link America/Denver Navajo > What's more my concern is that Ubuntu, Debian and Red Hat do not set > $TZ, so we'll get this kind of behavior on most Linux systems with a > default install of PostgreSQL. Since it's confusing to users (and will > result in other such bug reports and/or complaints), it would be nice to > do something to pick time zones which is more likely to result in > unsurprising values of Show TimeZone. [ shrug... ] The problem here is that "unsurprising" is in the eye of the beholder. Given the information available from glibc I don't think there is any portable way to tell what it thinks the true zone name is. We could twiddle the tiebreaking rule, like say just use strcmp() without any preference for shorter lengths. In this case that would give us America/Denver which is probably less surprising than Navajo to some people. But seeing that the Olsen database contains a very large and frequently changing set of timezone names, I think anything we can do here is going to be subject to the principle of conservation of astonishment. Making it better for US/Mountain is going to make it worse for somebody else --- in fact, I seem to recall that the shortest-name tiebreaking rule got there to hide some even more egregious behavior of the plain strcmp rule (cf commit 2def4552edbe1ada5aa76954997fd3142cb7c271). The displayed timezone name is cosmetic. Live with it. 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] Mismapping of Mountain Time
"Kevin Grittner" writes: > Tom Lane wrote: >> It's not all that separate: per the Olsen database, >> >> Link America/Denver US/Mountain >> Link America/Denver Navajo > Yeah, it gets complicated, since the State of Arizona ignores > Daylight Saving Time adjustments. On the other hand, most of > Arizona is covered by the Navajo Nation, which *does* observe DST. > Except for some government offices on the reservation. And the Hopi > Nation goes along with the local state rules, so pay attention. :-/ > So, yeah, Navajo is always the same as most of US/Mountain, but the > parts in Arizona don't ignore DST like the rest of the state does. Well, the Arizona rules are described by the America/Phoenix zone, which we *can* tell apart from America/Denver because there's an actual behavioral difference. If the user wanted Arizona rules and selected US/Mountain, that's their mistake not ours. 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] Mismapping of Mountain Time
> It's not all that separate: per the Olsen database, > > Link America/Denver US/Mountain > Link America/Denver Navajo > > Those are all aliases for the exact same timezone behavior, and PG > doesn't have any good way to choose which one you think is preferred. > It looks like it chooses the shortest name ... so in this case you'll > get Navajo. If you don't like that, set the timezone setting > explicitly or via the TZ environment variable for the postmaster. What's more my concern is that Ubuntu, Debian and Red Hat do not set $TZ, so we'll get this kind of behavior on most Linux systems with a default install of PostgreSQL. Since it's confusing to users (and will result in other such bug reports and/or complaints), it would be nice to do something to pick time zones which is more likely to result in unsurprising values of Show TimeZone. (This issue was reported by a customer as a bug to us) I'll give some thought as to how we could do so, and maybe add it to the TODO list. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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] Mismapping of Mountain Time
Tom Lane wrote: > Josh Berkus writes: >> There is actually a time zone "Navajo", which is a *separate* >> time zone from US/Mountain. Ideas on how this happened? > > It's not all that separate: per the Olsen database, > > Link America/Denver US/Mountain > Link America/Denver Navajo Yeah, it gets complicated, since the State of Arizona ignores Daylight Saving Time adjustments. On the other hand, most of Arizona is covered by the Navajo Nation, which *does* observe DST. Except for some government offices on the reservation. And the Hopi Nation goes along with the local state rules, so pay attention. :-/ So, yeah, Navajo is always the same as most of US/Mountain, but the parts in Arizona don't ignore DST like the rest of the state does. -Kevin -- 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] Mismapping of Mountain Time
On Thu, Mar 3, 2011 at 5:10 PM, Tom Lane wrote: > Josh Berkus writes: >> echo $TZ returns nothing. We've checked several Ubuntu systems, and it >> seems that Ubuntu does not set $TZ. > > Red Hat doesn't either; I think this is a general habit on Linux > distros. If you are using glibc, this is expected/normal. http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html -- Jon -- 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] Mismapping of Mountain Time
Josh Berkus writes: > echo $TZ returns nothing. We've checked several Ubuntu systems, and it > seems that Ubuntu does not set $TZ. Red Hat doesn't either; I think this is a general habit on Linux distros. 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] Mismapping of Mountain Time
On 3/3/11 2:31 PM, Josh Berkus wrote: > uname -a > Linux hemingway 2.6.32-25-server #44-Ubuntu SMP Fri Sep 17 21:13:39 UTC > 2010 x86_64 GNU/Linux > > date > Thu Mar 3 15:30:17 MST 2011 Also: echo $TZ returns nothing. We've checked several Ubuntu systems, and it seems that Ubuntu does not set $TZ. --Josh Berkus -- 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] Mismapping of Mountain Time
Josh Berkus writes: > ls -l localtime > lrwxrwxrwx 1 root root 31 2010-10-18 08:20 localtime -> > /usr/share/zoneinfo/US/Mountain > postgres=# select * from pg_settings where name = 'TimeZone'; > setting| Navajo > There is actually a time zone "Navajo", which is a *separate* time zone > from US/Mountain. Ideas on how this happened? It's not all that separate: per the Olsen database, LinkAmerica/Denver US/Mountain LinkAmerica/Denver Navajo Those are all aliases for the exact same timezone behavior, and PG doesn't have any good way to choose which one you think is preferred. It looks like it chooses the shortest name ... so in this case you'll get Navajo. If you don't like that, set the timezone setting explicitly or via the TZ environment variable for the postmaster. 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] Mismapping of Mountain Time
uname -a Linux hemingway 2.6.32-25-server #44-Ubuntu SMP Fri Sep 17 21:13:39 UTC 2010 x86_64 GNU/Linux date Thu Mar 3 15:30:17 MST 2011 ls -l localtime lrwxrwxrwx 1 root root 31 2010-10-18 08:20 localtime -> /usr/share/zoneinfo/US/Mountain postgres=# select * from pg_settings where name = 'TimeZone'; -[ RECORD 1 ]--- name | TimeZone setting| Navajo unit | category | Client Connection Defaults / Locale and Formatting short_desc | Sets the time zone for displaying and interpreting time stamps. extra_desc | context| user vartype| string source | command line min_val| max_val| enumvals | boot_val | UNKNOWN reset_val | Navajo sourcefile | sourceline | Version 8.4.7. There is actually a time zone "Navajo", which is a *separate* time zone from US/Mountain. Ideas on how this happened? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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] Possible regression: libpq + SSL aborts when user has no home directory
Christian Kastner writes: > Using libpq 9.0.3, when an SSL connection is attempted from a client > whose EUID is not in a password database, the connection fails because > the home directory cannot be determined. With libpq 8.4.7, everything is > fine. > I encountered this issue on my mail host, where I use virtual users. > When mail is delivered, parameters such as UID, home directory, etc. are > retrieved using multiple queries against a Postgres DB. > As soon as the virtual user's UID (which does not exist in any local > password database) is determined, exim setuid()s to it. All further > queries then fail with an error similar to this one: > PGSQL connection failed: could not get home directory to locate client > certificate files > FATAL: no pg_hba.conf entry for host "1.2.3.4", user "exim4", database > "fake_name", SSL off > Looking at interfaces/libpq/fe-secure.c, it seems that such a failure > previously only occurred when sslmode was "verify-*", otherwise the > missing home dir was ignored. Now, it always fails. Hmm. Offhand I agree that that seems like an unnecessary regression. It should act just the same as if it could not find any of those files. A quick look with git blame suggests that this got broken in my commit 4ed4b6c54e5fab24ab2624d80e26f7546edc88ad, and I don't think that it was intentional. One small problem is that if the sslmode is "verify-ca" or "verify-full", failure to find the root cert file is an error, and that error message normally includes the pathname at which the cert file was sought. What shall we print if we couldn't identify the home directory? 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] Possible regression: libpq + SSL aborts when user has no home directory
Using libpq 9.0.3, when an SSL connection is attempted from a client whose EUID is not in a password database, the connection fails because the home directory cannot be determined. With libpq 8.4.7, everything is fine. I encountered this issue on my mail host, where I use virtual users. When mail is delivered, parameters such as UID, home directory, etc. are retrieved using multiple queries against a Postgres DB. As soon as the virtual user's UID (which does not exist in any local password database) is determined, exim setuid()s to it. All further queries then fail with an error similar to this one: PGSQL connection failed: could not get home directory to locate client certificate files FATAL: no pg_hba.conf entry for host "1.2.3.4", user "exim4", database "fake_name", SSL off Looking at interfaces/libpq/fe-secure.c, it seems that such a failure previously only occurred when sslmode was "verify-*", otherwise the missing home dir was ignored. Now, it always fails. It was pointed out to me that the client-side SSL stuff changed in 9.0.3, so this might be entirely valid. I was just a little suprising. Regards, Christian -- 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 #5867: wish: plpgsql print table for debug
2011/3/3 Dimitri Fontaine : > Tom Lane writes: >> Note that doing anything more than RAISE NOTICE or equivalent would >> imply a significant protocol change. > > My understanding is that the standard allows multiple resultsets per > query, is that the protocol change you're talking about? > There is nothing similar in standard. Multirecordset is nice, but not standard feature. Regards Pavel Stehule > Regards, > -- > Dimitri Fontaine > http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- 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 #5867: wish: plpgsql print table for debug
Tom Lane writes: > Note that doing anything more than RAISE NOTICE or equivalent would > imply a significant protocol change. My understanding is that the standard allows multiple resultsets per query, is that the protocol change you're talking about? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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 #5867: wish: plpgsql print table for debug
On Thu, Mar 3, 2011 at 12:37 PM, Richard Neill wrote: > >> Sure it does. You can pass the tuple to RAISE NOTICE easily enough. >> It won't have all the same bells and whistles psql would supply, but >> it prints out well enough for debugging. Or at least it's never >> bothered me. > > Sorry if I'm being dense, but I can't see how you can pass a tuple; I think > raise-notice only lets you pass individual strings/integers. But I don't > think we can pass all of them without specifying in advance how many there > are raise notice '%', (select array_to_string(array(select foo from foo), E'\n')); :^). merlin -- 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 #5867: wish: plpgsql print table for debug
2011/3/3 Richard Neill : > >> Sure it does. You can pass the tuple to RAISE NOTICE easily enough. >> It won't have all the same bells and whistles psql would supply, but >> it prints out well enough for debugging. Or at least it's never >> bothered me. > > Sorry if I'm being dense, but I can't see how you can pass a tuple; I think > raise-notice only lets you pass individual strings/integers. But I don't > think we can pass all of them without specifying in advance how many there > are yes, it's possible for ROW or RECORD datatype Regards Pavel Stehule > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- 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 #5867: wish: plpgsql print table for debug
Note that doing anything more than RAISE NOTICE or equivalent would
imply a significant protocol change. You can't just shove a table out
to the client, because it'll think that that's the response to the outer
SELECT (or whatever) command that called your function. So while it'd
be kind of cool if you could invoke psql's table pretty-printing stuff
this way, the amount of work required to get there seems vastly out of
proportion to the benefit.
Dear Tom,
Thanks for your help. I agree that changing the protocol would be great
overhead; I'm not really suggesting that. Perhaps I should give an
example of what I mean
(1) Consider the following table, tbl_numbers:
number | english | french | german
1 one un ein
2 two deux zwei
3 threetroisdrei
(2) My desired debug function would be called this:
RAISE NOTICE_DEBUG ("SELECT * from tbl_numbers")
(3) The resulting logfile would then contain multiple separate lines,
each looking a bit like this:
NOTICE: numberenglishfrenchgerman
NOTICE: 1 oneunein
NOTICE: 2 twodeux zwei
NOTICE: 3 three trois drei
While pretty-printing would be nice, I agree it's not really important.
It would be nice to add the same space-padding to each field for
alignment, but delimiting with a single tab would be sufficient.
Richard
--
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 #5867: wish: plpgsql print table for debug
Sure it does. You can pass the tuple to RAISE NOTICE easily enough. It won't have all the same bells and whistles psql would supply, but it prints out well enough for debugging. Or at least it's never bothered me. Sorry if I'm being dense, but I can't see how you can pass a tuple; I think raise-notice only lets you pass individual strings/integers. But I don't think we can pass all of them without specifying in advance how many there are -- 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 #5867: wish: plpgsql print table for debug
Dear Pavel,
Thanks for your help.
Do you not think it would be really amazingly useful? After all, in C, the
single most useful debugging tool is "fprintf(stderr,...)", and yet
postgresql doesn't have an equivalent that can operate on the most common
data format. [I'm stretching the analogy a bit here, but it seems to me that
a multi-row table is to postgresql as int is to C.]
it's nonsense - PL/pgSQL is procedural language - so there are same -
similar types like C
Sorry - I perhaps over-stretched the analogy. What I meant was that, at
least apparently, SQL "types" include anything that can result from an
SQL statement, including an individual "record" or an entire temporary
table. I know that strictly speaking this isn't true, but it seems to me
that one should be able to do:
RAISE NOTICE (SELECT )
CREATE OR REPLACE FUNCTION debug_query(text)
RETURNS void AS $$
DECLARE r record;
BEGIN
FOR r IN EXECUTE $1 LOOP
RAISE NOTICE r;
END;
END;
$$ LANGUAGE plpgsql;
Thanks for your help - but I'm afraid this doesn't actually work. psql
rejects the line "RAISE NOTICE r;"
Raise notice expects a format string and some variables, very similar to
printf(). This means that we'd have to write something like:
RAISE NOTICE ('first %, second %, third %', col1, col2, col3;
except that our debug_query function doesn't know in advance how many
columns there are, (or the types and their names).
Richard
--
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 #5867: wish: plpgsql print table for debug
On Thu, Mar 3, 2011 at 1:37 PM, Richard Neill wrote:
>
>> Sure it does. You can pass the tuple to RAISE NOTICE easily enough.
>> It won't have all the same bells and whistles psql would supply, but
>> it prints out well enough for debugging. Or at least it's never
>> bothered me.
>
> Sorry if I'm being dense, but I can't see how you can pass a tuple; I think
> raise-notice only lets you pass individual strings/integers. But I don't
> think we can pass all of them without specifying in advance how many there
> are
Pavel had it almost right. Here's a version that works for me.
CREATE FUNCTION debug_query(qry text) RETURNS void
LANGUAGE plpgsql
AS $$
declare
r record;
begin
for r in execute qry loop
raise notice '%', r;
end loop;
end
$$;
And here it is doing its thing:
rhaas=# select debug_query('SELECT * FROM foo');
NOTICE: (1,Richard)
NOTICE: (2,Robert)
NOTICE: (3,Tom)
debug_query
-
(1 row)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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 #5867: wish: plpgsql print table for debug
Robert Haas writes: > On Thu, Mar 3, 2011 at 12:12 PM, Richard Neill wrote: >> Do you not think it would be really amazingly useful? After all, in C, the >> single most useful debugging tool is "fprintf(stderr,...)", and yet >> postgresql doesn't have an equivalent that can operate on the most common >> data format. [I'm stretching the analogy a bit here, but it seems to me that >> a multi-row table is to postgresql as int is to C.] > Sure it does. You can pass the tuple to RAISE NOTICE easily enough. > It won't have all the same bells and whistles psql would supply, but > it prints out well enough for debugging. Or at least it's never > bothered me. Note that doing anything more than RAISE NOTICE or equivalent would imply a significant protocol change. You can't just shove a table out to the client, because it'll think that that's the response to the outer SELECT (or whatever) command that called your function. So while it'd be kind of cool if you could invoke psql's table pretty-printing stuff this way, the amount of work required to get there seems vastly out of proportion to the benefit. 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 #5903: Turkish encoding problem
On Tue, Mar 1, 2011 at 1:59 AM, Sarp Akal wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5903
> Logged by: Sarp Akal
> Email address: s...@dms-tech.com
> PostgreSQL version: 9.0.2
> Operating system: Windows Server 2008 R2 x64
> Description: Turkish encoding problem
> Details:
>
> The server is setup for UTF8 encoding and collation and character type are
> Turkish_Turkey.1254
>
> The following code fails:
>
> select lower('İ') --> Lowercase of turkish capital I-with dot returns
> exactly the same character.
>
> select upper('ı') --> Uppercase of turkish small i-without dot returns
> exactly the same character.
>
> select lower('I') --> Lowercase of turkish capital I returns i where it
> should be i-without dot.
>
> select upper('i') --> Uppercase of turkish small returns I where it should
> be I-with dot.
I might be wrong about this, but I think this behavior is determined
by the operating system behavior of the locale you've selected, and we
just believe whatever the OS says.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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 #5869: postgresql corrupts unquoted non-ascii chars in column aliases
On 03.03.2011 16:08, Robert Haas wrote: On Tue, Feb 8, 2011 at 2:19 AM, David Schmitt wrote: Example query: SELECT column as zurück FROM table; results in corruption of the "ü" (umlaut u). This causes Npgsql to fail to match up the columns in the result set (see http://pgfoundry.org/tracker/?func=detail&aid=1010988&group_id=1000140&atid= 590) and pgadminIII doesn't display the alias in the result pane. That link doesn't show anything interesting when I look at it. What exactly do you mean by corrupted? There are some garbage bytes instead of the umlaut. The same query works with the same tools against a 8.4.5 running on Debian squeeze. If the alias is quoted like this: SELECT column as "zurück" FROM table; the query also works against the DB running on windows. PS: I tried downloading the newest version of the one click installer for windows from EnterpriseDB, and noticed that since recently that site requires a registration :-( I think this has been fixed. Please let me know if not. I presume there is a new 8.4.5 version at enterprisedb.com ? I'll have a look at it later. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- 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 #5867: wish: plpgsql print table for debug
On Thu, Mar 3, 2011 at 12:12 PM, Richard Neill wrote: > Do you not think it would be really amazingly useful? After all, in C, the > single most useful debugging tool is "fprintf(stderr,...)", and yet > postgresql doesn't have an equivalent that can operate on the most common > data format. [I'm stretching the analogy a bit here, but it seems to me that > a multi-row table is to postgresql as int is to C.] Sure it does. You can pass the tuple to RAISE NOTICE easily enough. It won't have all the same bells and whistles psql would supply, but it prints out well enough for debugging. Or at least it's never bothered me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5906: assertion failure in AtCleanup_Portals
I wrote: > We could revert the addition of the "cleanup == NULL" assert in > AtCleanup_Portals, but I'm still feeling that that assertion is a good > thing. Maybe the cleanest fix is to have PortalRun do something to run > the cleanup hook where it does this: > /* Prevent portal's commands from being re-executed */ > portal->status = PORTAL_DONE; Fixed that way. Thanks for the report! 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 #5867: wish: plpgsql print table for debug
Hello > > Do you not think it would be really amazingly useful? After all, in C, the > single most useful debugging tool is "fprintf(stderr,...)", and yet > postgresql doesn't have an equivalent that can operate on the most common > data format. [I'm stretching the analogy a bit here, but it seems to me that > a multi-row table is to postgresql as int is to C.] it's nonsense - PL/pgSQL is procedural language - so there are same - similar types like C > > There are a lot of people who would benefit from it, most of whom (including > me) don't really have the expertise to do it well. > I don't think so we need a special enhancing of RAISE statement. What is a problem on lines FOR r IN SELECT ... LOOP RAISE NOTICE r; END LOOP; ??? > Also, there is a lot of value in being able to debug as needed with a 1-line > debugging statement, then get back to the problem at hand, rather than > having to break out of the current programming task to write a debug > function :-) > CREATE OR REPLACE FUNCTION debug_query(text) RETURNS void AS $$ DECLARE r record; BEGIN FOR r IN EXECUTE $1 LOOP RAISE NOTICE r; END; END; $$ LANGUAGE plpgsql; Regards Pavel Stehule > Thanks very much, > > Richard > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- 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 #5912: Etc/GMT time utc offset error
"Ross Williams" writes: > On the target OS the offsets are correct GMT+ gives a increased utc_offset. > When I attempt to set via postgres, the timezone are flipped + for - and > vice versa. The problem is that there are conflicting standards for the sign of UTC offsets. The conventions Postgres has chosen are not 100% consistent, but neither is the real world. There's some discussion in this section of the manual: http://www.postgresql.org/docs/8.4/static/datatype-datetime.html#DATATYPE-TIMEZONES in particular this bit: Another issue to keep in mind is that in POSIX time zone names, positive offsets are used for locations west of Greenwich. Everywhere else, PostgreSQL follows the ISO-8601 convention that positive timezone offsets are east of Greenwich. 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 #5867: wish: plpgsql print table for debug
The following bug has been logged online: Bug reference: 5867 Logged by: Richard Neill Email address: postgre...@richardneill.org PostgreSQL version: 9.03 Operating system: Linux Description:wish: plpgsql print table for debug Details: When debugging a plpgsql function, it would be really amazingly useful to be able to do a regular psql-style SELECT, and have the result printed to screen. Something like: Raise Notice table 'SELECT ' and then plpgsql would run the query and dump the result to screen, using its helpful formatting. As far as I can see, this isn't possible (though there are a lot of people searching for how to do it), and the only workaround is to manually handle the looping and formatting, raising lots of individual notices. This makes debugging much harder than it should be. It wouldn't be too hard to write a loop that runs the select statement and does RAISE NOTICE on each row. Getting that into the psql formatting would be a little trickier, but I don't see why you couldn't write a PL/pgsql function to do it. Then you could just call that function and pass it an SQL query every time you want to do this. I'm rather hoping that this would actually be an enhancement to PL/PGSQL, (or at least an officially documented howto) rather than just a private debugging function. Do you not think it would be really amazingly useful? After all, in C, the single most useful debugging tool is "fprintf(stderr,...)", and yet postgresql doesn't have an equivalent that can operate on the most common data format. [I'm stretching the analogy a bit here, but it seems to me that a multi-row table is to postgresql as int is to C.] There are a lot of people who would benefit from it, most of whom (including me) don't really have the expertise to do it well. Also, there is a lot of value in being able to debug as needed with a 1-line debugging statement, then get back to the problem at hand, rather than having to break out of the current programming task to write a debug function :-) Thanks very much, Richard -- 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] can't build contrib/uuid-ossp
Robert Haas writes: > On Thu, Mar 3, 2011 at 11:16 AM, Jeff Hamann wrote: >> I've attached the config.log file. > It looks like the trouble is here: > In file included from conftest.c:92: > /usr/local/include/uuid.h:94: error: conflicting types for 'uuid_t' > /usr/include/unistd.h:133: error: previous declaration of 'uuid_t' was here > So the problem is, apparently, that Darwin defines its own version of > uuid_t that clashes with the one provided by uuid-ossp. There are > some #ifdefs around that bit of stuff on my machine, so it might be > possible to #define your way out of the problem. > If you figure out how to get it working, I think we'd be happy to > accept a patch that fixes it, unless it's only failing due to some > funky detail of your configuration, which I suspect isn't the case > based on a quick look at my system. On my Mac with uuid-ossp 1.6.2 installed in /usr/local, configure whines as shown above but the build goes through just fine, which probably is because uuid-ossp.c doesn't try to include . So the conflict noted by configure doesn't really affect us AFAICS. I would say that if there's anything to be done about it, it's the uuid-ossp folks' problem to solve not ours. 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 #5869: postgresql corrupts unquoted non-ascii chars in column aliases
On Thu, Mar 3, 2011 at 11:51 AM, David Schmitt wrote: > On 03.03.2011 16:08, Robert Haas wrote: >> >> On Tue, Feb 8, 2011 at 2:19 AM, David Schmitt wrote: >>> >>> Example query: >>> >>> SELECT column as zurück FROM table; >>> >>> results in corruption of the "ü" (umlaut u). This causes Npgsql to fail >>> to >>> match up the columns in the result set (see >>> >>> http://pgfoundry.org/tracker/?func=detail&aid=1010988&group_id=1000140&atid= >>> 590) and pgadminIII doesn't display the alias in the result pane. >> >> That link doesn't show anything interesting when I look at it. What >> exactly do you mean by corrupted? > > There are some garbage bytes instead of the umlaut. I'm not really an encoding guy, but I would think that someone who is would want to know exactly what bytes you were ending up with. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Corrupted index on 9.0.3 streaming hot standby
On Thu, Mar 3, 2011 at 11:39 AM, Jakub Ouhrabka wrote: > Hi Robert, > >> If there hasn't been a system crash on the standby, then it's harder >> to explain. It'd be interesting to compare the disk blocks in the >> index on the standby with the disk blocks in the index on the master >> and figure out which ones are different and in what way. pg_filedump >> might be useful. > > I think this is the case. We can even reproduce it: take another backup of > uncorrupted master and the slave is again corrupted. Well, in that case, I'd *really* like to see you compare the two files. Maybe you could reproduce the problem, ideally stop both servers (or at least CHECKPOINT), and then for each block in the affected index run: pg_filedump -i -R $BLOCKNUMBER $FILE > b.$BLOCKNUMBER ...on the master and on the standby. Then diff the master version of each file with the standby version and see what pops out. > The strange thing is that this only affects streaming replication standby, > not wal files shipping standby. Maybe we're doing something wrong... Maybe, but I can't think what would cause this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5899: Memory corruption when running psql
On Thu, Mar 3, 2011 at 11:14 AM, Ross Barrett wrote: > I determined that this issue was caused by something (a large error message > relating to failed delete caused by an integrity issue) which I erroneously > pasted into the psql terminal. I was able to get around the problem by > deleting my .pg_history file. > > Perhaps it is more accurate that this is a problem with termcap? More likely libedit, which FWICT seems to be riddled with bugs. :-( -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5863: help message report 5433 as default port
On Thu, Mar 3, 2011 at 11:38 AM, Dave Page wrote: > On Thu, Mar 3, 2011 at 8:30 PM, Robert Haas wrote: >> On Wed, Feb 2, 2011 at 4:06 PM, R. Engmann wrote: >>> >>> The following bug has been logged online: >>> >>> Bug reference: 5863 >>> Logged by: R. Engmann >>> Email address: rengm...@web.de >>> PostgreSQL version: 9.0.3 >>> Operating system: Windows 32bit >>> Description: help message report 5433 as default port >>> Details: >>> >>> running postgresql-9.0.3-1-windows.exe --help >>> tells the default port for postgres is 5433 >>> (supposed to be 5432). >> >> I can reproduce this. It appears to be an installer bug. Dave? > > Not a bug. The default port will be 5433 if there's something already > running on 5432. Oh, gosh. That's not at all clear from the message you get. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5911: pg_notify() function only works when channel name is lower case
Thank you both for clearing that up (and doing so quite quickly!).
The behavior makes complete sense now that I understand what is
happening here behind the scenes.
Regards,
Josh
On 3/3/2011 11:24 AM, Tom Lane wrote:
"Joshua McDougall" writes:
When using the pg_notify(text,text) function, the channel name MUST be lower
case otherwise the message does not go through.
It's not clear to me that this is a bug. The argument of NOTIFY is a
SQL identifier, which is folded to lower case by the lexer if not
double-quoted, but the argument of pg_notify is a string constant which
is a different matter altogether.
We could have pg_notify lowercase its argument at runtime, but then
we'd have to introduce quoting rules, so that you could do
select pg_notify('"IntentionallyMixedCase"', '...');
This isn't a lot clearer than the current behavior, and it definitely
wouldn't be backwards compatible. So I'm inclined to leave it alone.
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] Corrupted index on 9.0.3 streaming hot standby
Hi Robert, > If there hasn't been a system crash on the standby, then it's harder > to explain. It'd be interesting to compare the disk blocks in the > index on the standby with the disk blocks in the index on the master > and figure out which ones are different and in what way. pg_filedump > might be useful. I think this is the case. We can even reproduce it: take another backup of uncorrupted master and the slave is again corrupted. The strange thing is that this only affects streaming replication standby, not wal files shipping standby. Maybe we're doing something wrong... Could the reason for the strange behaviour (see previous mail) be something different than corrupted index? We'll try to reproduce it in testing environment and possibly create reproducible test case. I'll definitely report back... Regards, Kuba -- 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 #5899: Memory corruption when running psql
I determined that this issue was caused by something (a large error message relating to failed delete caused by an integrity issue) which I erroneously pasted into the psql terminal. I was able to get around the problem by deleting my .pg_history file. Perhaps it is more accurate that this is a problem with termcap? -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-5899-Memory-corruption-when-running-psql-tp3398967p3408178.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.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 #5912: Etc/GMT time utc offset error
The following bug has been logged online: Bug reference: 5912 Logged by: Ross Williams Email address: ross.willi...@watchguard.com PostgreSQL version: 8.3.1 and 8.4.7 Operating system: FreeBSD 7.3 and Ubuntu 10 Description:Etc/GMT time utc offset error Details: On the target OS the offsets are correct GMT+ gives a increased utc_offset. When I attempt to set via postgres, the timezone are flipped + for - and vice versa. http://wwp.greenwichmeantime.com/info/timezone.htm Gives a clear indication that there is an error in the utc_offset below. name | abbrev | utc_offset | is_dst Etc/GMT-14| GMT-14 | 14:00:00 | f Etc/GMT-13| GMT-13 | 13:00:00 | f Etc/GMT-12| GMT-12 | 12:00:00 | f Etc/GMT-11| GMT-11 | 11:00:00 | f Etc/GMT-10| GMT-10 | 10:00:00 | f Etc/GMT-9 | GMT-9 | 09:00:00 | f Etc/GMT-8 | GMT-8 | 08:00:00 | f Etc/GMT-7 | GMT-7 | 07:00:00 | f Etc/GMT-6 | GMT-6 | 06:00:00 | f Etc/GMT-5 | GMT-5 | 05:00:00 | f Etc/GMT-4 | GMT-4 | 04:00:00 | f Etc/GMT-3 | GMT-3 | 03:00:00 | f Etc/GMT-2 | GMT-2 | 02:00:00 | f Etc/GMT-1 | GMT-1 | 01:00:00 | f Etc/GMT+1 | GMT+1 | -01:00:00 | f Etc/GMT+2 | GMT+2 | -02:00:00 | f Etc/GMT+3 | GMT+3 | -03:00:00 | f Etc/GMT+4 | GMT+4 | -04:00:00 | f Etc/GMT+5 | GMT+5 | -05:00:00 | f Etc/GMT+6 | GMT+6 | -06:00:00 | f Etc/GMT+7 | GMT+7 | -07:00:00 | f Etc/GMT+8 | GMT+8 | -08:00:00 | f Etc/GMT+9 | GMT+9 | -09:00:00 | f Etc/GMT+10| GMT+10 | -10:00:00 | f Etc/GMT+11| GMT+11 | -11:00:00 | f Etc/GMT+12| GMT+12 | -12:00:00 | f -- 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 #5906: assertion failure in AtCleanup_Portals
Itagaki Takahiro writes: > On Thu, Mar 3, 2011 at 09:14, YAMAMOTO Takashi wrote: >> here's a small test case. > I was able to reproduce the assertion failure. > It looks we call CreatePortal for ROLLBACK, but don't invoke > DropPortal nor AtAbort_Portals before AtCleanup_Portals. Hmm. The reason why not is that xact.c is already in TBLOCK_ABORT_END state, ie, it knows it already did AbortTransaction and doesn't see a need to do it again. So the portal running ROLLBACK doesn't get cleaned up by AtAbort_Portals. We could revert the addition of the "cleanup == NULL" assert in AtCleanup_Portals, but I'm still feeling that that assertion is a good thing. Maybe the cleanest fix is to have PortalRun do something to run the cleanup hook where it does this: /* Prevent portal's commands from being re-executed */ portal->status = PORTAL_DONE; That should be a safe-enough place to run cleanup. 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 #5863: help message report 5433 as default port
On Thu, Mar 3, 2011 at 8:30 PM, Robert Haas wrote: > On Wed, Feb 2, 2011 at 4:06 PM, R. Engmann wrote: >> >> The following bug has been logged online: >> >> Bug reference: 5863 >> Logged by: R. Engmann >> Email address: rengm...@web.de >> PostgreSQL version: 9.0.3 >> Operating system: Windows 32bit >> Description: help message report 5433 as default port >> Details: >> >> running postgresql-9.0.3-1-windows.exe --help >> tells the default port for postgres is 5433 >> (supposed to be 5432). > > I can reproduce this. It appears to be an installer bug. Dave? Not a bug. The default port will be 5433 if there's something already running on 5432. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5865: Problem regarding Postgresql installation and ODBC driver installation in 64 bit Windows Vista OS
On Fri, Feb 4, 2011 at 10:07 AM, Amruta Buch wrote: > > The following bug has been logged online: > > Bug reference: 5865 > Logged by: Amruta Buch > Email address: ayb...@gmail.com > PostgreSQL version: Version 9.0.3-1 > Operating system: Windows Vista > Description: Problem regarding Postgresql installation and ODBC > driver installation in 64 bit Windows Vista OS > Details: > > I am unable to install Postgresql "Installer version Version 9.0.3-1 > winx86-64" on my HP 64 bit laptop dv6000 series having Windows Vista OS. Can you confirm the download isn't corrupted? Try downloading again, and then running from the command line with --help. You should see some help options. > But here inspite of showing > successful message of ODBC driver installation, when I try to generate a new > SYSTEM DSN for ODBC connection, it never shows me an option of postgresql > ODBC driver. Are you running the 32bit ODBC driver manager? We don't yet ship a 64bit driver, so nothing will show up in the 64bit DM. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] can't build contrib/uuid-ossp
On Thu, Mar 3, 2011 at 11:16 AM, Jeff Hamann wrote: > I've attached the config.log file. It looks like the trouble is here: In file included from conftest.c:92: /usr/local/include/uuid.h:94: error: conflicting types for 'uuid_t' /usr/include/unistd.h:133: error: previous declaration of 'uuid_t' was here So the problem is, apparently, that Darwin defines its own version of uuid_t that clashes with the one provided by uuid-ossp. There are some #ifdefs around that bit of stuff on my machine, so it might be possible to #define your way out of the problem. If you figure out how to get it working, I think we'd be happy to accept a patch that fixes it, unless it's only failing due to some funky detail of your configuration, which I suspect isn't the case based on a quick look at my system. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5911: pg_notify() function only works when channel name is lower case
"Joshua McDougall" writes:
> When using the pg_notify(text,text) function, the channel name MUST be lower
> case otherwise the message does not go through.
It's not clear to me that this is a bug. The argument of NOTIFY is a
SQL identifier, which is folded to lower case by the lexer if not
double-quoted, but the argument of pg_notify is a string constant which
is a different matter altogether.
We could have pg_notify lowercase its argument at runtime, but then
we'd have to introduce quoting rules, so that you could do
select pg_notify('"IntentionallyMixedCase"', '...');
This isn't a lot clearer than the current behavior, and it definitely
wouldn't be backwards compatible. So I'm inclined to leave it alone.
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 #5911: pg_notify() function only works when channel name is lower case
On Thu, Mar 3, 2011 at 9:20 AM, Joshua McDougall wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5911
> Logged by: Joshua McDougall
> Email address: j...@schemaverse.com
> PostgreSQL version: 9.0.3
> Operating system: Slackware Linux Kernel 2.6.28.6
> Description: pg_notify() function only works when channel name is
> lower case
> Details:
>
> When using the pg_notify(text,text) function, the channel name MUST be lower
> case otherwise the message does not go through.
>
> So, while this will work:
>
> LISTEN ERRORCHANNEL;
> NOTIFY ERRORCHANNEL, 'something!';
> NOTIFY eRrorChanNel, 'something!';
>
> this will not:
> SELECT pg_notify('ERRORCHANNEL','something!');
>
> You must use:
> SELECT pg_notify('errorchannel','something!');
not a bug. you have to double quote relnames (listen "Test"). if you
want the server not to case fold them. pg_notify takes a string, not a
relname, which uses different rules.
merlin
--
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] Problem with ALTER TABLE - occasional "tuple concurrently updated"
On Thu, Nov 18, 2010 at 1:35 PM, Alvaro Herrera wrote: > Excerpts from Alvaro Herrera's message of jue nov 18 15:31:16 -0300 2010: >> Excerpts from Robert Haas's message of jue nov 18 15:11:37 -0300 2010: >> >> > In the current master branch, it appears that "ALTER TABLE c INHERIT >> > p" takes a ShareUpdateExclusiveLock on the child, which seems >> > sufficient, and an AccessShareLock on the parent, which seems like it >> > might not be; though I'm having a hard time figuring out exactly when >> > it wouldn't be, especially since in 8.4 I'm fairly sure any ALTER >> > TABLE command takes an AccessExclusiveLock. >> >> What if two of these run at the same time, and the parent doesn't >> have children when they start? They would both try to set >> relhassubclass, no? > > Yep, duplicated the issue that way. I think ATExecAddInherit() and MergeAttributes() need to take ShareUpdateExclusiveLock instead of AccessShareLock to prevent this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5818: initdb lose the single quote of locale
On Fri, Jan 7, 2011 at 1:42 AM, yulei wrote: > > The following bug has been logged online: > > Bug reference: 5818 > Logged by: yulei > Email address: yu...@hotmail.com > PostgreSQL version: 9.0.2 > Operating system: Windows XP Service Pack 3 > Description: initdb lose the single quote of locale > Details: > > Hi,dear developers! > I am using a chinses window xp os. > i run "initdb -E UTF-8 -D temp" in cmd,it can get the > locale:"Chinese_People's Republic of China.936"。 > > but when initdb creating template1 , it lose the single quote of locale,it > use "Chinese_Peoples Republic of China.936"(notice that , it lose the ' > after "Chinese_People" ) for the "template1" record's > “datcollate”,“datctype” Column in tablepg_database。 > > though "creating template1 database" is ok,but the initdb's next step > "initializing pg_authid ..." failed. > bucause the invalid locale "Chinese_People's Republic of China.936" is used > to run the command "REVOKE ALL on pg_authid FROM public;"。 > > and the cmd resule is : > creating template1 database in temp/base/1 ... ok > initializing pg_authid ... : ݿʹõԻͲϵͳIJ > ϸϢ: ݿ⼯Ⱥ LC_COLLATE "Chinese_Peoples Re > ʾ: һԻ´ݿ⣬߰װʧԻ. > child process exited with exit code 1 > initdb: removing data directory "temp"。 > > to support what i say , i test like: > add " > create pg_database_test 5158 ( datname = name ) > open pg_database_test > insert OID = 1 ( "Chinese_People's Republic of China.936") > close pg_database_test > " > to postgreSQLHOME/share/postgres.bki > > run cmd "initdb -E UTF-8 -D temp --local=chs" > > it can init successful,then i start the server,run sql: > "SELECT * from pg_database_test" ,the result show "Chinese_Peoples Republic > of China.936". > yes ,the single quote of test string "Chinese_People's Republic of > China.936" lose. > > can you fix it ? I don't see any responses to this bug. Do we have a quoting problem somewhere? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5827: no consigo instalarlo
On Mon, Jan 10, 2011 at 6:19 PM, jon varona wrote: > > The following bug has been logged online: > > Bug reference: 5827 > Logged by: jon varona > Email address: jonvar...@hotmail.com > PostgreSQL version: 9.0.2-1 > Operating system: windows 7 > Description: no consigo instalarlo > Details: > > no puedo instalar el programa me pide una contraseña que desconozco, lo > cual quire decir que hay usuario, ese usuario no puedo eliminarlo necesito > una solucion gracias This is an English-language mailing list. You might want to try here: http://archives.postgresql.org/pgsql-es-ayuda/ It'd also probably be helpful to provide more details about the problelm. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5911: pg_notify() function only works when channel name is lower case
The following bug has been logged online:
Bug reference: 5911
Logged by: Joshua McDougall
Email address: j...@schemaverse.com
PostgreSQL version: 9.0.3
Operating system: Slackware Linux Kernel 2.6.28.6
Description:pg_notify() function only works when channel name is
lower case
Details:
When using the pg_notify(text,text) function, the channel name MUST be lower
case otherwise the message does not go through.
So, while this will work:
LISTEN ERRORCHANNEL;
NOTIFY ERRORCHANNEL, 'something!';
NOTIFY eRrorChanNel, 'something!';
this will not:
SELECT pg_notify('ERRORCHANNEL','something!');
You must use:
SELECT pg_notify('errorchannel','something!');
--
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 #5909: Function pg_get_expr throwing error for non superuser
The following bug has been logged online:
Bug reference: 5909
Logged by: tushar
Email address: tushar...@gmail.com
PostgreSQL version: 9.0.2
Operating system: RHEL-5 32 bit
Description:Function pg_get_expr throwing error for non superuser
Details:
Pls refer this below scenario
PG 8.4.4:-
=
connect to non superuser :-
postgres=# \c - t
psql (8.4.4)
You are now connected to database "postgres" as user "t".
postgres=> select pg_get_expr('a',null);
pg_get_expr
-
(1 row)
postgres=>
PG 9.0.2
=
connect to non superuser :-
postgres=# \c - t
You are now connected to database "postgres" as user "t".
postgres=> select pg_get_expr('a',null);
ERROR: argument to pg_get_expr() must come from system catalogs
postgres=>
Workaround:- if user is superuser then it is working fine..
I found a thread somewhat related to this above issue :-
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00503.php
which look fixed now in PG 9.0.2
e.g:-
postgres=> SELECT pg_get_expr(proargdefaults,
'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid limit 0;
pg_get_expr
-
(0 rows)
postgres=>
so i feel this query :-select pg_get_expr('a',null);
should also work in PG 9.0.2 but it is not working. is this an expected
behavior
--
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 #5843: documentation error
On Wed, Jan 19, 2011 at 12:47 PM, Andreas Kretschmer wrote: > > The following bug has been logged online: > > Bug reference: 5843 > Logged by: Andreas Kretschmer > Email address: akretsch...@spamfence.net > PostgreSQL version: 9.1 > Operating system: all > Description: documentation error > Details: > > the doku contains a bug: > > http://developer.postgresql.org/pgdocs/postgres/catalog-pg-class.html > > column relpersistence, wrong datatype. it's not a BOOL, it's a CHAR afaik. Sorry for the slow response. It looks like Thom Brown also noticed this, and it's fixed now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5908: PgOleDb 1.0.0.20 returns values without the digits after the dot.
On Wed, Mar 2, 2011 at 4:49 PM, Aldo Ribeiro wrote: > > The following bug has been logged online: > > Bug reference: 5908 > Logged by: Aldo Ribeiro > Email address: aldo...@gmail.com > PostgreSQL version: 9.0.3 > Operating system: Windows XP SP3 > Description: PgOleDb 1.0.0.20 returns values without the digits after > the dot. > Details: > > I'm using PostgreSQL 9.0.3 in VB6 with PgOleDb 1.0.0.20. I have a field of > type Numeric (8.2), but always returns values without the digits after the > dot. Using ODBC works. Please correct the PgOleDb and release a new > version. This list is only for bugs in core PostgreSQL, not PgOleDb. Also, this sounds like it's more likely to be a configuration problem than a bug. You'll need to contact whoever is responsible for PgOleDb, or peruse the appropriate documentation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5851: ROHS (read only hot standby) needs to be restarted manually in somecases.
On Tue, Feb 8, 2011 at 7:23 PM, mark wrote: > (~two weeks and it dies) > keepalives_idle=30 > keepalives_interval=30 > keepalives_count=30 Maybe something like this: keepalives_idle=60 keepalives_interval=5 keepalives_count=10 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5887: EXPLAIN returns more than 1000 rows when table is empty
On Tue, Feb 15, 2011 at 3:59 PM, warst...@list.ru wrote: > Understood. Can you show me where it is written in the documentation? > (I just want to know is, whether it is in the documentation and if not, > probably should add this case) This is a pretty frequently asked question, so it might be worth documenting. But I'm not sure exactly where in the documentation it should go. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5897: INSTALACAO
On Tue, Feb 22, 2011 at 8:17 AM, Nilson wrote: > > The following bug has been logged online: > > Bug reference: 5897 > Logged by: Nilson > Email address: laut...@uol.com.br > PostgreSQL version: 9.0 > Operating system: Windows XP > Description: INSTALACAO > Details: > > Srs. > > Não estou conseguinda instalar o postgres na minha maquina. > Chego até na tela que solicita a senha, ai recebo a mensagem que a senha é > invalida. > > Nota. Tinha instalado a versao 8.4, desinstalei e agora nao consigo instalar > a outra versao. > > Windows XP This is an English mailing list. You might try here: https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5899: Memory corruption when running psql
On Thu, Feb 24, 2011 at 11:36 AM, Ross Barrett wrote: > > The following bug has been logged online: > > Bug reference: 5899 > Logged by: Ross Barrett > Email address: ross_barr...@rapid7.com > PostgreSQL version: 9.0.3 > Operating system: Ubuntu 9.10 > Description: Memory corruption when running psql > Details: > > Attempting to run psql complains that termcap db is not present (bug 5807). > Applying the work around of placing an /etc/termcap file from a Red Hat > system allowed psql to run 1x. Subsequent runs always yield a memory > error: How did you install PostgreSQL? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5707: Cross compilation for windows is broken
On Sat, Feb 26, 2011 at 2:14 AM, Bruce Momjian wrote: > Has this been addressed? Not me. Sounds like no one cares enough to figure out how to do this. Perhaps this should be a TODO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5907: ODBC % bug
On Wed, Mar 2, 2011 at 3:06 PM, Andrew Considine wrote: > > The following bug has been logged online: > > Bug reference: 5907 > Logged by: Andrew Considine > Email address: andrew.consid...@sncorp.com > PostgreSQL version: 9.0.1-1 > Operating system: Windows XP > Description: ODBC % bug > Details: > > Using a password that contains a "%" symbol does not authenticate while > using the ODBC driver. The Postgresql installer accepts this password. The > password will even work while logging into PGAdmin. However when connecting > through the ODBC driver from one of our C++ applications we receive the > following error: FATAL: password authentication failed for user > "". We tested this behaviour with the "%" symbol in various > positions of the password with the same result. Also, we tested this with > "^" which worked as it should and "&" which also worked as it should. It > was only the usage of the "%" that failed to work properly while > authenticatin via the ODBC driver. You may want to try this question on the ODBC list, if you don't get a response here. http://archives.postgresql.org/pgsql-odbc/ -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Corrupted index on 9.0.3 streaming hot standby
2011/2/25 Jakub Ouhrabka : > Hi, > > we've found that we have corrupted index on 9.0.3 streaming hot standby. > Master works ok. There is one more non-streaming standby which is ok as > well. Platform is 64bit Linux. > > Database cluster and this database were created on 9.0.2 and than upgraded > to 9.0.3. We are not aware of any crash on either master or streaming > standby but we didn't investigate it deeply yet. > > For details about corrupted index see below. The table and index in question > are mostly read-only (several queries per second) writes happen only few > times a day. > > We've backed up whole cluster and recreated it. > > Shall we investigate it further? How? Is it possible that we make some > mistake when doing initial backup which caused corruption? Is there a way to > check other indexes? The obvious way this could happen is if there were a system crash on the standby. In theory that should be OK too, but if fsync isn't working properly due to a settings or disk controller configuration problem or similar, then it might not be. See also http://wiki.postgresql.org/wiki/Reliable_Writes If there hasn't been a system crash on the standby, then it's harder to explain. It'd be interesting to compare the disk blocks in the index on the standby with the disk blocks in the index on the master and figure out which ones are different and in what way. pg_filedump might be useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5895: Ability to match more than just CN in client certificate
On Sun, Feb 20, 2011 at 5:30 PM, Christopher Head wrote: > > The following bug has been logged online: > > Bug reference: 5895 > Logged by: Christopher Head > Email address: chris2...@hotmail.com > PostgreSQL version: 9.0.3 > Operating system: Linux amd64 > Description: Ability to match more than just CN in client certificate > Details: > > This is a feature request/wishlist, not a bug. Right now, when using client > certificates over SSL for authentication, the username map maps from the > Subject Common Name field in the certificate to a username in the database. > It would be nice if matches could be done on a few other fields in the > certificate. For example, my name is not particularly unusual, so it's > reasonable that someone else in the world might (and probably does) have the > same name. That doesn't mean I want to give that person access to my > database, even if they also get a certificate from e.g. cacert.org! > > A few fields to match on that would pretty much instantly close this hole > would be e-mail address and certificate serial number. While the e-mail > address suggestion could be generalized to match an arbitrary subset of the > subject's distinguished name fields (e.g. write something like > /O=FooOrg/CN=Christopher Head/ to require that both fields must be present > with the specified values), matching certificate serial number would be > slightly different as the serial number is not part of the distinguished > name. It would probably be the most secure field to match on, however, as no > CA will ever issue two certificates with the same serial number. E-mail > address would be a close second as an address can only be held by one > person, though it relies on the CA being able to verify the legitimate owner > of the address. It seems like there are a lot of possible combinations here that could be useful, so we'd want something that allowed a fairly flexible specification of what to match. Is this a problem you're interested in working on (i.e. contributing code)? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5874: pg_dumpall CREATE DATABASE statements 'missing' parameters
On Wed, Feb 9, 2011 at 4:57 AM, Jan-Peter Seifert wrote: > > The following bug has been logged online: > > Bug reference: 5874 > Logged by: Jan-Peter Seifert > Email address: jan-peter.seif...@gmx.de > PostgreSQL version: 8.4.7 > Operating system: Windows 7 64-Bit > Description: pg_dumpall CREATE DATABASE statements 'missing' > parameters > Details: > > Hello, > > it's not really a bug ... but CREATE DATABASE statements for databases with > the same Locale/Encoding as the server miss the parameters ENCODING, > LC_COLLATE and LC_CTYPE. So you 'can't' migrate to a server with a different > Locale/Encoding setting. > I'd be very happy if one had the option to switch between OS specific names > e.g. German_Germany.28591 on Windows and de_DE on Linux automatically ( -b > WIN ) or manually ( -w German_Germany.28591,de_DE+...) as well. These seem to go in opposite directions - if I'm understanding correctly, we could solve the first problem by always emitting the locale and encoding parameters, but then that'd make it more likely that you would run into conflicts in the second case. I think the best option may be to dump globals with pg_dumpall -g and then back up each database with pg_dump -Fc. The custom format dumps are really nice (selective restore, parallel restore) and of course that also gives you the option to create the database first and then restore the dump into it, which would let you dodge this problem. > I'd also be very happy if one could specify a comma separated list of > databases to skip (e.g. template1, postgres etc.) Seems like it could be useful, or maybe a list of databases to include would be better, not sure. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5870: Cannot get the first popup window during install
On Tue, Feb 8, 2011 at 9:35 AM, T Zimmerman wrote: > > The following bug has been logged online: > > Bug reference: 5870 > Logged by: T Zimmerman > Email address: zimmee_freep...@hotmail.com > PostgreSQL version: 8.4.1-2 > Operating system: Vista Home Premium with SP2 > Description: Cannot get the first popup window during install > Details: > > I cannot get the first popup window during install. I saw one person on > your blog mention that but didn't see a response. I just click on the .exe > for 8.4.1 and nothing at all happens. Things I've tried: > o Ensuring I am an administrator > o Run as administrator > o Creating another user as administrator for the install > o Turning off Windows User Access Control (UAC) > o Monitoring the Task Manager (see no evidence) > o Monitoring the Windows Event logs (see no evidence) > o Ensuring I have enough memory (3GB seems like enough) > o Verifying proper hardware which is HP Pavilion dv4 Notebook, 2GHz dual > CPUs, 3GB memory, 32 bit OS > > What to do??? > THANKS! > T Can you check whether there's a log file in %TEMP% called something like bitrock_installer_xxx.log, where xxx is a number? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5869: postgresql corrupts unquoted non-ascii chars in column aliases
On Tue, Feb 8, 2011 at 2:19 AM, David Schmitt wrote: > Example query: > > SELECT column as zurück FROM table; > > results in corruption of the "ü" (umlaut u). This causes Npgsql to fail to > match up the columns in the result set (see > http://pgfoundry.org/tracker/?func=detail&aid=1010988&group_id=1000140&atid= > 590) and pgadminIII doesn't display the alias in the result pane. That link doesn't show anything interesting when I look at it. What exactly do you mean by corrupted? > The same query works with the same tools against a 8.4.5 running on Debian > squeeze. > > If the alias is quoted like this: > > SELECT column as "zurück" FROM table; > > the query also works against the DB running on windows. > > PS: I tried downloading the newest version of the one click installer for > windows from EnterpriseDB, and noticed that since recently that site > requires a registration :-( I think this has been fixed. Please let me know if not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5871: database connecting failed
On Tue, Feb 8, 2011 at 11:16 AM, cheerag wrote: > > The following bug has been logged online: > > Bug reference: 5871 > Logged by: cheerag > Email address: kavis...@gmail.com > PostgreSQL version: 8.3.1 > Operating system: Windows XP professional service pack 3 > Description: database connecting failed > Details: > > I have been installing the latest version like 9.0 and i have entered the > password as "test" but when i try to connect it tell me that database cannot > connect...it fails...to connect on local server itselfi downloaded the > 8.4 and 8.3in that version also..there was the same problem. its there > anyway to solve this problem or reset this password This report is missing a few key details, such as exactly how you are trying to connect, and the exact text of whatever error message you are getting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5867: wish: plpgsql print table for debug
On Mon, Feb 7, 2011 at 1:01 AM, Richard Neill wrote: > > The following bug has been logged online: > > Bug reference: 5867 > Logged by: Richard Neill > Email address: postgre...@richardneill.org > PostgreSQL version: 9.03 > Operating system: Linux > Description: wish: plpgsql print table for debug > Details: > > When debugging a plpgsql function, it would be really amazingly useful to be > able to do a regular psql-style SELECT, and have the result printed to > screen. > > Something like: > > Raise Notice table 'SELECT ' > > and then plpgsql would run the query and dump the result to screen, using > its helpful formatting. > > As far as I can see, this isn't possible (though there are a lot of people > searching for how to do it), and the only workaround is to manually handle > the looping and formatting, raising lots of individual notices. This makes > debugging much harder than it should be. It wouldn't be too hard to write a loop that runs the select statement and does RAISE NOTICE on each row. Getting that into the psql formatting would be a little trickier, but I don't see why you couldn't write a PL/pgsql function to do it. Then you could just call that function and pass it an SQL query every time you want to do this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5863: help message report 5433 as default port
On Wed, Feb 2, 2011 at 4:06 PM, R. Engmann wrote: > > The following bug has been logged online: > > Bug reference: 5863 > Logged by: R. Engmann > Email address: rengm...@web.de > PostgreSQL version: 9.0.3 > Operating system: Windows 32bit > Description: help message report 5433 as default port > Details: > > running postgresql-9.0.3-1-windows.exe --help > tells the default port for postgres is 5433 > (supposed to be 5432). I can reproduce this. It appears to be an installer bug. Dave? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5861: lo_import and lo_export methods not working from the client side if database is at remote
On Wed, Feb 2, 2011 at 1:54 AM, Pankaj Singh wrote: > > The following bug has been logged online: > > Bug reference: 5861 > Logged by: Pankaj Singh > Email address: er1.pan...@gmail.com > PostgreSQL version: 9.0.2 > Operating system: Window XP > Description: lo_import and lo_export methods not working from the > client side if database is at remote > Details: > > Hello Sir/Madam, > > I am using PostgerSQL latest version and trying to insert and export image > from the client machine(Window) through VB program with the help of > lo_import and lo_export methods respectively. But I am unable to insert as > well as export image through the client machine from the remote PostgreSQL > database. > > Please note that PostgreSQL database server running at remote machine and > client application is in Visual Basic. > Please help me i am waiting for positive response from your side. This isn't a bug. You should try your question on pgsql-general or pgsql-novice, with a lot more detail. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5891: Unique index is not unique
On Thu, Feb 17, 2011 at 4:51 AM, Alexander V. Chernikov
wrote:
> Identical records:
> meganet=# SELECT count(*), array_agg(bc_payment_id) FROM billing.bc_payments
> GROUP BY contractor_name, payment_date, payment_commission_number,
> payment_sum, contractor_account, contractor_bik, inn HAVING count(*) > 1;
> count | array_agg
>
>
> ---+-
>
>
> 2 | {6376,6380}
>
>
> 2 | {6947,6605}
Has this database crashed at any point?
Can you reply-all with the output of SELECT ctid, xmin, xmax,
bc_payment_id FROM billing.bc_payments WHERE bc_payment_id IN
(6376,6380,6947,6605)?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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] can't build contrib/uuid-ossp
On Wed, Feb 16, 2011 at 1:10 PM, Jeff Hamann wrote: > Dear PostgreSQL bug-squasher-team, > I was trying to build postgresql-9.0.2 with the following ./configure: > $ ./configure --enable-cassert --enable-debug --with-python --with-ossp-uuid > and got the following message: > checking uuid.h presence... yes > configure: WARNING: uuid.h: present but cannot be compiled > configure: WARNING: uuid.h: check for missing prerequisite headers? > configure: WARNING: uuid.h: see the Autoconf documentation > configure: WARNING: uuid.h: section "Present But Cannot Be Compiled" > configure: WARNING: uuid.h: proceeding with the preprocessor's result > configure: WARNING: uuid.h: in the future, the compiler will take precedence > configure: WARNING: ## ## > configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## > configure: WARNING: ## ## > checking for uuid.h... yes Hmm. What platform is this on? And what's in config.log? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5906: assertion failure in AtCleanup_Portals
On Thu, Mar 3, 2011 at 09:14, YAMAMOTO Takashi wrote: >>> i got the following with my application, which uses >>> PQsendPrepare+PQsendQueryPrepared for nearly everything >>> including ROLLBACK. > > here's a small test case. I was able to reproduce the assertion failure. It looks we call CreatePortal for ROLLBACK, but don't invoke DropPortal nor AtAbort_Portals before AtCleanup_Portals. -- Itagaki Takahiro -- 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 #5910: Function pg_get_expr throwing error for non superuser
On 03.03.2011 10:59, tushar wrote:
Pls refer this below scenario
PG 8.4.4:-
=
connect to non superuser :-
postgres=# \c - t
psql (8.4.4)
You are now connected to database "postgres" as user "t".
postgres=> select pg_get_expr('a',null);
pg_get_expr
-
(1 row)
It was an oversight that we allowed that previously, because the user
can easily crash the backend by passing bogus values. Try 8.4.5 or
later, and you will get the same error that you do on 9.0.2.
--
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 #5910: Function pg_get_expr throwing error for non superuser
The following bug has been logged online:
Bug reference: 5910
Logged by: tushar
Email address: tushar...@gmail.com
PostgreSQL version: 9.0.2
Operating system: RHEL-5 32 bit
Description:Function pg_get_expr throwing error for non superuser
Details:
Pls refer this below scenario
PG 8.4.4:-
=
connect to non superuser :-
postgres=# \c - t
psql (8.4.4)
You are now connected to database "postgres" as user "t".
postgres=> select pg_get_expr('a',null);
pg_get_expr
-
(1 row)
postgres=>
PG 9.0.2
=
connect to non superuser :-
postgres=# \c - t
You are now connected to database "postgres" as user "t".
postgres=> select pg_get_expr('a',null);
ERROR: argument to pg_get_expr() must come from system catalogs
postgres=>
Workaround:- if user is superuser then it is working fine..
I found a thread somewhat related to this above issue :-
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00503.php
which look fixed now in PG 9.0.2
e.g:-
postgres=> SELECT pg_get_expr(proargdefaults,
'pg_catalog.pg_class'::regclass)
FROM pg_proc pr
LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid limit 0;
pg_get_expr
-
(0 rows)
postgres=>
so i feel this query :-select pg_get_expr('a',null);
should also work in PG 9.0.2 but it is not working. is this an expected
behavior?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
