On 29/01/2012 22:33, Tom Lane wrote:
> Matteo Beccati writes:
>>> I've just noticed that an expression index I've created was not used with a
>>> view contiaining a UNION ALL. Switching to UNION or querying the table
>>> directly works as expected.
>
> Looks like I broke this back in November :-(
That seems to work.
thanks
-Original Message-
From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com]
Sent: 28 January 2012 19:34
To: James Stevenson
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6413: pg_relation_size wont work on table with upper
case chars
On
Excerpts from Andy Grimm's message of sáb ene 28 14:32:24 -0300 2012:
> Perhaps I should just submit the patch to pgsql-hackers ? I'm new to
> the pgsql bug interaction process, so my apologies if filing a bug was
> not the appropriate way to present the issue. I get Internal Server
> Error mes
On Sat, Jan 28, 2012 at 5:48 PM, Alvaro Herrera
wrote:
>
> Excerpts from Andy Grimm's message of sáb ene 28 14:32:24 -0300 2012:
>
>> Perhaps I should just submit the patch to pgsql-hackers ? I'm new to
>> the pgsql bug interaction process, so my apologies if filing a bug was
>> not the appropria
hi,
> y...@mwd.biglobe.ne.jp writes:
>> the following patch fixes/updates/adds random comments in the tree.
>
> Applied, thanks.
thanks.
>
> BTW, it took some manual effort to undo the line-wrapping that got done
> on this posting. It'd be better to send patches directly to the
> pgsql-hacker
On 1/29/2012 3:02 AM, Dave Page wrote:
On Sat, Jan 28, 2012 at 2:47 AM, Dharmendra Goyal
wrote:
Nice analysis Eric. ANy idea why (which program set this) this particular
registry was set.
Dave, shall we consider using "%COMSPEC% /c" with 0 as second parameter..??
We can certainly try it, th
On Sat, Jan 28, 2012 at 8:45 PM, Michael Brauwerman
wrote:
> We did try that with a postgres 9.1.2, compiled from source with debug
> flags, but we got 0x10 bad address in gdb. (Obviously we did it wrong
> somehow)
>
> We will keep trying to get a good set of symbols set up.
Hmm. Your backtrace
The following bug has been logged on the website:
Bug reference: 6420
Logged by: Thomas McGlynn
Email address: tom.mcgl...@nasa.gov
PostgreSQL version: 9.1.2
Operating system: Any
Description:
As part of our preparations for the leap second this year I wanted to see
h
The following bug has been logged on the website:
Bug reference: 6421
Logged by: Bartosz Dmytrak
Email address: bdmyt...@eranet.pl
PostgreSQL version: 9.1.2
Operating system: Mandriva 2011 64 bit
Description:
Cannot revoke column level privilages.
Scenario:
1. as „po
All right, so we were able to get a full bt of the alloc error on a test
system. Also, since we have a lot of emails going around on this - I
wanted to make it clear that we're seeing *two* production errors, which
may or may not be related. (The OP for bug #6200 also sees both issues.)
One is a
bdmyt...@eranet.pl writes:
> Cannot revoke column level privilages.
AFAICS this is not a bug, and it's certainly not specific to
column-level privileges. You had "postgres" grant some privileges to
"otherUser" with grant option, and then had "otherUser" re-grant those
privileges to public. "post
tom.mcgl...@nasa.gov writes:
> As part of our preparations for the leap second this year I wanted to see
> how Postgres handles this. The only information I could see was
> (Technically, PostgreSQL uses UT1 because
> leap seconds are not handled.)
> in section 9.9 of the manual. This seems to be
Bridget Frey writes:
> The second error is an invalid memory alloc error that we're getting ~2
> dozen times per day in production. The bt for this alloc error is below.
This trace is consistent with the idea that we're getting a corrupt
tuple out of a table, although it doesn't entirely preclud
The following bug has been logged on the website:
Bug reference: 6422
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Linux
Description:
Hi.
Unfortunately I was hit by that problem in the real project.
During a
Hi Tom,
Thanks for the reply, we appreciate you time on this. The alloc error
queries all seem to be selects from a btree primary index. I gave an
example in my initial post from the logins table. Usually for us it
is logins but sometimes we have seen it on a few other tables, and
it's always a
Bridget Frey writes:
> Thanks for the reply, we appreciate you time on this. The alloc error
> queries all seem to be selects from a btree primary index. I gave an
> example in my initial post from the logins table. Usually for us it
> is logins but sometimes we have seen it on a few other tab
I wrote:
> Hm. The stack trace is definitive that it's finding the bad data in a
> tuple that it's trying to print to the client, not in an index.
BTW, after a bit more reflection it occurs to me that it's not so much
that the data is necessarily *bad*, as that it seemingly doesn't match
the tupl
Hi Mark,
Install log shows that your db installation is successful. The error which
you had sent is coming because your earlier installation failed to create
'postgres' user and when you ran the installer again, installer read
/etc/postgres-reg.ini file to check any previous installation and found
18 matches
Mail list logo
