Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
Andrew Dunstan wrote:
I spent months on a working party on these and similar issues a few
years back, in a commercial setting. One of the big issues is when you
start tracking something. Bugs are a pretty simple case. Features are
much harder to handle. Someone comes up with an idea. There is
On Sep 4, 2006, at 12:44 , Tom Lane wrote:
OK, so if everyone is leaning to #3, the name game remains to be
played.
Do we all agree on this:
x @ y means x contains y
x @ y means x is contained in y
Are we all prepared to sign a solemn oath to commit hara-kiri if we
invent a
On Sun, Sep 03, 2006 at 08:30:13PM -0700, Neil Conway wrote:
Martijn van Oosterhout said:
Ok, it looks like pages can be arranged hierarchically.
Well, a prefix like Todo: is not the incantation one needs to use to
arrange pages in hierarchies. You probably want / to indicate a subpage:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Browne
Sent: 04 September 2006 03:55
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] gBorg status?
The fact that it has been out for a week, without any public comment
On 2006-09-04, Tom Lane [EMAIL PROTECTED] wrote:
OK, so if everyone is leaning to #3, the name game remains to be played.
Do we all agree on this:
x @ y means x contains y
x @ y means x is contained in y
While I suggested something like those, I would also suggest that the
Tom Lane ha scritto:
OK, so if everyone is leaning to #3, the name game remains to be played.
Do we all agree on this:
x @ y means x contains y
x @ y means x is contained in y
Are we all prepared to sign a solemn oath to commit hara-kiri if we
invent a new datatype that gets
On Mon, Sep 04, 2006 at 11:12:13AM +0700, Jeroen T. Vermeulen wrote:
As I've said before, all this falls down if there is a significant cost to
keeping one or two extra plans per prepared statement. You mentioned
something about tracking plans. I don't know what that means, but it
sounded
Matteo Beccati [EMAIL PROTECTED] writes:
Tom Lane ha scritto:
OK, so if everyone is leaning to #3, the name game remains to be played.
Do we all agree on this:
x @ y means x contains y
x @ y means x is contained in y
Are we all prepared to sign a solemn oath to commit hara-kiri
GRANT role [, ...]
TO { username | GROUP groupname | PUBLIC } [, ...] [ WITH
ADMIN
OPTION ]
It doesn't say that anymore:
http://archives.postgresql.org/pgsql-committers/2006-
08/msg00034.php
Pfft. I need to remember to check development docs as well :-) sorry
about the noise.
On Fri, 2006-08-18 at 08:52 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2006-08-17 at 19:11 -0400, Tom Lane wrote:
I noticed a minor annoyance while testing: when the system is completely
idle, you get a forced segment switch every checkpoint_timeout seconds,
even
Right now, the release notes show a list of all the significant
items in each release, but it isn't available until the release,
and it isn't complete (because it would be unreadable by ordinary
users). And there is no tracking of individual items in progress
except by individual developers.
Gregory Stark [EMAIL PROTECTED] writes:
Matteo Beccati [EMAIL PROTECTED] writes:
Tom Lane ha scritto:
x @ y means x is contained in y
ltree @ ltree
If you consider ltree entries to be sets containing all their children then
those sound consistent.
Oops, sorry for the noise.
Am Montag, 4. September 2006 03:57 schrieb Andrew Dunstan:
Ah! Thanks! What had failed for me was just running with
/path/to/old/autoconf - this one works however. Strange that a config
package can't work out where its own installed files are.
I had that fixed in Autoconf a while back for this
Am Montag, 4. September 2006 04:06 schrieb Andrew Dunstan:
Patch attached - seems to work on my FC5/x86_64 box. Also contains the
OSX fix backported. Not sure that it qualifies as small though :-)
It looks pretty scary to me.
Didn't we say once that we don't want to backport fixes for
Am Montag, 4. September 2006 04:10 schrieb Bruce Momjian:
Are you saying you don't like the patch,
That's it.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Folks,
Because of a broken wrist, I won't be able to type much.
1. Is there any discussion being going to regrading the:
%Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
2. I took a brief look at gramm.y, would it be okay to create a new
section like
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The pg_regress.sh has this code that
should create it:
outputdir=results/
if [
x @ y means x is contained in y
ltree @ ltree
If you consider ltree entries to be sets containing all their
children
then those sound consistent.
Now we get to decide whether @ was better than the now proposed @
:-)
I like @. (or we stay clear by using the inet ops)
Am Montag, 4. September 2006 10:23 schrieb Albe Laurenz:
This is just a 'one line' change in the documentation of
the --with-ldap flag of ./configure
Well, if you want to link from the configure option to the place where the
feature is explained, then that should be done consistently for all
With this approach, you still have to update your rules if
you want to support RETURNING on your views --- but if you
don't update them, you don't have a security hole. Basically
the standard setup for an updatable view would use
ON INSERT DO INSTEAD INSERT INTO ... RETURNING ...
Michael Meskes [EMAIL PROTECTED] writes:
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The pg_regress.sh has this code that
Matteo Beccati [EMAIL PROTECTED] writes:
Tom Lane ha scritto:
OK, so if everyone is leaning to #3, the name game remains to be played.
Do we all agree on this:
x @ y means x contains y
x @ y means x is contained in y
Does this mean that also contrib/ltree operators will likely change for
Peter Eisentraut wrote:
Am Montag, 4. September 2006 10:23 schrieb Albe Laurenz:
This is just a 'one line' change in the documentation of
the --with-ldap flag of ./configure
Well, if you want to link from the configure option to the place where
the
feature is explained, then that should be
Michael Glaesemann [EMAIL PROTECTED] writes:
Assuming the meaning of contains and is contained in is inclusive
(rather than strict), then we'd have
a = b : a contains b
a = b : a is contained by b
I don't think we can consider that, because we already have and
operators meaning is left
i am looking at some corner case which might also cause troubles for
other people.
consider the following:
SELECT some_timestamp::date FROM very_large_table GROUP BY
some_timestamp::date
my very_large_table is around 1billion entries.
the problem is: the planner has a problem here as it
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2006-09-04, Tom Lane [EMAIL PROTECTED] wrote:
Do we all agree on this:
x @ y means x contains y
x @ y means x is contained in y
While I suggested something like those, I would also suggest that the
existing operators for inet/cidr be taken
On Mon, Sep 04, 2006 at 12:06:02AM -0400, Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
There's a lot of duplicate code in ecpg.
No kidding :-(. The parser is bad enough but the datatype library is
an order of magnitude worse. I don't have a great solution at hand
though.
Hans-Juergen Schoenig [EMAIL PROTECTED] writes:
consider the following:
SELECT some_timestamp::date FROM very_large_table GROUP BY
some_timestamp::date
my very_large_table is around 1billion entries.
the problem is: the planner has a problem here as it is taking the
(correct)
Michael Meskes [EMAIL PROTECTED] writes:
On Mon, Sep 04, 2006 at 12:06:02AM -0400, Tom Lane wrote:
The backend utils/adt/ code gets to rely on the backend's
error handling and memory management protocols, which I surely do
not propose to remove, but how could we keep common sources when
[EMAIL PROTECTED] (Peter Eisentraut) writes:
sslinfo contrib module - information about current SSL certificate
Author: Victor Wagner [EMAIL PROTECTED]
It was premature to add this: Bruce is still trying to get a copyright
assignment out of the author.
regards, tom lane
Michael Glaesemann [EMAIL PROTECTED] writes:
[ [EMAIL PROTECTED] wrote: ]
x = y x contains y
x y x strictly contains y
x = y x is contained in y
x y x is strictly contained in y
(I'd be fine with Andrew's versions. I probably picked them up from
his ip4r code, now that I think
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of
hi tom ...
i thought about creating an index on the expression but the problem
is that this is hardly feasable.
in 8.0 (what i have here) this would block the table and i would run
out of disk space as well. this is a 600 gb biest :(
what about the planner approach?
this would solve the
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, I have a problem with the README copyright:
+sslinfo - information about current SSL certificate for PostgreSQL
+==
+Copyright (c) 2006 Cryptocom LTD
Speaking of
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
one objects, I'll
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sun, September 3, 2006 23:52, Tom Lane wrote:
What exactly do you mean by optimize away a parameter? The way you
described the mechanism, there are no parameters that are optimized
away, you've merely adjusted selectivity predictions using some
On Sat, 2006-08-26 at 22:46 -0400, Jonah H. Harris wrote:
On 8/26/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Actually I was thinking in the design rather than the code ...
Doh! We hadn't posted the design just yet. Let me write him and see
where he's at and we'll throw something together
On Mon, Sep 04, 2006 at 17:19:37 +0200,
Hans-Juergen Schoenig [EMAIL PROTECTED] wrote:
i thought about creating an index on the expression but the problem
is that this is hardly feasable.
in 8.0 (what i have here) this would block the table and i would run
That may be hard to deal
On Sep 4, 2006, at 7:04 PM, Bruno Wolff III wrote:
On Mon, Sep 04, 2006 at 17:19:37 +0200,
Hans-Juergen Schoenig [EMAIL PROTECTED] wrote:
i thought about creating an index on the expression but the problem
is that this is hardly feasable.
in 8.0 (what i have here) this would block the
Bruce Momjian [EMAIL PROTECTED] writes:
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
This version was withdrawn by the author for rework, no?
regards, tom lane
---(end of
I've gotten a little tired of reading reports that ILIKE doesn't work as
expected in UTF8. The problem is that iwchareq() in like.c is several
bricks shy of a load, as noticed e.g. here
http://archives.postgresql.org/pgsql-bugs/2005-10/msg1.php
I looked a little bit at making iwchareq less
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the if no
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, I have a problem with the README copyright:
+sslinfo - information about current SSL certificate for PostgreSQL
+==
+Copyright (c) 2006 Cryptocom LTD
Tom,
On 9/4/06, Tom Lane [EMAIL PROTECTED] wrote:
I propose that for ILIKE in multibyte encodings, we just pass the strings
through lower() and then use the normal LIKE code. This will be a bit
slower than what we do now, but as a wise man once said, code can be
arbitrarily fast if it needn't
Tom Lane wrote:
[EMAIL PROTECTED] (Peter Eisentraut) writes:
sslinfo contrib module - information about current SSL certificate
Author: Victor Wagner [EMAIL PROTECTED]
It was premature to add this: Bruce is still trying to get a
copyright assignment out of the author.
Another one of those
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speaking of which, has anyone checked the copyrights on the other
proposed-for-inclusion contrib modules?
Uh, what other ones? I see none in the patch queue.
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00050.php
On Mon, Sep 04, 2006 at 19:09:16 +0200,
Hans-Juergen Schoenig [EMAIL PROTECTED] wrote:
setting work_mem to 2gb does not help here ;)
set it to the max value on 8.0.
this was my first try too.
the problem is - there is no magic switch to mislead the planner a
little without hacking the
Peter Eisentraut wrote:
Bruce Momjian wrote:
How many times do I have to say this: IT IS NOT A REFACTOR PATCH AS
REPORTED BY THE AUTHOR, AND PETER HAS NOT REFUTED THAT.
The initial patch was the feature plus some code refactoring included.
That was what the author said. I asked him to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speaking of which, has anyone checked the copyrights on the other
proposed-for-inclusion contrib modules?
Uh, what other ones? I see none in the patch queue.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speaking of which, has anyone checked the copyrights on the other
proposed-for-inclusion contrib modules?
The new ISBN is the only open one. hstore hasn't had enough requests
for inclusion.
Really? A quick search of the archives
Guillaume Smet [EMAIL PROTECTED] writes:
On 9/4/06, Tom Lane [EMAIL PROTECTED] wrote:
I propose that for ILIKE in multibyte encodings, we just pass the strings
through lower() and then use the normal LIKE code.
Perhaps it's a stupid question but what about the indexes? An index on
Tom Lane skrev:
entryliteralfunctionsetseed/function(typedp/type)/literal/entry
entrytypeint/type/entry
- entryset seed for subsequent literalrandom()/literal calls/entry
+ entryset seed for subsequent literalrandom()/literal calls (value
between -1.0 and
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speaking of which, has anyone checked the copyrights on the other
proposed-for-inclusion contrib modules?
The new ISBN is the only open one. hstore hasn't had enough requests
for inclusion.
Really? A quick
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speaking of which, has anyone checked the copyrights on the other
proposed-for-inclusion contrib modules?
Uh, what other ones? I see none in the patch queue.
Dennis Bjorklund [EMAIL PROTECTED] writes:
entryliteralfunctionsetseed/function(typedp/type)/literal/entry
entrytypeint/type/entry
- entryset seed for subsequent literalrandom()/literal
calls/entry
+ entryset seed for subsequent literalrandom()/literal calls
Dennis Bjorklund [EMAIL PROTECTED] writes:
What about the return value? The doc didn't say anything about it.
AFAICT it's just junk. It happens to be the input times
MAX_RANDOM_VALUE, but what use is that? I wonder if we shouldn't
change the function to return VOID ... that option wasn't
Dhanaraj M [EMAIL PROTECTED] writes:
Sorry for resubmitting this patch.
Just now I found a problem.
Instead of assigning initial sequence value to 1,
I assign LLONG_MAX to avoid the buffer overflow problem.
Please find the current version here.
This patch is a mess. In the first place, it's
Gevik Babakhani wrote:
Folks,
Because of a broken wrist, I won't be able to type much.
1. Is there any discussion being going to regrading the:
%Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
No.
2. I took a brief look at gramm.y, would it be
Tom Lane wrote:
[EMAIL PROTECTED] (Peter Eisentraut) writes:
sslinfo contrib module - information about current SSL certificate
Author: Victor Wagner [EMAIL PROTECTED]
It was premature to add this: Bruce is still trying to get a copyright
assignment out of the author.
I got it this
Patch has applied this patch. Thanks.
---
Peter Eisentraut wrote:
Am Dienstag, 22. August 2006 02:52 schrieb Bruce Momjian:
This seems like a nice /contrib module.
Your patch has been added to the PostgreSQL
Patch applied. Thanks.
---
Christopher Kings-Lynne wrote:
Hi guys,
I've attached as much as I've done so far on the GIN docs. It's not a
lot, but I'm afraid with the feature freeze in effect, I'm just not
going to
Bruce Momjian wrote:
Patch has applied this patch. Thanks.
Sorry typo:
Peter has applied this patch. Thanks.
---
---
Peter Eisentraut
I should have a list of open items for 8.2 within 24 hours.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 2: Don't
On Mon, Sep 04, 2006 at 05:15:57PM +0100, Mark Cave-Ayland wrote:
3) Add planner support so that WITH clauses are mapped to a new type of
node that utilises two tuplestores - an output tuplestore and a working
tuplestore. The output tuple store will in effect be the contents of the
table
Alvaro Herrera [EMAIL PROTECTED] writes:
Also, the code is released under BSD license, so why is it important if
it says Copyright Foo, Inc or something else?
Because every so often we get pestered by lawyers who get worried when
there's a collection of random different copyright notices in the
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
[EMAIL PROTECTED] (Peter Eisentraut) writes:
sslinfo contrib module - information about current SSL certificate
Author: Victor Wagner [EMAIL PROTECTED]
It was premature to add this: Bruce is still trying to get a
Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
On Sun, Sep 03, 2006 at 10:21:11PM -0400, Bruce Momjian wrote:
When I tried the ecpg regression tests it complained there was no
results/ directory. I created one and it worked.
Hmm, anyone else experiencing this? The
Albe Laurenz [EMAIL PROTECTED] writes:
# The backend doesn't need everything that's in LIBS, however
! LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses
-lldap_r $(PTHREAD_LIBS), $(LIBS))
This seems pretty risky. What if PTHREAD_LIBS contains -L switches?
They'd get
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
This version was withdrawn by the author for rework, no?
Right, and the thread in patches_hold shows that. The reason it is in
there
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
[EMAIL PROTECTED] (Peter Eisentraut) writes:
sslinfo contrib module - information about current SSL certificate
Author: Victor Wagner [EMAIL PROTECTED]
It was premature to add this: Bruce is still trying to get
Picking out a specific point from the thread on prepared queries:
Currently, the handling of Parse/Bind on the unnamed statement seems to
go like this:
- Parse on the unnamed statement does analysis and rewriting but does
not plan, storing the query in a special memory context dedicated to
Andrew - Supernews [EMAIL PROTECTED] writes:
I believe this could usefully (and transparently to clients) be changed
so that Bind on the unnamed statement does _not_ store the plan back in
the unnamed statement's context, but instead produces a plan which is
only used _for that specific
[EMAIL PROTECTED] (Bruce Momjian) writes:
Sequences were not being shown due to the use of lowercase 's' instead
of 'S', and the views were not checking for table visibility with
regards to temporary tables and sequences.
What became of my objection that the test should be on USAGE privilege
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Sequences were not being shown due to the use of lowercase 's' instead
of 'S', and the views were not checking for table visibility with
regards to temporary tables and sequences.
What became of my objection that the test should
Albe Laurenz wrote:
Peter Eisentraut wrote:
Am Montag, 4. September 2006 10:23 schrieb Albe Laurenz:
This is just a 'one line' change in the documentation of
the --with-ldap flag of ./configure
Well, if you want to link from the configure option to the place where
the
feature is
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where
Peter Eisentraut wrote:
Log Message:
---
sslinfo contrib module - information about current SSL certificate
Author: Victor Wagner [EMAIL PROTECTED]
This seems to have broken the bustard buildfarm member, which uses VPATH
IIRC:
make[1]: Leaving directory
Patch applied. Placed in src/tools/msvc. Thanks.
---
Magnus Hagander wrote:
a.hub.org[200.46.208.251], delay=1, status=sent (250 2.7.1 Ok,
discarded, id=258
35-09 - BANNED: P=p003,L=1,M=multipart/mixed |
Patch applied. Thanks.
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The reason the patch is so short is that it's a kluge. If we really
cared about supporting this case, more wide-ranging changes
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples. It's not hard to imagine scenarios
where that results in severe
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples. It's not hard to imagine scenarios
where that
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
entryliteralfunctionsetseed/function(typedp/type)/literal/entry
entrytypeint/type/entry
- entryset seed for subsequent literalrandom()/literal
calls/entry
+ entryset seed for subsequent
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
Wait a minute. This patch changes the behavior so that
LockBufferForCleanup is applied to *every* heap page, not only the ones
where there are removable tuples.
Pavel Stehule [EMAIL PROTECTED] writes:
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.
This patch doesn't seem to cope with cases where the supplied tuple has
the wrong number of columns, and it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wrote:
Sequences were not being shown due to the use of lowercase 's' instead
of 'S', and the views were not checking for table visibility with
regards to temporary tables and sequences.
Tom Lane replied:
What became of my objection that the
Alvaro Herrera [EMAIL PROTECTED] writes:
This seems to have broken the bustard buildfarm member, which uses VPATH
IIRC:
Fixed --- I noticed it about the same time you did. I'm surprised Peter
didn't get a Makefile right the first time though ...
regards, tom lane
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane replied:
What became of my objection that the test should be on USAGE privilege
for the containing schema instead?
I took a stab at implementing this, but what exactly would we check? Looks
like all the temp tables have automatic usage
Hey Stefan, could you run some hardware diagnostics on leveret?
It's been returning increasingly erratic results over the past few days.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
Alvaro Herrera wrote:
I see the no-index case now:
+ if (nindexes)
+ LockBuffer(buf, BUFFER_LOCK_SHARE);
+ else
+ LockBufferForCleanup(buf);
Let's see what Greg says, or revert.
Hm, that's a good
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Attached version should now work properly.
Applied, thanks.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Sun, Sep 03, 2006 at 12:01:06AM -0400, Tom Lane wrote:
But ever since 7.3 the convention for identifying system objects has
been pretty well-defined: anything that lives in one of the predefined
schemas. What problem were you having using that approach in
newsysviews?
It was just an issue
Ühel kenal päeval, T, 2006-08-29 kell 22:12, kirjutas Joshua D. Drake:
Auto creations of partitions
This would be something like:
create table foo () partition by ...
from the referenced MySQL manual entry
CREATE TABLE members (
...
joined DATE NOT NULL
)
PARTITION BY KEY(joined)
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
This rush to apply patches just because no one seems to be capable of
keeping up with them not being reviewed, is starting to get a bit
worrisome.
When things are placed in the patches queue, I need to get feedback if
there is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SELECT *,has_schema_privilege(oid,'USAGE') FROM pg_namespace;
Well, if you test it as a superuser, it's going to return TRUE every
time.
Exactly. So I'm not seeing how we can use USAGE as a reliable test for
the case where a temporary table was
I don't have a concrete proposal to make, but I do think that the
current patch-queue process is not suited to the project as it stands
today. Maybe if this issue-tracking stuff gets off the ground, we
could let developers place ACK or NAK flags on patches they've looked
at, and have some rule
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
This rush to apply patches just because no one seems to be capable of
keeping up with them not being reviewed, is starting to get a bit
worrisome.
When things are placed in the patches queue, I need to get
Joshua D. Drake wrote:
I don't have a concrete proposal to make, but I do think that the
current patch-queue process is not suited to the project as it stands
today. Maybe if this issue-tracking stuff gets off the ground, we
could let developers place ACK or NAK flags on patches they've
Joshua D. Drake [EMAIL PROTECTED] writes:
How about *requiring* test cases that prove the patch?
There are lots and lots of things that can't really be tested with
pg_regress-based tests, and in any case a test does not prove the
absence of bugs; particularly not a test devised by the code
I suggest you test for the Intel compiler, and if it is there, make the
static variable volatile, and add a comment about why that is being
done.
---
Sergey E. Koposov wrote:
On Sat, 2 Sep 2006, Bruce Momjian wrote:
1 - 100 of 116 matches
Mail list logo