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,
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
De
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
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, everyth
> -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
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
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
"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 ot
> 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 lik
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
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
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-bug
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
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
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 = 'Tim
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,
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
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
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://2ndQuad
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
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 se
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 co
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 r
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 b
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'
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 co
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: Tur
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
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 s
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
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
"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
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 functi
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: p
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
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
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 .
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:
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, t
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
> m
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 p
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 t
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 rea
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
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: Pr
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'
"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
doubl
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
>
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
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
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
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
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 be
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:
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
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 Enterp
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 w
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:
>
>
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: Memo
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-
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:
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
> t
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:
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
> Descriptio
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
> Descri
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_
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:
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: p
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 rep
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 a
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 coun
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 presen
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 CreatePo
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
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 be
75 matches
Mail list logo
