Hi,
I'm testing HOT patches, applying to CVS HEAD.
http://archives.postgresql.org/pgsql-patches/2007-05/msg00065.php
I found a few issues in the patch. Some of them might already have
been fixed, but anyway I'll report them for information.
I don't see any problems excluding the following in
With the assumption that the above that one refered to the PG_CONFIG
macro definition in Makefile.global. As existing extension makefiles do
not defined PG_CONFIG, relying on one would break them wrt future
releases?
Ah, I see. I was thinking in terms of breaking them intentionally ;-)
On Saturday 23 June 2007 05:56, Magnus Hagander wrote:
Magnus Hagander wrote:
On Thu, Jun 07, 2007 at 01:12:06PM +0200, Peter Eisentraut wrote:
Magnus Hagander wrote:
Is this script in CVS somewhere? I know it's not in the main backend
repo.
Most of what these scripts have done in the
Tom Lane [EMAIL PROTECTED] writes:
For the moment, lie about WITH's status in the table so it will still get
quoted --- this is because of the expectation that WITH will become reserved
when the SQL recursive-queries patch gets done.
Out of curiosity I'm checking what consequences some other
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
For the moment, lie about WITH's status in the table so it will still get
quoted --- this is because of the expectation that WITH will become reserved
when the SQL recursive-queries patch gets done.
Out of curiosity
Hello,
triggers in PostgreSQL are cascading by default. From section 34.1.
of the 8.2 manual:
If a trigger function executes SQL commands then these commands
may fire triggers again. This is known as cascading triggers.
There is no direct limitation on the number of cascade levels.
Fabien COELHO [EMAIL PROTECTED] writes:
But ISTM that the remedy (breaking all past makefiles for all extensions)
is not worth the issue.
A better documentation, and possibly following your suggestion with an
explicit PG_CONFIG in contrib makefiles, but without breaking existing
extensions
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
For the moment, lie about WITH's status in the table so it will still get
quoted --- this is because of the expectation that WITH will become reserved
when the SQL recursive-queries patch gets done.
Out of curiosity
Let's add the ifndef to Makefile.global and change the
existing extension makefiles to
PG_CONFIG := pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
Any objections?
Maybe the := for pg_config is not necessary, = is fine for a
simple string definition ?
Gregory Stark wrote:
I'm thinking it may make sense to lie about all of these in quote_identifier
so that someone who upgrades from 8.2 to 8.3 can then upgrade to 8.4. If we
add reserved words in one step then there's no way to upgrade except to rename
things before dumping. Any comments?
On Jun 26, 2007, at 10:04 , Chris Mair wrote:
Hello,
On the italian list we're discussing a case were a user reportedly
worked around this (i.e. got rid of unwanted cascading calls) by
writing an on insert trigger procedure something on the lines of:
ALTER TABLE tab DISABLE TRIGGER USER;
Chris Mair [EMAIL PROTECTED] writes:
On the italian list we're discussing a case were a user reportedly
worked around this (i.e. got rid of unwanted cascading calls) by
writing an on insert trigger procedure something on the lines of:
ALTER TABLE tab DISABLE TRIGGER USER;
-- do more
Tom,
We do not patch those files; the update technique is download, untar,
commit, and there's really no point in doing it except when a release
is imminent. See src/timezone/README and src/tools/RELEASE_CHANGES.
Do we have anything else pending? We may need to do a release just for this
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm confused. Won't pg_dump quote the keywords it knows its postgres
version will need quoted? We can't expect it to have knowledge of future
requirements for quoting, unless someone really does invent time travel
(in which case someone could just go
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I'm thinking it may make sense to lie about all of these in quote_identifier
so that someone who upgrades from 8.2 to 8.3 can then upgrade to 8.4. If we
add reserved words in one step then there's no way to upgrade except to
Gregory Stark wrote:
It may still be worth telling one version of Postgres about anticipated
keywords prior to a release which adds them so that people who don't follow
instructions and try a dump generated with an old pg_dump have a fighting
chance. Besides, what's a person to do if they have
Tom Lane [EMAIL PROTECTED] writes:
Yeah. I'm disinclined to pre-emptively quote things for pie-in-the-sky
patches. WITH is already a grammar keyword, so it's not a big deal to
tweak things to quote it, but adding a dozen keywords that have zero
functionality in the grammar is another thing
Josh Berkus [EMAIL PROTECTED] writes:
Do we have anything else pending? We may need to do a release just
for this timezone update if we don't have anything else within a few
weeks. We have a fair number of users in NZ.
I'd kinda like to get 8.3beta1 out the door before we expend time on
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Also, the fact that this particular form of the grammar requires
reserving the keywords does not prove that there is no way to have the
features without that. I'd want to see us try a little harder first.
At least
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
The normal build process for any open-source package is
./configure
make
sudo make install
... now what? OK, time to read the manual ...
Since they
Andrew Hammond [EMAIL PROTECTED] writes:
On 6/25/07, Tom Lane [EMAIL PROTECTED] wrote:
+1 on having such a discussion in the manual (someone else suggested
that already IIRC). But I'm not seeing what a configure flag brings
to the party.
Like Andrew Sullivan said above, if we want to
On Tue, Jun 26, 2007 at 03:08:59PM -0400, Tom Lane wrote:
It still wouldn't make us secure by default. Not unless you propose
to actually change the default.
Perhaps I wasn't clear enough, but the suggestion I made (for
something I actually don't care about, I hasten to add again) was
that the
Tom Lane [EMAIL PROTECTED] writes:
As for inside connections, secure is still largely dependent on what your
threat model is.
Indeed I think closing Postgres to access based on the unix userid of the
connecting user is the wrong threat model. That's basically saying you don't
trust the unix
I just had an epiphany, I think.
As I wrote in the LDC discussion,
http://archives.postgresql.org/pgsql-patches/2007-06/msg00294.php
if the bgwriter's LRU-cleaning scan has advanced ahead of freelist.c's
clock sweep pointer, then any buffers between them are either clean,
or are pinned and/or
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have gotten distracted :-(
The only problem with
On Tue, 26 Jun 2007, Tom Lane wrote:
It should try to be behind the sweep, ie, so far ahead that it's lapped
the clock sweep and is trailing along right behind it, cleaning buffers
immediately after their usage_count falls to zero. All the rest of the
buffer arena is either clean or has
* Tom Lane ([EMAIL PROTECTED]) wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have gotten
Fabien COELHO [EMAIL PROTECTED] writes:
Some documentation (not just code) update seems important to me.
Agreed. I added this to xfunc.sgml's discussion of PGXS makefiles:
Index: doc/src/sgml/xfunc.sgml
===
RCS file:
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have gotten distracted
Greg Smith [EMAIL PROTECTED] writes:
Unless someone else has a burning desire to implement Tom's idea faster
than me, I should be to build this new implementation myself in the next
couple of days.
Sure, go for it. I'm going to work next on committing the LDC patch,
but I'll try to avoid
Tom Lane wrote:
I just had an epiphany, I think.
As I wrote in the LDC discussion,
http://archives.postgresql.org/pgsql-patches/2007-06/msg00294.php
if the bgwriter's LRU-cleaning scan has advanced ahead of freelist.c's
clock sweep pointer, then any buffers between them are either clean,
or are
Greg Smith wrote:
I broke Itagaki-san's patch into two pieces when I was doing the review
cleanup on it specifically to make it easier to tinker with this part
without losing some of its other neat features. Heikki, did you do
anything with that LRU adjustment patch since I sent it out:
Gregory Stark wrote:
All that really has to happen is that dblink should by default not be callable
by any user other than Postgres. DBAs should be required to manually run
GRANT EXECUTE ON dblink_connect(text) TO public; if that's what he wants.
That serves the purpose of making PG secure by
* Florian Pflug ([EMAIL PROTECTED]) wrote:
Gregory Stark wrote:
All that really has to happen is that dblink should by default not be
callable
by any user other than Postgres. DBAs should be required to manually run
GRANT EXECUTE ON dblink_connect(text) TO public; if that's what he wants.
On Tue, 26 Jun 2007, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Tom Lane wrote:
In fact, the notion of the bgwriter's cleaning scan being in front of
the clock sweep is entirely backward. It should try to be behind the
sweep, ie, so far ahead that it's lapped the clock sweep and is trailing
along right
Jeremy Drake wrote:
2. If you cannot tell what process is connecting on a local socket (which
I suspect you cannot portably),
See ident_unix() in hba.c.
It might not be 100% portable but I think it's fairly close for platforms
that actually have unix sockets.
cheers
andrew
On Tue, 26 Jun 2007, Heikki Linnakangas wrote:
How much of the buffer cache do you think we should try to keep
clean? And how large a percentage of the buffer cache do you think have
usage_count=0 at any given point in time?
What I discovered is that most of the really bad checkpoint pause
On Wed, 27 Jun 2007, ITAGAKI Takahiro wrote:
It might be good to use statistics information about buffer usage to
modify X runtime.
I have a complete set of working code that tracks buffer usage statistics
as the background writer scans, so that it has an idea what % of the
buffer cache is
On Tue, 26 Jun 2007, Heikki Linnakangas wrote:
I haven't worked on [Greg's] patch. I started looking at this, using
Itagaki's patch as the basis.
The main focus of how I reworked things was to integrate the whole thing
into the pg_stat_bgwriter mechanism. I thought that made the
41 matches
Mail list logo
