On Tue, Apr 11, 2006 at 12:47:03AM -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What does enabling plpgsql do via access that you can't just do from an
SQL query?
SQL isn't Turing-complete
With all due respect, SQL *is* Turing-complete. Here's a little demo
of this
On 2006-04-11, Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What does enabling plpgsql do via access that you can't just do from an
SQL query?
SQL isn't Turing-complete
SQL with the ability to create recursive functions, as exists in pg, is
certainly
On Mon, Apr 10, 2006 at 10:02:25PM -0400, Bruce Momjian wrote:
The patch wasn't ignored. It is just that I never got to applying it yet.
Neil's patch vs. psql supercedes this :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
As I reviewed the win32/sema.c, there is some code that I am not clear, can
anybody explain please?
In semctl(SETVAL):
if (semun.val sem_counts[semNum])
sops.sem_op = -1;
else
sops.sem_op = 1;
/* Quickly lock/unlock the semaphore (if we can) */
if (semop(semId, sops, 1) 0)
Andrew - Supernews wrote:
On 2006-04-11, Tom Lane [EMAIL PROTECTED] wrote:
I don't feel a need to offer specific examples as requested by Andrew.
Why not? You're basing your entire argument on a false premise (that
pl/pgsql is more powerful than SQL); I can provide specific examples of
why
On 2006-04-11, Richard Huxton dev@archonet.com wrote:
Andrew - Supernews wrote:
On 2006-04-11, Tom Lane [EMAIL PROTECTED] wrote:
I don't feel a need to offer specific examples as requested by Andrew.
Why not? You're basing your entire argument on a false premise (that
pl/pgsql is more
Hi,
You have to start a background process, then attach to it. If this is
possible in eclipse then it should work.
Typically everyone uses gdb.
Dave
On 9-Apr-06, at 10:55 PM, 李峰 wrote:
pgsql-hackers！
Hi , I want to use eclipse to compiler the postgresql source code
and debug them on
On Mon, 2006-04-10 at 02:16, Martijn van Oosterhout wrote:
The appears to be two seperate cases here though, one is to just farm
out the read request to another process (basically aio), the other is
to do actual processing there. The latter is obviously for more useful
but requires a fair bit
Hi,
when dealing with a bug in the postgresql-plr interface I think
I found a suboptimal method to process CASE statements. First
to the problem:
I'm using the Debian packaged version of PLR version 0.6.2-2 (Debian
testing) and found a problem calculating median from a set of
values that
On Tue, Apr 11, 2006 at 04:43:33PM +0200, Andreas Tille wrote:
Hi,
when dealing with a bug in the postgresql-plr interface I think
I found a suboptimal method to process CASE statements. First
to the problem:
snip
SELECT median(nonnull), median(mightbenull) from plrtest where flag = 0;
Martijn van Oosterhout kleptog@svana.org writes:
The problem in your example is that you're using aggrgates in the case
statement.
Yeah. The aggregate results are all computed before we start to evaluate
the SELECT output list --- the fact that the aggregate is referenced
within a CASE doesn't
On Tue, 11 Apr 2006, Martijn van Oosterhout wrote:
Because there were no non-null rows, the system passed a NULL to the
final func. Seems you have two ways of dealing with this. Mark the
finalfunc as STRICT so the system won't call it with NULL. Or give the
agrregate an INITCOND which is an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm trying to build the rpms for RH9,
I downloaded the srpm for RH9 but I'm stuck on these errors:
Attempt a:
# rpmbuild --rebuild postgresql-8.0.7-1PGDG.src.rpm
Installing postgresql-8.0.7-1PGDG.src.rpm
error: Failed build dependencies:
Can you guarantee unequivocally that there are absolutely not security
issues in plpgsql?
Can you guarantee unequivocally that there are absolutely not security
issues in PostgreSQL?
I believe Tom's point is that it is not possible to do so, and, since
plpgsql isn't something that all
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What does enabling plpgsql do via access that you can't just do from an
SQL query?
SQL isn't Turing-complete --- plpgsql is. So if our would-be hacker has
a need to do some computation incidental to his hack, he can certainly
get it
Richard Huxton wrote:
Andrew - Supernews wrote:
On 2006-04-11, Tom Lane [EMAIL PROTECTED] wrote:
I don't feel a need to offer specific examples as requested by Andrew.
Why not? You're basing your entire argument on a false premise (that
pl/pgsql is more powerful than SQL); I can provide
Alvaro Herrera [EMAIL PROTECTED] writes:
An idea arising in chat with Joshua Drake: the retargetting code, if it
turns out to work and not be excessively expensive, could also be useful
to implement a server-side connection pooling of sorts: the postmaster
could keep idle backends and
Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm trying to build the rpms for RH9,
I downloaded the srpm for RH9 but I'm stuck on these errors:
RH9 is not a supported platform by RedHat or PGDG.
Attempt a:
# rpmbuild --rebuild postgresql-8.0.7-1PGDG.src.rpm
Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
An idea arising in chat with Joshua Drake: the retargetting code, if it
turns out to work and not be excessively expensive, could also be useful
to implement a server-side connection pooling of sorts: the postmaster
could keep
Simon Riggs [EMAIL PROTECTED] writes:
I think it would be useful to think about exactly what type of
query/activity we are looking to improve the performance on. That way we
can understand the benefit of this proposal and take some baseline
measurements to analyse what is happening for those
On Tue, 2006-04-11 at 07:47, Myron Scott wrote:
client
or additional processing. Am I missing something in this analysis?
I've attached my dtrace script.
To answer my own question, I suppose my processors are
relatively slow compared to most setups.
Myron Scott
Hi,
I'm trying to add fields to pg_database in the system catalog. As long
as I add fixed-size fields before the VAR LENGTH ones, that's all fine.
But adding a VAR LENGTH (text) field initdb fails at: copying template1
to template0. The child process 'postgres' fails with signal 11. Strange
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
An idea arising in chat with Joshua Drake: the retargetting code, if it
turns out to work and not be excessively expensive, could also be useful
to implement a server-side
Greg Stark wrote:
Even on Solaris I'm sure parsing and preparing plans for all the queries,
building up the system table cache for all the objects in the database, and so
on are much much more expensive than fork(). I wouldn't be surprised if even
on windows it was still a pretty close race.
On 4/11/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
I've only added the fields in include/catalog/pg_database.h. Do I need
to fiddle other places?
Make sure you updated Natts_pg_database, the bootstrap DATA line, and
the stuff in src/backend/commands/dbcommands.c.
Other than that I don't
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think it would be useful to think about exactly what type of
query/activity we are looking to improve the performance on. That way we
can understand the benefit of this proposal and take some baseline
measurements to analyse what is
On Tue, 2006-04-11 at 14:07 -0400, Jonah H. Harris wrote:
Make sure you updated Natts_pg_database, the bootstrap DATA line, and
the stuff in src/backend/commands/dbcommands.c.
dbcommands.c was the missing peace, thank you!
Markus
---(end of
On 4/11/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
dbcommands.c was the missing peace, thank you!
No problemo :)
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
---(end of broadcast)---
TIP 6: explain
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/11/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
I've only added the fields in include/catalog/pg_database.h. Do I need
to fiddle other places?
Make sure you updated Natts_pg_database, the bootstrap DATA line, and
the stuff in
On 4/11/06, Tom Lane [EMAIL PROTECTED] wrote:
Good ways to answer this sort of question are:
1. Grep for references to some of the existing fields in the same catalog.
2. Look at the CVS diff for previous commits that added fields to the
same catalog.
True, true.
--
Jonah H. Harris,
Joshua D. Drake [EMAIL PROTECTED] writes:
Well I am go out on a limb here and gather to guess that sequential scans and
index scans are still very relevant because the CPU could be bound by the scan
(either one) based on the type of query being performed.
This doesn't really have anything
Hi pg Hackers,
First I using PostgreSQL for four year now, and I would like to thank you all for your work :)
I'm currently doing a study about the Open Source database.
So I'm testing some of the contrib modules like dblink, tsearch, admin81 and I was using postgis a lot in a previous life.
[ FreeBSD email list removed.]
I totally agree, and have added the attached documentation patch to
recommend using different users in FreeBSD jails.
---
Stephen Frost wrote:
-- Start of PGP signed section.
* Marc G.
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
para
+ If running in FreeBSD jails by enabling applicationsysconf/'s
+ literalsecurity.jail.sysvipc_allowed/,
applicationpostmaster/s
+ running in different jails should be run by different operating
system
+
Stephen Frost wrote:
-- Start of PGP signed section.
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
para
+ If running in FreeBSD jails by enabling applicationsysconf/'s
+ literalsecurity.jail.sysvipc_allowed/,
applicationpostmaster/s
+ running in
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
I updated the wording to say 'non-root users':
If running in FreeBSD jails by enabling applicationsysconf/'s
literalsecurity.jail.sysvipc_allowed/, applicationpostmaster/s
running in different jails should be run by
Stephen Frost wrote:
-- Start of PGP signed section.
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
I updated the wording to say 'non-root users':
If running in FreeBSD jails by enabling applicationsysconf/'s
literalsecurity.jail.sysvipc_allowed/,
On Mon, Apr 10, 2006 at 10:44:15AM +0100, Richard Huxton wrote:
Bruce Momjian wrote:
* Allow EXPLAIN output to be more easily processed by scripts
Can I request an extension/additional point?
* Design EXPLAIN output to survive cut paste on mailing-lists
Being able to paste into a
On Mon, Apr 10, 2006 at 11:02:50PM -0700, David Fetter wrote:
On Tue, Apr 11, 2006 at 12:47:03AM -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What does enabling plpgsql do via access that you can't just do from an
SQL query?
SQL isn't Turing-complete
With all
Jim C. Nasby [EMAIL PROTECTED] writes:
Rather than debate how turing complete SQL is, look at the real issue:
is a compromised system with plPGSQL installed more dangerous than a
compromised system without plPGSQL. As far as I can see, it's not.
You're disregarding the possibility that plpgsql
On Mon, Apr 10, 2006 at 12:02:56PM -0700, Luke Lonergan wrote:
Hannu,
On 4/10/06 2:23 AM, Hannu Krosing [EMAIL PROTECTED] wrote:
The cost of fetching a page from the OS is not really much of an
overhead,
Have you tested this ?
I have - the overhead of fetching a page from Linux
On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Rather than debate how turing complete SQL is, look at the real
issue: is a compromised system with plPGSQL installed more
dangerous than a compromised system without plPGSQL. As far as I
can
On Mon, Apr 10, 2006 at 05:22:13PM +0800, Qingqing Zhou wrote:
Markus Schiltknecht [EMAIL PROTECTED] wrote
Hi Qingqing,
As Tom pointed out, without big change, a backend on database D1 can't
connect to D2. This is because to connect to a database, we need to
initialize a lot of
On Mon, Apr 10, 2006 at 01:36:45PM -0400, Alvaro Herrera wrote:
Markus Schiltknecht wrote:
On Mon, 2006-04-10 at 17:22 +0800, Qingqing Zhou wrote:
Check the code InitPostgres(). These global varaibles are scattered in
many
places, so I am not sure if it is easy to write clean code to
David Fetter [EMAIL PROTECTED] writes:
On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
More realistically, though, the theoretical point that you can do
arbitrary calculations by turning loops into recursive SQL functions
is mostly just theoretical, and the reason is that you won't
On Tue, Apr 11, 2006 at 05:01:17PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
More realistically, though, the theoretical point that you can do
arbitrary calculations by turning loops into recursive SQL
functions
David Fetter [EMAIL PROTECTED] writes:
I don't get your not getting this 'cause you're a very smart guy. Are
you under the impression that an attacker will stop because he has to
try a few times?
No, I'm saying that having access to a PL renders certain classes of
attacks significantly more
On Tue, 11 Apr 2006, Tom Lane wrote:
We could maybe change things so that the finalfunc isn't run unless the
result value is actually demanded in the SELECT list or HAVING clause,
but for 99.99% of applications checking that would be a waste of cycles,
so I'm disinclined to do it.
I'm lacking
Are there are more possibilities for some bug in the plpgsql engine to allow an
exploit: actually changing the stack through a buffer overflow, or a bug in an
intrinsic function, or allowing an injection that crosses some privilege
boundary, via someone else's EXECUTE?
It's a lot easier to
That's only going to be true for very high end systems with multiple raid
controllers and dozens of spindles.
Not true. I have a system right now that would benifit. My database is
only 500 megs and I have 2 gig of ram and two processors... I only have
a raid 1, but that is o.k. because most
On Tue, 11 Apr 2006, Joshua D. Drake wrote:
Can you guarantee unequivocally that there are absolutely not security
issues in plpgsql?
Can you guarantee unequivocally that there are absolutely not security issues
in PostgreSQL?
No, but does that mean we should increase the potential by
On Tue, Apr 11, 2006 at 11:22:53PM +0200, Andreas Tille wrote:
On Tue, 11 Apr 2006, Tom Lane wrote:
We could maybe change things so that the finalfunc isn't run unless the
result value is actually demanded in the SELECT list or HAVING clause,
but for 99.99% of applications checking that
On Tue, Apr 11, 2006 at 05:20:02PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I don't get your not getting this 'cause you're a very smart guy.
Are you under the impression that an attacker will stop because he
has to try a few times?
No, I'm saying that having access
Andreas Tille [EMAIL PROTECTED] writes:
I'm lacking experience here so I perfectly trust you that keeping
the default case as it is. The question is, whether adding an
option to change the default might make sense.
I don't think so. The current API contract for aggregate functions is
that
Tom Lane wrote:
In the end it's only one small component of security, but any security
expert will tell you that you take all the layers of security that you
can get. If you don't need a given bit of functionality, it shouldn't
get installed.
I think any security expert would say that if let
No, but does that mean we should increase the potential by adding in
something that not everyone that runs PostgreSQL actually uses?
Using this argument I could say that we don't need primary keys, foreign
keys, views or rules. Especially the latter 3 ;).
Sincerely,
Joshua D. Drake
On 2006-04-11, Tom Lane [EMAIL PROTECTED] wrote:
David Fetter [EMAIL PROTECTED] writes:
I don't get your not getting this 'cause you're a very smart guy. Are
you under the impression that an attacker will stop because he has to
try a few times?
No, I'm saying that having access to a PL
On 2006-04-11, Tom Lane [EMAIL PROTECTED] wrote:
More realistically, though, the theoretical point that you can do
arbitrary calculations by turning loops into recursive SQL functions is
mostly just theoretical,
It's not at all theoretical. The very practical problem of trying to write
code
Martijn van Oosterhout kleptog@svana.org writes:
--f2QGlHpHGjS2mn6Y
On Tue, Apr 11, 2006 at 11:22:53PM +0200, Andreas Tille wrote:
I'm lacking experience here so I perfectly trust you that keeping
the default case as it is. The question is, whether adding an
option to change the default
On Tue, 2006-04-11 at 17:20 -0400, Tom Lane wrote:
No, I'm saying that having access to a PL renders certain classes of
attacks significantly more efficient. A determined attacker with
unlimited time may not care, but in the real world, security is
relative.
That's a fair point.
Perhaps a
On Tue, 11 Apr 2006, Joshua D. Drake wrote:
No, but does that mean we should increase the potential by adding in
something that not everyone that runs PostgreSQL actually uses?
Using this argument I could say that we don't need primary keys, foreign
keys, views or rules. Especially the
On Tue, 2006-04-11 at 19:35 -0300, Marc G. Fournier wrote:
On Tue, 11 Apr 2006, Joshua D. Drake wrote:
No, but does that mean we should increase the potential by adding in
something that not everyone that runs PostgreSQL actually uses?
Using this argument I could say that we don't
On Tue, Apr 11, 2006 at 03:43:56PM -0700, Joshua D. Drake wrote:
On Tue, 2006-04-11 at 19:35 -0300, Marc G. Fournier wrote:
On Tue, 11 Apr 2006, Joshua D. Drake wrote:
No, but does that mean we should increase the potential by adding in
something that not everyone that runs
Anybody on this list hear/opine anything pf the GPUSort project for postgresql?
I'm working on a radix-sort subcase for tuplesort, and there are similarities.
http://www.andrew.cmu.edu/user/ngm/15-823/project/
--
Engineers think that equations approximate reality.
Physicists think that reality
That's a fair point.
Perhaps a compromise would be to enable pl/pgsql by default, but not
grant the USAGE privilege on it. This would allow superusers to define
pl/pgsql functions without taking any additional steps. Non-superusers
could be given access to pl/pgsql via a simple GRANT --
2006/4/8, Tom Lane [EMAIL PROTECTED]:
I've never understood what the conceptual model is for Oracle's rownum.
Where along the SQL operational pipeline (FROM / WHERE / GROUP BY /
aggregate / compute output columns / ORDER BY) is it supposed to be
computed? To be useful for the often-requested
Neil,
Perhaps a compromise would be to enable pl/pgsql by default, but not
grant the USAGE privilege on it. This would allow superusers to define
pl/pgsql functions without taking any additional steps. Non-superusers
could be given access to pl/pgsql via a simple GRANT -- either for all
On Tue, Apr 11, 2006 at 04:02:07PM -0700, Mischa Sandberg wrote:
Anybody on this list hear/opine anything pf the GPUSort project for
postgresql? I'm working on a radix-sort subcase for tuplesort, and there
are similarities.
http://www.andrew.cmu.edu/user/ngm/15-823/project/
I've heard it
68 matches
Mail list logo
