Rusty Conover wrote:
> It seems like this is a race condition cause by the system catalog cache not
> being locked properly. I've included a perl script below that causes the
> crash on my box consistently.
>
> The script forks two different types of processes:
>
> #1 - begin transaction, creat
Pavel Golub wrote:
> Hello, Pgsql-bugs.
>
> PostgreSQL version: 8.4.x
> Operating system: All
>
> If RETURNS TABLE clause of CREATE FUNCTION contain column of character type
> (withou
> length specifier) it should be treated as character(1) according to
> manual, but it look like text.
> (http
Hi Sir,
Suppose I created a function getage(id character varying).
Now Is there any query in postgreSQL that I can retreive the name of all
user difned/system function in the database schema.
like "select VIEW_TYPE_OWNER, VIEW_TYPE, OID_TEXT from user_views" will list
all views in oracle.
or
selec
2010/4/14 Gaurav K Srivastav :
> Hi Sir,
>
> Suppose I created a function getage(id character varying).
>
> Now Is there any query in postgreSQL that I can retreive the name of all
> user difned/system function in the database schema.
> like "select VIEW_TYPE_OWNER, VIEW_TYPE, OID_TEXT from user_vi
Gaurav K Srivastav wrote:
> Suppose I created a function getage(id character varying).
> Now Is there any query in postgreSQL that I can retreive the name
> of all user difned/system function in the database schema.
> like "select VIEW_TYPE_OWNER, VIEW_TYPE, OID_TEXT from user_views"
> will list
On Apr 14, 2010, at 7:10 AM, Heikki Linnakangas wrote:
> Rusty Conover wrote:
>> It seems like this is a race condition cause by the system catalog cache not
>> being locked properly. I've included a perl script below that causes the
>> crash on my box consistently.
>>
>> The script forks two
Heikki Linnakangas writes:
> According to the comments above RelationClearRelation(), if it's called
> with 'rebuild=true', the caller should hold a lock on the relation, i.e
> refcnt > 0. That's not the case in RelationFlushRelation() when it
> rebuilds a new relcache entry.
> Attached patch sho
I wrote:
> Why would this patch fix anything? It doesn't change the lock status.
I have not been able to reproduce the crash using Rusty's script on my
own machine, but after contemplating his stack trace for awhile I have a
theory about what is happening. I think that while we are building a
ne
The following bug has been logged online:
Bug reference: 5420
Logged by: cool
Email address: coolshower2...@yahoo.co.jp
PostgreSQL version: 8.1.8
Operating system: debian 2.6.18-6-686
Description:pg_attribute broken
Details:
We use PostgreSQL Databse on Hospital Inf
The following bug has been logged online:
Bug reference: 5421
Logged by: cool shower
Email address: coolshower2...@yahoo.co.jp
PostgreSQL version: 8.1.8
Operating system: debian 2.6.18-6-686
Description:pg_attribute broken
Details:
We use PostgreSQL Databse on Hospi
> I'd certainly call this a bug, if not a couple of different bugs.
There seems to be more. I see a problem not just with unqualified char not
being treated equivalent to char(1). I also see a general problem with RETURNS
TABLE disregarding any explicit lengths declared for any character type. F
2010/4/14 Kevin J Bluck :
>> I'd certainly call this a bug, if not a couple of different bugs.
>
> There seems to be more. I see a problem not just with unqualified char not
> being treated equivalent to char(1). I also see a general problem with
> RETURNS TABLE disregarding any explicit lengths
"cool shower" wrote:
> PostgreSQL version: 8.1.8
> Q2:Does anything have repair patches ?
You may want to review the fixes between 8.1.8 and the latest 8.1
bug fix release, which is 8.1.20:
http://www.postgresql.org/docs/8.1/static/release.html
Perhaps one of these fixes would help. I'd
"cool shower" writes:
>
> attrelid addname atttypidattstattarget attlen
> attnum
> 45762santeiflg18_4 0 0 0
> 0 (?)
What do you mean by "0 (?)"? There shouldn't be any entries in
pg_attribute with attnum zero. The
Hi Tom,
Note that we recommend using -fwrapv with gcc, so that it doesn't break
code that depends on this type of test. (If int4inc isn't working then
there are probably a lot of other places that are broken too.) I imagine
LLVM has the same or similar switch.
llvm-gcc has the -fwrapv flag,
Pavel Golub writes:
> Example:
> CREATE OR REPLACE FUNCTION test_char_function()
> RETURNS TABLE(id int, salesourcecode character) AS
> $BODY$
> VALUES (1, 'one'), (2, 'two'), (3, 'three');
> $BODY$
> LANGUAGE 'sql'
> pqfmod function from libpq library for salesourcecode column returns
> 0,
Pavel Stehule writes:
> RETURNS TABLE (x int, y int) is equal to CREATE FUNCTION foo(.. OUT x
> int, OUT y int) RETURNS SETOF RECORD. But PostgreSQL functions ignore
> typmod for parameters - so it is not bug, it is feature :(
Yeah. Or at least, this is not something that can be changed without
John Regehr writes:
> Hi Tom,
>> None of these proposals are improvements over what's there. The
>> fundamental problem is that if the compiler chooses to believe that
>> overflow doesn't exist, it can optimize away *any* test that could only
>> succeed in overflow cases. Finding a form of the t
>> PostgreSQL functions ignore typmod for parameters...
> ...not something that can be changed without a great
> deal of work --- and application breakage...
Thanks to all for the clarifications. I can make it return what I wanted with
qualified character types by returning a SETOF RECORD types,
"Kevin J Bluck" writes:
> But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
> legal to specify them in that clause?
Yeah, possibly. CREATE FUNCTION has historically accepted (and then
discarded) typmod information for all function parameter and result
types; RETURNS TABLE doe
Perhaps this is some Solaris-specific change he is seeing.
---
Craig Ringer wrote:
> [re-posting as I mistakenly sent this only to the OP]
>
> On 09/04/10 16:49, Wolfgang.Koenig wrote:
> > initdb stores default client_encod
I haven't seen anyone reply to this report, which might mean we are
waiting for Gentoo to be fixed. Gentoo is notoriously dynamic and it is
hard for us to adjust based on their changes in every case, which I
guess explains why 8.4.X has not been fixed either.
"Wolfgang.Koenig" writes:
> initdb stores default client_encoding from environment-variable
> Postgres Version: 8.4.3 and 8.3.6
> Operating System: Sun Solaris 5.10 and SuseEnterprise 9
> When a database is initialized with the initdb-command, the default
> client_enconding, which will be stored
Juan C. Aragon wrote:
> Hi Guys:
>
>
>
> I need to know how to reset the ACL to default (null) for a function. This
> is for PostgreSQL 8.0.14 and 8.4.1 on Windows.
>
> I used the User Interface to removed all the Privileges, but the ACL is
> still = {}
>
> I need to make the ACL to be blank
On 15/04/2010 8:05 AM, Tom Lane wrote:
"Kevin J Bluck" writes:
But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
legal to specify them in that clause?
Yeah, possibly. CREATE FUNCTION has historically accepted (and then
discarded) typmod information for all function parame
Craig Ringer writes:
> So - I do think there's a bug here, if _tables_ can be created with
> character(1) fields containing three- or four-character strings.
[ shrug... ] If you can demonstrate such a behavior, I'd agree it's a
bug, but the examples at hand have nothing to do with what gets sto
On 15/04/2010 10:25 AM, Tom Lane wrote:
Craig Ringer writes:
So - I do think there's a bug here, if _tables_ can be created with
character(1) fields containing three- or four-character strings.
[ shrug... ] If you can demonstrate such a behavior, I'd agree it's a
bug, but the examples at han
That is a serious problem. Based on your ASAP requirement, I think you
need a commercial support contract or consultant to fix this for you.
---
cool wrote:
>
> The following bug has been logged online:
>
> Bug reference:
I wrote:
> It's fairly easy to reproduce in the regression database:
> type "\d ten". I'm not sure what the triggering condition
> is exactly, because some seemingly-similar cases don't fail,
> for instance "\d test" works as expected, ditto "\d t".
It turns out that the problem occurs when there
2010/4/15 Tom Lane :
> "Kevin J Bluck" writes:
>> But if RETURN TABLE doesn't respect typemods, perhaps it shouldn't be
>> legal to specify them in that clause?
>
> Yeah, possibly. CREATE FUNCTION has historically accepted (and then
> discarded) typmod information for all function parameter and r
30 matches
Mail list logo
