The following bug has been logged online:
Bug reference: 6018
Logged by: lxzou
Email address: zoulx1...@163.com
PostgreSQL version: 9.1beta1
Operating system: Linux
Description:ctrl +C cause data inconsistent for sync standby
Details:
Dear Sir:
I am interested in
Hi Matthijs,
Thanks for the report.
On Tue, Mar 22, 2011 at 04:31:47PM +0100, Matthijs Bomhoff wrote:
> The bit of SQL below does not behave the way it should on postgres 8.4.4
> (tested by me) and 9.0.3 (verified independently on #postgresql).
On git master, too.
> The third statement in the
On Tue, May 10, 2011 at 11:38 AM, lxzou wrote:
> I am interested in standby function of PG, so i test the new feature about
> sync standby in PG9.1. I have a question, i install only one primary
> postgres and no standby server. When i execute an insert statement in
> primary, this statement was
Hello all,
while packaging 9.1 beta1, I noticed that the "collate" test case now
fails (see attached regression.diffs). It seems to work when I run
this under LANG= LANGUAGE= (i. e. in C locale), but it fails under
both en_US.UTF-8 and de_DE.UTF-8.
Is this just a bug/quirk/expectation of the test
Hello all,
I (or rather the Debian postgresql-common) test suite noticed that
postgresql.conf's "log_timezone = unknown" does not work any more:
server starting
FATAL: invalid value for parameter "log_timezone": "unknown"
I think this should be considered a regression, as it's still in
post
Martin Pitt writes:
> while packaging 9.1 beta1, I noticed that the "collate" test case now
> fails (see attached regression.diffs). It seems to work when I run
> this under LANG= LANGUAGE= (i. e. in C locale), but it fails under
> both en_US.UTF-8 and de_DE.UTF-8.
[ raised eyebrow... ] What pla
The following bug has been logged online:
Bug reference: 6019
Logged by:
Email address: etdirl...@gmail.com
PostgreSQL version: 9.0.4
Operating system: SLES 11 SP1 and WinXP SP3
Description:invalid cached plan on inherited table
Details:
Cached execution plan of SQ
Martin Pitt writes:
> Hello all,
> I (or rather the Debian postgresql-common) test suite noticed that
> postgresql.conf's "log_timezone = unknown" does not work any more:
That was an intentional change, actually. Do you have a real use case
for setting it that way?
> I think this should be cons
Hello,
Tom Lane [2011-05-10 10:35 -0400]:
> That was an intentional change, actually. Do you have a real use case
> for setting it that way?
I don't, it's quite an useless setting. I just stumbled over it as I
use the standard upstream postgresql.conf.sample files (uncommented,
of course) in the
Tom Lane [2011-05-10 10:03 -0400]:
> [ raised eyebrow... ] What platform? This seems to point towards "C"
> locale not doing what it is supposed to ...
After your comment I checked locales on my system, and for some reason
I had an /usr/lib/locales/C.UTF-8/ besides the usual locale-archive. I
cl
Martin Pitt writes:
> Tom Lane [2011-05-10 10:03 -0400]:
>> [ raised eyebrow... ] What platform? This seems to point towards "C"
>> locale not doing what it is supposed to ...
> After your comment I checked locales on my system, and for some reason
> I had an /usr/lib/locales/C.UTF-8/ besides t
Hello again,
sorry for spamming you today, but I promise that this is the last
mail; it's the one remaining test case failure for me.
I have some test cases to verify the handling of the obsolete \'
escaping in different locales (cf. CVE-2006-2313).
Up to 9.0, \' was still allowed in safe locale
We figured it out: the server add simply does not show up until you
close and reopen the app. Once we do that, it behaves normally. It is a
bug, but not a show-stopper.
Thanks!
Alexander Bryant
IT Services for VIDD and SCHARP
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail
On Tue, May 10, 2011 at 06:20:23PM +0200, Martin Pitt wrote:
> Since HISTORY does not mention this, is that an explicit decision to
> finally deprecate the old \' syntax (which would be great, as it makes
> this thing a lot more robust and deterministic, but it might be worth
> mentioning it in HIS
hubert depesz lubaczewski writes:
> On Tue, May 10, 2011 at 06:20:23PM +0200, Martin Pitt wrote:
>> Since HISTORY does not mention this, is that an explicit decision to
>> finally deprecate the old \' syntax (which would be great, as it makes
>> this thing a lot more robust and deterministic, but
hubert depesz lubaczewski [2011-05-10 18:37 +0200]:
> release notes clearly mentions is:
> http://developer.postgresql.org/pgdocs/postgres/release-9-1.html
> >> - Change the default value of standard_conforming_strings to on (Robert
> >> Haas)
> [...]
Ah, of course. Thanks!
(grep failure, sorry)
Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > On Tue, May 10, 2011 at 06:20:23PM +0200, Martin Pitt wrote:
> >> Since HISTORY does not mention this, is that an explicit decision to
> >> finally deprecate the old \' syntax (which would be great, as it makes
> >> this thing a lot more robu
I run my test program with 2 ways in the same login environment.One succeed and
one fail.
1) psql -d dbi_link_test
-->connect succeed
2) psql -h HOSTNAME -d dbi_link_test
-->connect fail
The different is connection options(Unix Domain Sockets/TCP Sockets).
- Original Message -
From: "
On 05/10/11 8:09 PM, 李紅兵 wrote:
I run my test program with 2 ways in the same login environment.One
succeed and one fail.
1) psql -d dbi_link_test
-->connect succeed
2) psql -h HOSTNAME -d dbi_link_test
-->connect fail
The different is connection options(Unix Domain Sockets/TCP Sockets).
is
Bruce Momjian writes:
> Tom Lane wrote:
>> Hmm ... considering that's the first thing in the release notes, I'm
>> surprised Martin missed it. Maybe he was looking for something
>> mentioning backslashes ... should we add a bit that specifically says
>> that backslashes are now no-ops by default?
"" writes:
> Cached execution plan of SQL stored procedure (which select from inherited
> table) executed from within PLPGSQL function is used even when inheritance
> descendant is already removed.
Don't hold your breath waiting for a fix for that :-(. There isn't any
support for detecting plan-
Perhaps you misunderstanding what I mean.
I can connect to postgreSQL server correctly,
but When I connect postgreSQL with TCP Sockets, it return error to connect to
oracle server by DBI->connect from perlu script.
When I connect postgreSQL with Unix Domain Sockets,it works well.
My conf file:
The following bug has been logged online:
Bug reference: 6020
Logged by: Skylar Hawk
Email address: skylar.j.h...@gmail.com
PostgreSQL version: 9.0.3
Operating system: OpenBSD
Description:Wrong data type returned after CAST in FROM
Details:
Hello,
I noticed a stran
On 11/05/11 13:53, 李紅兵 wrote:
> Perhaps you misunderstanding what I mean.
> I can connect to postgreSQL server correctly,
> but When I connect postgreSQL with TCP Sockets, it return error to
> connect to oracle server by DBI->connect from perlu script.
>
> When I connect postgreSQL with Unix Doma
24 matches
Mail list logo
