Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I thought I saw something this weekend about a new zic/timezone database
being
released though having trouble finding out the details now... is this
something that should be backpatched into the 8.0.x series?
Too late for 8.0.1.
On Fri, 28 Jan 2005 10:53:33 -0500, Tom Lane [EMAIL PROTECTED] wrote:
we should consider
something like clamp to size of table / 10 instead.
... unless a *single* grouping column is estimated to have more than
N/10 distinct values, which should be easy to check.
Servus
Manfred
On Wed, 19 Jan 2005 18:57:48 +0100, I wrote:
My first vacuum.c
refactoring patch, rev 1.281 2004-06-08, added these comments in
repair_frag():
/*
* VACUUM FULL has an exclusive lock on the relation. So
* normally no other transaction can have pending INSERTs or
* DELETEs in this relation.
Hi all,
I have a query that is something like this:
SELECT DISTINCT ON ( x ) x, foo(x)
FROM ...
now what do I see is that for each different x value
the foo is executed more than once, I guess this is because
the distinct filter out the rows after executing the query.
Is this behaviour the normal
Hi everyone,
I'm trying to install a copy of PostgreSQL 7.3.8 on FC3 x86_64, and having a
very strange problem with shared memory in that PostgreSQL seems to be
taking far too many semaphores for the parameters in the postgresql.conf
file. I've raised this with some of the members of the IRC
When SQL that returns many tuples with character code conversion
is executed, the FunctionCall3/FunctionCall5 becomes a bottleneck.
Because MemSet is used to initialize FunctionCallInfoData in these
functions, a lot of cycles are spent.
test query
set client_encoding to
Bruce Momjian pgman@candle.pha.pa.us writes:
A bigger question is whether we want to modify the timezone datbase in
minor releases. Such a change could cause application behavior changes.
The reason the zic database changes so often is that in certain parts
of the world they throw dice before
Am Samstag, 29. Januar 2005 23:32 schrieb Marc G. Fournier:
On Wed, 26 Jan 2005, Christopher Browne wrote:
Actually, the latter isn't so.
If Mammoth or Pervasive or such release their own release of
PostgreSQL, nothing has historically mandated that they make that
release available
On Sun, 30 Jan 2005, Tom Lane wrote:
Steve Atkins [EMAIL PROTECTED] writes:
For a replacement type, how important is it that it be completely
compatible with the existing inet/cidr types? Is anyone actually using
inet types with a non-cidr mask?
If you check the archives you'll discover that our
Primarily to give Magnus/Dave a chance at the code as early as possible
for the Windows package, the 8.0.1 bundles are now available ... I'm
working on the 7.x series bundles, but due to some delays in maintenance
work on the servers this past weekend, they are taking a wee bit longer
then
On Sun, Jan 23, 2005 at 07:32:55PM +0200, Heikki Linnakangas wrote:
If it helps, I could try to split it into two patches, one with code
rearrangements that don't change current behaviour, and then the actual
2PC stuff on top of that.
I think that'd be a good idea, because such a patch
Josh's last suggestion (ALL TABLES IN someschema) seems to me to be a
reasonable compromise between usefulness, syntactic weirdness, and
hiding implementation details.
Maybe it is not necessary to extend the syntax to distinguish between
the two cases. Maybe it's worth considering to have
On Sun, Jan 30, 2005 at 09:49:43PM -0600, Larry Rosenman wrote:
On Sun, 30 Jan 2005, Tom Lane wrote:
Steve Atkins [EMAIL PROTECTED] writes:
For a replacement type, how important is it that it be completely
compatible with the existing inet/cidr types? Is anyone actually using
inet types
Manfred Koizar [EMAIL PROTECTED] writes:
On Fri, 28 Jan 2005 10:53:33 -0500, Tom Lane [EMAIL PROTECTED] wrote:
we should consider
something like clamp to size of table / 10 instead.
... unless a *single* grouping column is estimated to have more than
N/10 distinct values, which should be
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I'm trying to install a copy of PostgreSQL 7.3.8 on FC3 x86_64, and having a
very strange problem with shared memory in that PostgreSQL seems to be
taking far too many semaphores for the parameters in the postgresql.conf
file.
Judging by the
8.0.1 7.4.7 are currently both available for testing, and 7.3.9 is
currently being built ... will pop a note once both 7.3. and 7.2 are also
ready ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy
Steve Atkins [EMAIL PROTECTED] writes:
The cidr type, including it's external interface, is simply broken.
That is a large claim that I don't think you have demonstrated.
The only one of your examples that seems to me to contradict the
documentation is this one:
steve=# select
Guys,
BTW, if you hadn't guessed, that comment was supposed to be off-list.
Unfortunately, I discovered a bug with KMail and list management, the hard
way ...
Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if
you have list management turned on, it sometimes sends
Andrew,
On Thu, Jan 27, 2005 at 10:39:52AM -0800, Josh Berkus wrote:
Thanks. As you know, I'm getting a little sick of the chicken little
act among many of the -hackers
I think this is a little bit of a mischaracterisation. Afilias is
already a customer of IBM.
BTW, if you
Marc,
And to be perfectly frank, I was mostly thinking of Marc when I said that.
Sorry, that was uncharitable. I meant that (at the time) you were panicking.
Now you have something different to panic about. How goes the server
shuffle?
--
Josh Berkus
Aglio Database Solutions
San
Josh Berkus wrote:
Guys,
BTW, if you hadn't guessed, that comment was supposed to be off-list.
Unfortunately, I discovered a bug with KMail and list management, the hard
way ...
Sigh.Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if
you have list management turned on, it
Hi *,
I will start implementing this stuff based on this syntax:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
so there are two seperate commands to use.
is everybody fine with this aproach?
cheers,
Matthias
PS.: Tom, shouldn't we mention the
On Mon, 31 Jan 2005, Josh Berkus wrote:
Now you have something different to panic about. How goes the server
shuffle?
alot smoother today then it went yesterday ... and faster ... but, then
again, *most* clients use 256MB of storage, so moving their VM around
takes no time ... svr1 is @ ~13G
On Mon, 31 Jan 2005, Josh Berkus wrote:
Marc,
And to be perfectly frank, I was mostly thinking of Marc when I said that.
Sorry, that was uncharitable. I meant that (at the time) you were panicking.
Wait, I've not panic'd about all of this at any point ... the only
'chicken little' comment I made
Hi Merlin,
sorry - I replied to Tom PG hackers before I saw you last post.
I think it is best to code the basic functionallity within the two new
commands, and see
how this works out. We can add your idea and others on top of it later
on.
what about that?
cheers,
Matthias
Marc,
alot smoother today then it went yesterday ... and faster ... but, then
again, *most* clients use 256MB of storage, so moving their VM around
takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox
alone ... and i miscalculated how long it would take to move it back
Please review them to make sure they look already ...
Dave, I've changed the symlink's as well ...
Will announce everything publicly around 4am GMT tonight (midnight my
time) to give ~10hrs for the rest to propogate out ...
Marc G. Fournier Hub.Org Networking Services
Gaetano Mendola [EMAIL PROTECTED] writes:
now what do I see is that for each different x value
the foo is executed more than once, I guess this is because
the distinct filter out the rows after executing the query.
Is this behaviour the normal one? Shall be not documented ?
Usually
Greg Stark wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
now what do I see is that for each different x value
the foo is executed more than once, I guess this is because
the distinct filter out the rows after executing the query.
Is this behaviour the normal one? Shall be not documented ?
Matthias wrote:
I think it is best to code the basic functionallity within the two new
commands, and see
how this works out. We can add your idea and others on top of it later
on.
I think you should do whatever you think is most
appropriate...discussion can of course continue after you have a
Gaetano Mendola [EMAIL PROTECTED] writes:
my warning was due the fact that in the docs is written nowhere this
drawback.
The SELECT reference page already says that the output rows are computed
before applying ORDER BY or DISTINCT.
regards, tom lane
Hello again.
This time I'd like to speak about in-memory bitmap to combine index scan
results. I know, this code should use minimal amount of memory, so I really
want to hear any possible pros and cons.
Below, pseudocode is given. After running it, we'll have a list of CTID
pointers, and one
Merlin Moncure [EMAIL PROTECTED] writes:
Is this:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
Really better than this?
GRANT { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER
| EXECUTE | CREATE | ALL [ PRIVILEGES ] }
Paul Vixie [EMAIL PROTECTED] writes:
when my cidr datatype was integrated into pgsql, the decision was made to
incorporate a copy of bind's inet_net_pton.c rather than add a link-time
dependence to libbind.a (libbind.so).
We didn't really want to assume that all platforms are using libbind :-(
On Mon, 31 Jan 2005 11:20:31 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Already done that way.
if (relvarcount 1)
clamp *= 0.1;
That's not what I meant. I tried to say that if we have a GROUP BY
several columns and one of these columns alone has more than N/10
distinct
Tom Lane [EMAIL PROTECTED] writes:
steve=# select '224.0.0.0'::cidr;
cidr
-
224.0.0.0/4
which should be /32 according to what the docs say:
224-239 are multicast addresses. Making it /4 makes the entire multicast
address space one network block which is about
Manfred Koizar [EMAIL PROTECTED] writes:
That's not what I meant. I tried to say that if we have a GROUP BY
several columns and one of these columns alone has more than N/10
distinct values, there's no way to get less than that many groups.
Oh, I see, you want a max calculation in there too.
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
Really better than this?
GRANT { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES |
TRIGGER
| EXECUTE | CREATE | ALL [ PRIVILEGES ] }ON SCHEMA schemaname [,
...]
The latter
Please check this one over ... Tom foudn some issues with the docs build
that should be fixed ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of
Merlin Moncure [EMAIL PROTECTED] writes:
Is the price of looking up a schema a deal breaker here, or is it
possible to avoid it?
My guess is no as to both questions. I've never seen any profiles
suggesting that permissions-checking is a significant part of query
startup. In any case, if you
[bcc to -hackers, -general]
Folks,
I'm happy to announce that PostgreSQL will have a home at LinuxWorld in two weeks after
all. My company, OpenMFG, is teaming up with SRA America to wave the elephant flag at
booth #1411 - right next door to the .org Pavillion, two booths up from the
Intel
On Mon, Jan 31, 2005 at 12:16:26PM -0500, Tom Lane wrote:
Steve Atkins [EMAIL PROTECTED] writes:
The cidr type, including it's external interface, is simply broken.
That is a large claim that I don't think you have demonstrated.
The only one of your examples that seems to me to contradict
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 31 January 2005 18:30
To: pgsql-hackers@postgresql.org
Cc: David Fetter
Subject: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ...
Please review them to make sure they look
I just noticed that our port/getopt_long.c substitute implementation
does not accept abbreviated names for long options:
$ pg_dump --username tgl regression
... works ...
$ pg_dump --user tgl regression
pg_dump: illegal option -- user
Try pg_dump --help for more information.
$
The GNU
Dave Page dpage@vale-housing.co.uk writes:
/pub/src/v8.0.1 is missing :-(
Why do we even have individual symlinks in pub/src? Seems to me we
could replace the whole src directory with a symlink to source, and
eliminate one bit of release bookkeeping ...
regards, tom
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 31 January 2005 22:24
To: Dave Page
Cc: Marc G. Fournier; pgsql-hackers@postgresql.org; David Fetter
Subject: Re: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ...
Dave Page
Marc G. Fournier [EMAIL PROTECTED] writes:
Please check this one over ... Tom foudn some issues with the docs build
that should be fixed ...
Seems clean now.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you
fixed
On Mon, 31 Jan 2005, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 31 January 2005 18:30
To: pgsql-hackers@postgresql.org
Cc: David Fetter
Subject: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ...
Please review
On Mon, 31 Jan 2005, Tom Lane wrote:
Dave Page dpage@vale-housing.co.uk writes:
/pub/src/v8.0.1 is missing :-(
Why do we even have individual symlinks in pub/src? Seems to me we
could replace the whole src directory with a symlink to source, and
eliminate one bit of release bookkeeping ...
the
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: 31 January 2005 22:35
To: Tom Lane
Cc: Dave Page; pgsql-hackers@postgresql.org; David Fetter
Subject: Re: [HACKERS] 7.2.7 - 8.0.1 Bundles Ready ...
On Mon, 31 Jan 2005, Tom Lane wrote:
Dave Page
Paul Vixie [EMAIL PROTECTED] writes:
i have two suggestions. first, look at the rest of the current source file,
in case there are other fixes.
Right, I already grabbed the latest.
second, track changes this source file during
your release engineering process for each new pgsql version.
On Mon, 2005-01-31 at 23:38 +0900, a_ogawa wrote:
(b)Define the macro that initialize FunctionCallInfoData, and use it
instead of MemSet in all FunctionCallN, DirectFunctionCallN,
OidFunctionCallN.
This macro is the following.
#define InitFunctionCallInfoData(Fcinfo, Flinfo, Nargs)
Merlin, Tom:
A table or function privilege, if it exists, will override anything for
the table. This will be faster (FWIW) than a multiple table grant
because it's just setting one permission at the schema level. Someone
else will have to comment on how effectively this will work with
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2005-01-31 at 23:38 +0900, a_ogawa wrote:
(b)Define the macro that initialize FunctionCallInfoData, and use it
instead of MemSet in all FunctionCallN, DirectFunctionCallN,
OidFunctionCallN.
This macro is the following.
#define
We didn't really want to assume that all platforms are using libbind :-(
i think you could have, at the time, since windows wasn't even a gleam in
pgsql's eye. even now, libbind would be a dependable universal dependency,
since we publish windows binaries.
the pgsql fork of this code did not
I set up MinGW and msys distributive.
Also i did download CVS source of PostGre.
What command should i do next to compile sources.
Please help, never worked with MinGW.
thank in advance.
Dmitry Konnov
---(end of broadcast)---
TIP 6: Have you
when my cidr datatype was integrated into pgsql, the decision was made to
incorporate a copy of bind's inet_net_pton.c rather than add a link-time
dependence to libbind.a (libbind.so). thus, when this bug was fixed in
2003:
revision 1.14
date: 2003/08/20 02:21:08;
Merlin Moncure wrote:
Jeff wrote:
Is there a practical use for retrieving 2^31 records at once?
(this is a serious question, I'm not arguing that it should cause a
syntax error)
Regards,
Jeff Davis
On Mon, 2005-01-24 at 14:13 -0500, Merlin Moncure wrote:
I was
Andreas Pflug wrote:
Merlin Moncure wrote:
3) Allow GRANT/REVOKE permissions to be applied to all schema
objects
with one
Maybe this is apply schema changes to several objects with one
command. This seems reasonable.
Well, I don't know. IMO, what I would really like to see
Michael Fuhr [EMAIL PROTECTED] writes:
On Tue, Feb 01, 2005 at 12:56:20AM -0500, Tom Lane wrote:
His point stands though: if you are accessing Postgres through some kind
of connection-pooling software, currval() cannot be trusted across
transaction boundaries, since the pool code might give
Tom Lane Writes:
Michael Fuhr [EMAIL PROTECTED] writes:
On Tue, Feb 01, 2005 at 12:56:20AM -0500, Tom Lane wrote:
His point stands though: if you are accessing Postgres
through some
kind of connection-pooling software, currval() cannot be trusted
across transaction boundaries, since
61 matches
Mail list logo
