On 9/13/12 11:58 PM, Tom Lane wrote:
I wrote:
A probably less costly solution than marking current_call_data volatile
is just to make it not-static.
And on still further investigation, the patch I just applied to HEAD
seems to make it go away too. Bizarre as can be. If that holds up for
you,
The following bug has been logged on the website:
Bug reference: 7539
Logged by: Yug
Email address: yugandharh...@gmail.com
PostgreSQL version: 9.2.0
Operating system: (Red Hat 4.1.2-52), 64-bit
Description:
Hello,
I am seeing a mismatch in the results returned
I think everything is covered by Mike here. "getlocales.exe" returns the
list of locales in the format "Language, Country" for most of them. and
this worked fine on 9.1, but does not work on 9.2. And if we are looking
for a workaround in installer, then as Mike suggested, we should handle it
in ini
I think everything is covered by Mike here. "getlocales.exe" returns the
list of locales in the format "Language, Country" for most of them. and
this worked fine on 9.1, but does not work on 9.2. And if we are looking
for a workaround in installer, then as Mike suggested, we should handle it
in ini
On Friday, September 14, 2012, Sandeep Thakkar wrote:
> I think everything is covered by Mike here. "getlocales.exe" returns the
> list of locales in the format "Language, Country" for most of them. and
> this worked fine on 9.1, but does not work on 9.2. And if we are looking
> for a workaround i
No.. what I mean to say is that the output from getlocales is same in 9.1
and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not
accepting the same output. So, it has nothing to with the VC++ runtimes.
PG9.1:
--
c:\Program Files\PostgreSQL\9.1>bin\initdb.exe" --locale="English
On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar
wrote:
> No.. what I mean to say is that the output from getlocales is same in 9.1
> and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not
> accepting the same output. So, it has nothing to with the VC++ runtimes.
Ah, OK. Sorr
I note also that two of the special case locales Mike found are ones
that are supposed to be handled properly by that patch (they have dots
in the name). Here's an earlier attempt, which I believe the second
patch was intended to complement:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=com
On Thursday, September 13, 2012 10:57 PM Fujii Masao
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
The following bug has been logged on the website:
>>>
Bug reference: 7534
>>
On Thu, Sep 13, 2012 at 1:45 PM, Jeff Davis wrote:
> On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
>> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
>> > This bug seems particularly troublesome because the right fix would be
>> > to include the relpersistence in the WAL records that n
Dave Page writes:
> On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar
> wrote:
>> No.. what I mean to say is that the output from getlocales is same in 9.1
>> and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not
>> accepting the same output. So, it has nothing to with the VC
Marko Tiikkaja writes:
> On 9/13/12 11:58 PM, Tom Lane wrote:
>> And on still further investigation, the patch I just applied to HEAD
>> seems to make it go away too. Bizarre as can be. If that holds up for
>> you, I think back-patching that change is less ugly than making the
>> variable non-st
On Fri, Sep 14, 2012 at 10:09 AM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar
>> wrote:
>>> No.. what I mean to say is that the output from getlocales is same in 9.1
>>> and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not
>>> ac
On 9/14/12 4:26 PM, Tom Lane wrote:
So that explains why including perl.h is relevant. Would you like to
try modifying your copy of pthread.h to confirm it's the same situation
on Ubuntu?
Yup, that fixes it.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
yugandharh...@gmail.com writes:
> I am seeing a mismatch in the results returned by a select statement
> on Postgres 9.2.0. What I am seeing is a select statement with an additional
> restriction is returning results which are not part of the select statement
> without that additional restric
The following bug has been logged on the website:
Bug reference: 7540
Logged by: Gl
Email address: grandl...@gmail.com
PostgreSQL version: 9.0.1
Operating system: Windows Server 2012
Description:
Good day. I have a folder "Data". PG versioned postgresql-9.0.1-1.1C (x6
Sorry I didnt mention it.
temp is a table name.
FOR r in select distinct(id) from temp
There are no distinct id's in table 'temp', so record 'r' has null values.
So I guess the control is not going inside the loop.
Any suggestions?
--
View this message in context:
http://postgresql.10456
On 09/14/12 8:31 AM, te wrote:
Sorry I didnt mention it.
temp is a table name.
FOR r in select distinct(id) from temp
There are no distinct id's in table 'temp', so record 'r' has null values.
So I guess the control is not going inside the loop.
Any suggestions?
there's a difference betwee
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>
> On Thursday, September 13, 2012 10:57 PM Fujii Masao
> On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
>> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
>> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
> The following bug has bee
On Fri, Sep 14, 2012 at 12:21 PM, Amit Kapila wrote:
> On Thursday, September 13, 2012 10:32 PM Fujii Masao wrote:
> On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas wrote:
>> On 12.09.2012 22:03, Fujii Masao wrote:
>>>
>>> On Wed, Sep 12, 2012 at 8:47 PM, wrote:
The following bug h
20 matches
Mail list logo
