Bruce,
Are you still working on completing this?
Attached is my latest rewrite of this patch.
Basically, it adds RETURNING to INSERT/UPDATE/DELETE, and allows
arbitrary expressions.
I'm still not sure how to handle DELETE ... USING and UPDATE ... FROM as
I don't see a way to project the
Alvaro Herrera wrote:
I still haven't added custom cost-based delays, but I don't see that as
a showstopper for removing it. I just went through the CVS log and I
don't see anything else that applies.
I think you should at least add an autovacuum specific value for
vacuum_cost_delay because
David Fetter wrote:
*** 716,724
listitem
para
! In the current implementation, if you are fetching or returning
! very large data sets, you should be aware that these will all go
! into memory.
/para
/listitem
/itemizedlist
--- 766,776
Magnus Hagander wrote:
Seems it's dead on the buildfarm box as well:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2005-07-30%20
01:00:01
From what I can tell, the recent patch for O_DIRECT broke it.
OK, fix attached, and some macro cleanup too.
--
Bruce Momjian
Per recent discussion, here is yet another updated version of the
instrumentation patch. Changes:
* Added guc option disable_remote_admin, that disables any write
operations (write, unlink, rename) even for the superuser. Set as
PGC_POSTMASTER so it cannot be changed remotely.
I put this under
Michael Paesold [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I still haven't added custom cost-based delays, but I don't see that as
a showstopper for removing it. I just went through the CVS log and I
don't see anything else that applies.
I think you should at least add an autovacuum
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I still haven't added custom cost-based delays, but I don't see that as
a showstopper for removing it. I just went through the CVS log and I
don't see anything else that applies.
I think you should at
I just realised the entry for pg_file_rename is duplicated in pg_proc.h.
Unless someone can say it's a good thing (it was in the original
patch..), please remove one of those entries before applying. It breaks
the opr_sanity test.
//Magnus
-Original Message-
From: [EMAIL PROTECTED]
Patch applied. Thanks.
---
Michael Glaesemann wrote:
Please find attached diffs for documentation and simple regression
tests for the new interval-day changes. I added tests for
justify_hours() and justify_days()
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I think you should at least add an autovacuum specific value for
vacuum_cost_delay because it turns cost-based vacuum delay on or off.
I am thinking we should move ahead with what we have now, suggest the
work-arounds, and
Bruce Momjian pgman@candle.pha.pa.us writes:
I think you should at least add an autovacuum specific value for
vacuum_cost_delay because it turns cost-based vacuum delay on or off.
I am thinking we should move ahead with what we have now, suggest the
work-arounds, and thensee what use-cases
Magnus Hagander [EMAIL PROTECTED] writes:
Per recent discussion, here is yet another updated version of the
instrumentation patch. Changes:
* Added guc option disable_remote_admin, that disables any write
operations (write, unlink, rename) even for the superuser. Set as
PGC_POSTMASTER so it
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Per recent discussion, here is yet another updated version of the
instrumentation patch. Changes:
* Added guc option disable_remote_admin, that disables any write
operations (write, unlink, rename) even for the superuser. Set as
Magnus Hagander wrote:
Per recent discussion, here is yet another updated version of the
instrumentation patch. Changes:
* Added guc option disable_remote_admin, that disables any write
operations (write, unlink, rename) even for the superuser. Set as
PGC_POSTMASTER so it
Also, as I already said, marking it as PGC_POSTMASTER is
simply not
adequate security. Once we have some sort of remote
admin feature,
I would expect it to support adjustment of even postmaster-level
options (this would mean forcing a database restart of
course) ---
you
Updated patch applied. Thanks.
---
Alvaro Herrera wrote:
Hackers,
Subject says it all. Please review the grammar ...
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
Et put se mouve (Galileo Galilei)
--
Bruce
I think any secure solution is going to have to block all write
access to postgresql.conf, and that includes all the COPY
TO and all
the untrusted languages.
Exactly. But we won't get that for 8.1. So for now, we
block all write
access through *new* functions, per the let's
Magnus Hagander wrote:
I think any secure solution is going to have to block all write
access to postgresql.conf, and that includes all the COPY
TO and all
the untrusted languages.
Exactly. But we won't get that for 8.1. So for now, we
block all write
access through
Magnus Hagander [EMAIL PROTECTED] writes:
For the long term I was thinking something like restrict_superuser,
which would disable both read and write, and COPY, and untrusted PL
creation, etc, etc. But that's not for 8.1.
That's exactly what I'm talking about.
Also, as I already said,
On Sat, Jul 30, 2005 at 11:46:37AM -0400, Bruce Momjian wrote:
Updated patch applied. Thanks.
Huh, something is very wrong with the markup:
http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-vacuum.html
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
Having your biases confirmed
Once we have a real remote admin API, it becomes an
argument, and it
will have to be adjusted. But we don't have that today, and
I see no
need to create a new guc category just for this. After all, some of
these functions will probably go away completely once we
have such an
On Sat, Jul 30, 2005 at 10:57:15AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I think you should at least add an autovacuum specific value for
vacuum_cost_delay because it turns cost-based vacuum delay on or off.
I am thinking we should
-Original Message-
From: [EMAIL PROTECTED] on behalf of Tom Lane
Sent: Sat 7/30/2005 4:58 PM
To: Magnus Hagander
Cc: PostgreSQL-patches
Subject: Re: [PATCHES] Updated instrumentation patch
None of these functions are getting into 8.1 anyway; we should be
designing the long-term
Alvaro Herrera wrote:
On Sat, Jul 30, 2005 at 11:46:37AM -0400, Bruce Momjian wrote:
Updated patch applied. Thanks.
Huh, something is very wrong with the markup:
http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-vacuum.html
OK, fixed. link and linkend should not both be used.
--
On Sat, Jul 30, 2005 at 12:06:11PM -0400, Alvaro Herrera wrote:
On Sat, Jul 30, 2005 at 11:46:37AM -0400, Bruce Momjian wrote:
Updated patch applied. Thanks.
Huh, something is very wrong with the markup:
http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-vacuum.html
This should fix
On Sat, Jul 30, 2005 at 01:04:28PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
On Sat, Jul 30, 2005 at 11:46:37AM -0400, Bruce Momjian wrote:
Updated patch applied. Thanks.
Huh, something is very wrong with the markup:
OK, I backed out my fix and applied your, and tested the output.
---
Alvaro Herrera wrote:
On Sat, Jul 30, 2005 at 12:06:11PM -0400, Alvaro Herrera wrote:
On Sat, Jul 30, 2005 at 11:46:37AM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
Please find attached diffs for documentation and simple regression
tests for the new interval-day changes.
The buildfarm results suggest that justify_days is broken in the
integer-datetimes case, eg from panda:
***
Here is promised documentation.
Be warned that both my writing skills and my english are far from good :)
--
Regards
Petr Jelinek (PJMODOS)
Index: doc/src/sgml/catalogs.sgml
===
RCS file:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
It was agreed earlier that this should be saved for 8.2, I believe.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
On Sat, Jul 30, 2005 at 09:47:58AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
You have rolled 2 problems into one - spi_query+spi_fetchrow does not
address the issue of returning large data sets.
Suggest instead:
[suggestion]
Revised patch attached. Thanks for catching this
Bruce Momjian pgman@candle.pha.pa.us writes:
I have worked over your patch and I think it is ready for application.
I've made another pass over this and should be able to commit tomorrow
(I'm about to knock off for today, and ran out of time to test
pg_dumpall). One thing I changed was that it
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Titus von Boxberg wrote:
Tom Lane schrieb:
Titus von Boxberg [EMAIL PROTECTED] writes:
It works for me if we
33 matches
Mail list logo
