Sibtay Abbas <[EMAIL PROTECTED]> writes:
> All the information related to functions are stored in pg_proc system
> catalog. But when a function is compiled (probably the data structure
> that contains a compiled function is pgfunction) where is it stored
> for persistence.
It isn't.
Hello everyone
i have been studying postgres's function handling philosophy lately. I
got stuck at a point where i could'nt get the answer myself
All the information related to functions are stored in pg_proc system
catalog. But when a function is compiled (probably the data structure
that contai
Will this make it into 8.1?
>-Original Message-
>From: Tom Lane [mailto:[EMAIL PROTECTED]
>Sent: Thursday, January 27, 2005 7:38 PM
>To: Kenneth Lareau
>Cc: David Parker; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and
>Solaris automounts
>
>Ke
On Thu, 27 Jan 2005, Robert Treat wrote:
On Thursday 27 January 2005 20:47, Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
On Thursday 27 January 2005 10:27, Tom Lane wrote:
Ordinarily I would agree with you, but what happens to someone who is
still running 8.0.* when IBM's patent gets is
On Thursday 27 January 2005 20:47, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Thursday 27 January 2005 10:27, Tom Lane wrote:
> >> Ordinarily I would agree with you, but what happens to someone who is
> >> still running 8.0.* when IBM's patent gets issued?
> >
> > This is a s
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thursday 27 January 2005 10:27, Tom Lane wrote:
>> Ordinarily I would agree with you, but what happens to someone who is
>> still running 8.0.* when IBM's patent gets issued?
> This is a straw-man, since nothing stops people from running 8.0.0
> even i
Yes, thanks very much!
- DAP
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Lareau
>Sent: Thursday, January 27, 2005 8:10 PM
>To: Tom Lane
>Cc: Kenneth Lareau; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on
On Thursday 27 January 2005 10:27, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I don't think it is worth breaking the expectation that only minor
> > changes get committed in revision level releases even with a beta.
>
> Ordinarily I would agree with you, but what happens to some
In message <[EMAIL PROTECTED]>, Tom Lane writes:
>Kenneth Lareau <[EMAIL PROTECTED]> writes:
>> In message <[EMAIL PROTECTED]>, Tom Lane writes:
>>> Could you truss that and see what it does?
>
>> Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0'
>> on my Solaris 9 system:
>
Kenneth Lareau <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, Tom Lane writes:
>> Could you truss that and see what it does?
> Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0'
> on my Solaris 9 system:
> 10832: mkdir("/software/postgresql-8.0.0", 0777)
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> There's also a tiny race condition, which I guess isn't worth worrying
> about.
Considering that we're not checking ownership or permissions of the
parent directories, I'd say not.
regards, tom lane
---
Tom Lane wrote:
I don't know why the command 'mkdir' doesn't exhibit the
same problem as the function 'mkdir', but running:
mkdir /software/postgresql-8.0.0
produces the correct error "File exists" on my system.
Could you truss that and see what it does? It would be a simpl
In message <[EMAIL PROTECTED]>, Tom Lane writes:
>Kenneth Lareau <[EMAIL PROTECTED]> writes:
>> In message <[EMAIL PROTECTED]>, Tom Lane writes:
>>> I suppose that manually creating the data directory before running
>>> initdb would also avoid this issue, since the mkdir(2) loop is only
>>> entered
Kenneth Lareau <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, Tom Lane writes:
>> I suppose that manually creating the data directory before running
>> initdb would also avoid this issue, since the mkdir(2) loop is only
>> entered if we don't find the directory in existence.
> Actua
In message <[EMAIL PROTECTED]>, Tom Lane writes:
>"David Parker" <[EMAIL PROTECTED]> writes:
>> Did initdb previously just assume the -D path existed, and now it is
>> trying to create the whole path, if necessary?
>
>Pre-8.0 it was using mkdir(1), which might possibly contain some weird
>workaroun
On Fri, Jan 28, 2005 at 12:27:05PM +1300, Oliver Jowett wrote:
> Oliver Jowett wrote:
> >Having the close fail
> >because of an intervening savepoint rollback isn't great -- the error
> >will cause an unexpected failure of the current transaction.
>
> Never mind -- I just reread the protocol doc
I tried that, and it just runs into the problem with the first sub dir
it tries to create:
ed9i03:/home/dparker/temp
% initdb -D /home/dparker/temp/testdb
The files belonging to this database system will be owned by user
"dparker".
This user must also own the server process.
The database cluster
Oliver Jowett wrote:
Having the close fail
because of an intervening savepoint rollback isn't great -- the error
will cause an unexpected failure of the current transaction.
Never mind -- I just reread the protocol docs, and it's safe to close a
nonexistant portal. Did this previously issue a wa
"David Parker" <[EMAIL PROTECTED]> writes:
> Did initdb previously just assume the -D path existed, and now it is
> trying to create the whole path, if necessary?
Pre-8.0 it was using mkdir(1), which might possibly contain some weird
workaround for this case on Solaris.
I suppose that manually cr
Alvaro Herrera wrote:
On Wed, Jan 26, 2005 at 05:10:09PM -0500, Tom Lane wrote:
I don't think we have a lot of choices: we have to destroy (or at least
mark FAILED) all such cursors for the time being.
I don't see a lot of difference between marking the portal FAILED and
destroying it (maybe I'm
On Thu, 2005-01-27 at 15:27 -0500, Tom Lane wrote:
> I just noticed that there is no permission check anywhere in CREATE
> AGGREGATE concerning the aggregate's transition and final functions.
> This means anyone can trivially bypass the function EXECUTE permission
> check: just make an aggregate fu
Coincidentally I JUST NOW built 8.0 on Solaris 9, and ran into the same
problem. As they say, "this used to work".
We build databases as part of the build of our product, and I'm looking
into what we need to do to upgrade from 7.4.5, and this was the first
thing I ran into. I hadn't gotten as
Folks,
I ran into an interesting issue when installing PostgreSQL 8.0 that I'm
not sure how to resolve correctly. My system is a Sun machine (Blade
1000) running Solaris 9, with relatively recent patches. After install-
ing 8.0, I went to run the 'initdb' command and was greeted with the
followin
On Thu, 27 Jan 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
It is ~22:00GMT right now ... I will start the packaging process in
approx. 3hrs and will announce once they are all ready ...
I think we are gonna have to put it off a little bit. I haven't even
started doing the
Hmm... I don't remember specifying a datatype. I suppose whatever the
default one is. :)
I'll be happy to test again, just let me know.
Mark
On Fri, Jan 28, 2005 at 06:28:32AM +0900, ITAGAKI Takahiro wrote:
> Thanks for testing, Mark!
>
> > I gave this a try with DBT-2, but got a core dump on
On Thu, Jan 27, 2005 at 15:27:54 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
> I just noticed that there is no permission check anywhere in CREATE
> AGGREGATE concerning the aggregate's transition and final functions.
> This means anyone can trivially bypass the function EXECUTE permission
> check
Thanks for testing, Mark!
> I gave this a try with DBT-2, but got a core dump on our ia64 system.
> I hope this isn't a random thing, like I ran into previously. Maybe
> I'll try again, but postgres dumped core.
Sorry, this seems to be my patch's bug.
Which datatype did you compile with? LP64, I
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> It is ~22:00GMT right now ... I will start the packaging process in
> approx. 3hrs and will announce once they are all ready ...
I think we are gonna have to put it off a little bit. I haven't even
started doing the release notes, and we've got a
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Day ago we run 'vacuum verbose analyze;' and now we're observing
strange output (see below). We see many repeated passes through the
table 'usno' and all indices (2).
Nothing strange about it: that's how vacuum deals with large tables.
You
I just noticed that there is no permission check anywhere in CREATE
AGGREGATE concerning the aggregate's transition and final functions.
This means anyone can trivially bypass the function EXECUTE permission
check: just make an aggregate function to call it for you. (Now, this
works only for funct
It is ~22:00GMT right now ... I will start the packaging process in
approx. 3hrs and will announce once they are all ready ...
Just to clarify, we're doing:
8.0.1
And 7.4/7.3/7.2 branches ... correct?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL P
Oleg Bartunov writes:
> Day ago we run 'vacuum verbose analyze;' and now we're observing
> strange output (see below). We see many repeated passes through the
> table 'usno' and all indices (2).
Nothing strange about it: that's how vacuum deals with large tables.
You can reduce the number of pass
Josh Berkus writes:
> No, we're reactive regardless. Proactive would have been to investigate the
> ARC paper when it was published for outstanding patent applications, and
> again before feature freeze. Or even to have considered the fact that when
> an IBM person publishes a paper on ne
Josh,
> >>Bruce is advocating waiting until the Patent has been Granted, instead of
> >>doing something about it now, when we know the patent is going through
> >> the system (and will likely get granted) ... a "reactive" vs "proactive"
> >> response to the problem.
>
> Very well written Josh.
Th
Hi everyone,
I gave this a try with DBT-2, but got a core dump on our ia64 system.
I hope this isn't a random thing, like I ran into previously. Maybe
I'll try again, but postgres dumped core. Binary and core here:
http://developer.osdl.org/markw/pgsql/core/2morefiles.tar.bz2
#0 Functi
Marc, Tom, Robert, Bruce, et al:
> Bruce is advocating waiting until the Patent has been Granted, instead of
> doing something about it now, when we know the patent is going through the
> system (and will likely get granted) ... a "reactive" vs "proactive"
> response to the problem.
No, we're rea
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> How hard would it be to do as several have suggested already ... abstract
> out the ARC/LRU stuff into an API?
That was basically my objection to Neil's draft patch: it didn't make
any effort to abstract out a cleaner API. I'll try to look into th
On Thu, 27 Jan 2005, Tom Lane wrote:
What's really being debated here is how we can have adequate confidence
in a change that is admittedly larger than we like to back-patch. It's
not an unprecedented thing mind you; we have back-patched some fairly
large bug fixes in the past. But it's a bit
Robert Treat <[EMAIL PROTECTED]> writes:
> I don't think it is worth breaking the expectation that only minor
> changes get committed in revision level releases even with a beta.
Ordinarily I would agree with you, but what happens to someone who is
still running 8.0.* when IBM's patent gets issued
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It's only a SMOC, nothing difficult AFAICS. Disk-spilling logic
> included, because it'd be probably needed.
The question of disk-spilling is really the only part that seems very
hard. It would be useful to see if we could solve the problem of
spillin
Hi there,
we have a table with 500mln rows:
wsdb=# \d usno
Table "public.usno"
Column | Type | Modifiers
++---
ra | real |
dec| real |
bmag | real |
rmag | real |
ipix | bigint |
Indexes:
"ipix_ind" btree (ipix)
"radec_idx1" btree
Greg Stark <[EMAIL PROTECTED]> writes:
> I don't see how you're in the clear. If session A does an insert and it
> doesn't see a duplicate and doesn't commit, but then B does an insert and sees
> the duplicate from A and marks his tentative, and then commits, shouldn't B's
> commit succeed?
No. B
> TODO1: Allow GRANT/REVOKE permissions to be applied to all schema
> objects with one command.
> TODO2: Assign Permissions to schemas wich get automatically inherited
> by objects created in the schema.
>
> a) should we pursue both of them?
> b) how can a syntax for TODO1 look like? Anchored at '
On Wed, 2005-01-26 at 02:09, Neil Conway wrote:
> Tom Lane wrote:
> > This may be the right path to go for
> > 8.0.* ... but we must NOT suppose that we can just push it out without
> > a full beta test cycle.
>
> Yeah, I think a beta period would be a good idea (not nearly as long as
> the 8.0 b
Ühel kenal päeval (kolmapäev, 26. jaanuar 2005, 13:30+1100), kirjutas
Neil Conway:
> Simon Riggs wrote:
> > The one factor which stands out for me from this is that Keir Fraser's
> > and Tim Harris' algorithms are available as *code*, which additionally
> > are covered by a licence which appears to
45 matches
Mail list logo
