Ü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 be an
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 beta
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 'GRANT
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,
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 (ra,
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
spilling
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?
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
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 this
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 reactive
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
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.
Thanks. As you
Josh Berkus josh@agliodbs.com 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
Oleg Bartunov oleg@sai.msu.su 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
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
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
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov oleg@sai.msu.su 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
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
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,
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:
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 our
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
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
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
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
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
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
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
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
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 docs, and
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
workaround for this
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.
Actually,
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 if we don't find
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 simple
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
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) Err#89
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:
10832:
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 someone who
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 8.0
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
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
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.
42 matches
Mail list logo
