pratikchirania writes:
> 1. I am in Costa Rica, using Windows Server 2008 R2/Windows 2003 with
> PostgreSQL 8.3/9.0
> 2. System Date/Time Settings shows "CST/Central America" with UTC-6 as extra
> display
> 4. There is NO DST for CST (Central America) a.k.a America/Costa_Rica to the
> PostgreSQL d
Hi, thanks for the responses. Here are updates from my end:
1. I am in Costa Rica, using Windows Server 2008 R2/Windows 2003 with
PostgreSQL 8.3/9.0
2. System Date/Time Settings shows "CST/Central America" with UTC-6 as extra
display
system timezone: (using command: systeminfo)
Time Zone:
On Fri, Sep 9, 2011 at 9:41 PM, Roman wrote:
> Query
> select null union select 4
> is Ok but
> select null union select null union select 4
> is Fail
>
> i think it`s a bug because you choose type in second query twice
> null and null -> text
> text and int -> fail
Yeah, this is lousy. Unfortun
> It's possible that we could build simple estimators for these operators
> that just turn the problem into a range estimation and then pass it off
> to somewhere else, but nobody has tried.
Right, that's why I'm asking. I'd like to reuse code ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://
Josh Berkus writes:
>> If you mean the indexscan optimization, we do know how to estimate the
>> cost of the indexscans, because that depends mostly on the behavior of
>> the added < or > condition(s). This does not imply knowing how to
>> estimate the behavior of >>= itself.
> If we can estimat
> If you mean the indexscan optimization, we do know how to estimate the
> cost of the indexscans, because that depends mostly on the behavior of
> the added < or > condition(s). This does not imply knowing how to
> estimate the behavior of >>= itself.
If we can estimate the cost of the indexsca
Josh Berkus writes:
> On 9/21/11 1:56 PM, Tom Lane wrote:
>> A look in pg_operator will show you that these operators have no
>> associated selectivity estimators at all. It's not so much "broken"
>> as "unimplemented".
> Oh! I was assuming that the special case code kicked in regardless.
> So
On Wed, Sep 21, 2011 at 11:17 PM, Eric Vollnogel
wrote:
> The date_part('isoyear', some_column) function is not always returning the
> correct result. See below:
See http://www.postgresql.org/docs/8.4/static/functions-datetime.html :
"Each ISO year begins with the Monday of the week containing t
The following bug has been logged online:
Bug reference: 6219
Logged by: Eric Vollnogel
Email address: edvollno...@dstsystems.com
PostgreSQL version: 9.0.4 64bit
Operating system: Windows 7 SP 1 64bit
Description:date_part() function producting incorrect year
Details:
On 9/21/11 1:56 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Summary: special inet operators ( << >> <<= =>> ) are
>> up to 100X off in estimating rowcounts
>
> A look in pg_operator will show you that these operators have no
> associated selectivity estimators at all. It's not so much
Josh Berkus writes:
> Summary: special inet operators ( << >> <<= =>> ) are
> up to 100X off in estimating rowcounts
A look in pg_operator will show you that these operators have no
associated selectivity estimators at all. It's not so much "broken"
as "unimplemented".
regression=# se
Euler Taveira de Oliveira writes:
> On 21-09-2011 13:38, Robert Haas wrote:
>> The rules for interpreting time zone specifications are arcane enough
>> to make me suspect that this isn't a bug even though it seems rather
>> odd, but in any case it would be useful to know how many hours
>> PostgreS
Summary: special inet operators ( << >> <<= =>> ) are
up to 100X off in estimating rowcounts
Type: performance
Severity: normal
Tested on: 9.1.0
Description:
We've been noticing that row estimates for queries which use the =>> and
<<= operators for inet data were way, way off. We fina
On 21-09-2011 13:38, Robert Haas wrote:
On Wed, Sep 21, 2011 at 3:16 AM, pratikchirania wrote:
The command clearly does not return '--with-system-tzdata'. I am using
Windows server 2008 R2. The TZ data must be working fine as other
applications on the OS are working fine. The issue is also repr
On Wed, Sep 21, 2011 at 3:16 AM, pratikchirania wrote:
> The command clearly does not return '--with-system-tzdata'. I am using
> Windows server 2008 R2. The TZ data must be working fine as other
> applications on the OS are working fine. The issue is also reproducible on
> Postgre version 8.3.
Y
On Wed, Sep 21, 2011 at 11:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas wrote:
>>> On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane wrote:
In that case I'm betting Robert broke it somewhere in the unlogged-table
changes.
>
>>> Yeah, looks like
"YAMAMOTO Takashi" writes:
> 9.2devel (2562dcea811eb642e1c5442e1ede9fe268278157)
> ERROR: could not serialize access due to concurrent update
> STATEMENT: UPDATE file SET atime = current_timestamp WHERE fileid = $1
> TRAP: FailedAssertion("!(owner->nsnapshots == 0)", File: "resowner.c", Line:
>
Robert Haas writes:
> On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas wrote:
>> On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane wrote:
>>> In that case I'm betting Robert broke it somewhere in the unlogged-table
>>> changes.
>> Yeah, looks like it. Will investigate.
> I committed a localized fix for
The following bug has been logged online:
Bug reference: 6218
Logged by: YAMAMOTO Takashi
Email address: y...@mwd.biglobe.ne.jp
PostgreSQL version: 9.2
Operating system: NetBSD
Description:TRAP: FailedAssertion("!(owner->nsnapshots == 0)", File:
"resowner.c", Line: 36
On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas wrote:
> On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Excerpts from Abel Abraham Camarillo Ojeda's message of mié sep 14 18:33:33
>>> -0300 2011:
_n_srv=# create table pg_temp.c (x int);
CREATE TABLE
ghtOn Wed, Sep 21, 2011 at 07:29:23AM +0800, Craig Ringer wrote:
> On 21/09/2011 12:05 AM, Lionel Elie Mamane wrote:
>>Bug reference: 6216
>>Logged by: Lionel Elie Mamane
>>Email address: lio...@mamane.lu
>> In C++, a "char**" value is not convertible to a "const char**"
>> val
Hi,
Thanks for your response.
I tried your suggestion and got the following outputs:
C:\PostgreSQL\9.0\bin>pg_config
BINDIR = C:/POSTGR~1/9.0/bin
DOCDIR = C:/POSTGR~1/9.0/doc
HTMLDIR = C:/POSTGR~1/9.0/doc
INCLUDEDIR = C:/POSTGR~1/9.0/include
PKGINCLUDEDIR = C:/POSTGR~1/9.0/include
INCLUDEDIR-SERV
22 matches
Mail list logo
