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 has been logged on the website:
>>>
>>> Bug reference: 7533
The following bug has been logged on the website:
Bug reference: 7537
Logged by: Owen Sleep
Email address: dfisupp...@docfocus.ca
PostgreSQL version: 9.0.8
Operating system: Windows Server 2003 Service Pack 2
Description:
PostgreSQL service was running successfully fo
On 09/13/12 12:17 PM, te wrote:
FOR r in select distinct(id) from temp
select clean()
what is this selecting records from? what is "temp" ?
--
john r pierceN 37, W 122
santa cruz ca mid-left coast
--
Sent via pgsql-
Hi all,
I am new to postgresql and I am trying to write a function which uses record
(r) to select from table and then proccess that record value.
CREATE OR REPLACE FUNCTION clean()
RETURNS integer AS $$
DECLARE
r record;
result integer:= 0;
BEGIN
FOR r i
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, I think back-patching that change is
I wrote:
> Apparently the reasoning is that current_call_data is a static and
> therefore the compiler can see everything that can happen to it and
> therefore this store into current_call_data is dead code, since the
> store six lines below will replace it. Sigh. I shall file a bug,
> but I've f
Marko Tiikkaja writes:
> On 13/09/2012 19:48, Tom Lane wrote:
>> Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly?
> We've reproduced it on both 5.14.2 and 5.16.1.
Meh. I've managed to reproduce it on the fifth system I tried. I don't
think it's got anything to do with
Sandeep, can you look into this and respond on list please? The thread
started here: http://archives.postgresql.org/pgsql-bugs/2012-09/msg00083.php
It sounds to me like the OS is at fault for not accepting the name it
gives to a locale as input, and that the change to the installer would
be a work
On 13/09/2012 19:48, Tom Lane wrote:
Marko Tiikkaja writes:
On 9/12/12 1:50 AM, Tom Lane wrote:
Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly?
We've reproduced it on both 5.14.2 and 5.16.1.
What happens is that free_plperl_function() for some reason gets called
w
Marko Tiikkaja writes:
> On 9/12/12 1:50 AM, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> Joel Jacobson managed to narrow it down to this test case, which crashes
>>> consistently on Ubuntu 12.04 both with and without your patch. I,
>>> however, wasn't able to reproduce the problem on my OS X M
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
>>> Logged by: Amit Kapila
>>> Email address:
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 need it. But that
> > can't be backported (right?).
>
> N
The following bug has been logged on the website:
Bug reference: 7536
Logged by: Brad Bowman
Email address: b...@bereft.net
PostgreSQL version: 9.1.5
Operating system: linux
Description:
I'd like a -c (or -f) option that doesn't exit immediately. In my case, I'd
like
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 has been logged on the website:
>>>
>>> Bug reference: 7533
>>> Logged by: Amit Kapila
>>> Email address:
Dimitri Fontaine writes:
> I think we shouldn't change the content of pg_depend lightly here, and
So here's a patch following that idea.
Even for TIP I don't want us to change how pg_depend tracking is done,
because I want to propose a fix for the pg_dump bug wrt sequences and
pg_extension_confi
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 need it. But that
> can't be backported (right?).
No, because if a WAL record was written at all, then by definition
Alvaro Herrera writes:
> Well, what I saw was that both the table and its SERIAL-generated
> sequence got an DEPENDENCY_EXTENSION row in pg_depend, which is exactly
> what (IMV) causes the problem. One of my proposals is to tweak the code
> to avoid that row (but if we do that, then we need to do
On Thursday, September 13, 2012 5:52 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 has been logged on the website:
>>
>>> Bug reference: 7533
>>> Logged by: Amit Kapila
>>> Email address: amit.
On 12.09.2012 22:03, Fujii Masao wrote:
On Wed, Sep 12, 2012 at 8:47 PM, wrote:
The following bug has been logged on the website:
Bug reference: 7533
Logged by: Amit Kapila
Email address: amit.kap...@huawei.com
PostgreSQL version: 9.2.0
Operating system: Suse
Description:
19 matches
Mail list logo
