Abhijit Menon-Sen [EMAIL PROTECTED] writes:
--- fe-protocol3.c.1~ 2004-10-05 18:59:55.293092244 +0530
+++ fe-protocol3.c2004-10-05 19:17:48.154807848 +0530
@@ -220,6 +220,11 @@ pqParseInput3(PGconn *conn)
conn-asyncStatus = PGASYNC_READY;
Implementation-wise, I really dislike storing the info in a shared hash
table, because I don't see any reasonable bound on the size of the hash
table (your existing code uses 100 which is about as arbitrary as it
gets). [...]
The idea that occurs to me instead is to not use WAL or shared memory
Tom Lane [mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
... you end up with a core dump (signal 6) and an error
saying that you
can't stop before end of backup.
Was this corrected? I don't see any followups to it in the archives.
Not by me,
Well, the question is how long must the individual databases retain
state with which to answer recover requests. I don't like forever,
so I'm proposing that there should be an explicit command to say you
can forget about this gid.
I think it would be ok to forget the gid after:
1.
Hi Gavin,
I saw a initdb crashes when it is creating the template1 database.
I
couldn't figure out what is wrong. I attached the backtrace and
some
architecture/compiler info.
If someone needs more info, drop me a line.
Can you run initdb with the -d flag?
The log is attached.
On Thu, 7 Oct 2004, Euler Taveira de Oliveira wrote:
Hi Gavin,
I saw a initdb crashes when it is creating the template1 database.
I
couldn't figure out what is wrong. I attached the backtrace and
some
architecture/compiler info.
If someone needs more info, drop me a line.
Reini Urban schrieb:
Tom Lane schrieb:
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused. CVS has in port.h:
so you should already be calling the junction code on Cygwin.
true. didn't thought of that. very strange.
Yeah, I'm sure he is, but it looks from the regression results like it
doesn't
On Wed, 6 Oct 2004, Josh Berkus wrote:
[snip]
Of course, this is as true of functions as it will be of procedures. So half
the functionality that I'm angling for to support with calling named params
could be accomplished within the context of overloading just by extending the
named param
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If it were the else's indent plus one more tab it would be reasonably
sane; it'd match the indentation of what comes next.
OK, I can do that but consider:
[ other case ]
Just out of curiosity, what will
Fabien COELHO [EMAIL PROTECTED] writes:
Sorry for this stupid general comment, but why couldn't the gid be stored
in some shared system table that would rely on pg infrastructure for
caching, sharing, locking and so on?
That would have a number of pitfalls of its own:
* No
Hiya Everyone,
Can anyone explain how postgreSQL reads from a text
file into tables already created in PostgreSQL?
I am also checking the thread in the Forum just to see
if someone has written about it in the past.
Thanks.
Newton
___
Do you
Eyinagho Newton wrote:
Can anyone explain how postgreSQL reads from a text
file into tables already created in PostgreSQL?
Please direct general usage questions to [EMAIL PROTECTED].
I am also checking the thread in the Forum just to see
if someone has written about it in the past.
Please
Gavin Sherry wrote:
We cannot use named parameter notation with functions due to
overloading. Disregarding the idea of default values, consider:
create function foo(i int, j int) ...
create function foo(j int, i int) ...
That just means we cannot use the parameter name as a distinguishing
On Wed, Oct 06, 2004 at 01:27:26PM -0400, Alvaro Herrera wrote:
On Wed, Oct 06, 2004 at 10:01:42AM -0700, Mark Wong wrote:
On Mon, Oct 04, 2004 at 02:42:43PM -0400, Greg Stark wrote:
Mark Wong [EMAIL PROTECTED] writes:
Links to results are here:
7.5devel -
On Thu, 7 Oct 2004, Eyinagho Newton wrote:
Can anyone explain how postgreSQL reads from a text
file into tables already created in PostgreSQL?
Check out COPY command.
http://www.postgresql.org/docs/7.4/interactive/sql-copy.html
The file has to be in a certain format as explained in the
Peter Eisentraut wrote:
Gavin Sherry wrote:
We cannot use named parameter notation with functions due to
overloading. Disregarding the idea of default values, consider:
create function foo(i int, j int) ...
create function foo(j int, i int) ...
That just means we cannot use the parameter
On Sat, Sep 18, 2004 at 06:06:05AM -0400, Jan Wieck wrote:
On 9/17/2004 7:32 PM, Tom Lane wrote:
over time. I'm wondering about DNS lookup results in particular.
Except for one localhost, one /tmp/.s.PGSQL... and the 543x lookup
during the postmaster start, all lookups are IP addresses
This seems to have shown two problems. First is using the constant
username 'postgres' for postgres login salt, but if we use something
variable we would have to pass that constant on the wire so everyone
will see it. We can't encrypt the random salt with the password because
the server doesn't
Tom, Gavin, Peter, Andrew,
[ thinks some more... ] Actually I guess the problem comes with
create function foo(i float, j int) ...
create function foo(j int, i float) ...
which is a legal pair of functions from a positional viewpoint, but
would look identical when matching by names. We'd
I'd like to set up a BOF with any of the developers who are interested
in Boston at the Linux World Expo coming up at the end of February. I
don't have anything specific in mind and would like to get something
going. Any takers?
Some of the things I'm currently working on are OLTP and DSS
Mark Wong wrote:
I'd like to set up a BOF with any of the developers who are interested
in Boston at the Linux World Expo coming up at the end of February. I
don't have anything specific in mind and would like to get something
going. Any takers?
Some of the things I'm currently working on
On Thu, Oct 07, 2004 at 02:28:37PM -0400, Bruce Momjian wrote:
Mark Wong wrote:
I'd like to set up a BOF with any of the developers who are interested
in Boston at the Linux World Expo coming up at the end of February. I
don't have anything specific in mind and would like to get something
David Fetter wrote:
On Thu, Oct 07, 2004 at 02:28:37PM -0400, Bruce Momjian wrote:
Mark Wong wrote:
I'd like to set up a BOF with any of the developers who are interested
in Boston at the Linux World Expo coming up at the end of February. I
don't have anything specific in mind and
Added to open items list:
* remove non-portable TABLESPACE clause from CREATE TABLE using
a SET or ALTER command
---
Philip Warner wrote:
At 06:31 PM 1/09/2004, Fabien COELHO wrote:
I've noticed
On Thu, Oct 07, 2004 at 03:29:59PM -0400, Bruce Momjian wrote:
David Fetter wrote:
On Thu, Oct 07, 2004 at 02:28:37PM -0400, Bruce Momjian wrote:
Mark Wong wrote:
I'd like to set up a BOF with any of the developers who are
interested in Boston at the Linux World Expo coming up at the
Hi,
I'd like to know if there are any plans on introducing bitmap indexes
into postgresql. I think this could mean a big performance improvement
especially for datawarehousing applications. I know that there is an
index type hash but I don't know how both types are comparable due to
they are both
Bruce,
No, not really. The only things I think we know we want for 8.1 is
better integrated auto-vacuum and 2-phase commit.
What about the User Space quota patch? I though that one was pending review
as well.
And the completion of exception-handling for functions based on savepoints.
--
Yann Michel schrieb:
I'd like to know if there are any plans on introducing bitmap indexes
into postgresql. I think this could mean a big performance improvement
especially for datawarehousing applications. I know that there is an
index type hash but I don't know how both types are comparable due
David Fetter [EMAIL PROTECTED] writes:
Is there some way to mark this kind of stuff on the TODO
list? Right now things are marked, essentially, might get done
eventually, and handled in the coming release. Maybe some marker
like slated for version m.n would be good. :)
If we actually had
Josh Berkus [EMAIL PROTECTED] writes:
What about the User Space quota patch?
What about it? We never actually got one, according to my mailbox.
I was a tad concerned about the speed penalty associated with possibly
checking during every commit, but in the absence of seeing a patch it's
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 06 October 2004 17:35
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Pl/perl broken on Windows
OK, I have adjusted the code to use #define for the plperl compile.
This should prevent the
I agree with Tom on both points, userspace quote and TODO list items.
---
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
What about the User Space quota patch?
What about it? We never actually got one,
Yann Michel wrote:
Hi,
I'd like to know if there are any plans on introducing bitmap indexes
into postgresql. I think this could mean a big performance improvement
especially for datawarehousing applications. I know that there is an
index type hash but I don't know how both types are
Gavin Sherry wrote:
On Wed, 6 Oct 2004, Josh Berkus wrote:
[snip]
Of course, this is as true of functions as it will be of procedures. So half
the functionality that I'm angling for to support with calling named params
could be accomplished within the context of overloading just by extending
Tom Lane wrote:
The main thing that I'm not happy about is the syntax. I'm going to
resist commandeering = for this purpose, and I don't see any way to use
that symbol for this without forbidding it as a user-defined operator.
I previously suggested using AS, which is already a fully reserved
On Fri, 8 Oct 2004, Gaetano Mendola wrote:
Gavin Sherry wrote:
On Wed, 6 Oct 2004, Josh Berkus wrote:
[snip]
Of course, this is as true of functions as it will be of procedures. So half
the functionality that I'm angling for to support with calling named params
could be
On Thu, 7 Oct 2004, Peter Eisentraut wrote:
Gavin Sherry wrote:
We cannot use named parameter notation with functions due to
overloading. Disregarding the idea of default values, consider:
create function foo(i int, j int) ...
create function foo(j int, i int) ...
That just means we
On Thu, 7 Oct 2004, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
We cannot use named parameter notation with functions due to overloading.
Disregarding the idea of default values, consider:
create function foo(i int, j int) ...
create function foo(j int, i int) ...
If we
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do optimization,
sorting, or execution of single query. The major advantage of such a
feature would be to allow multiple CPUs to work together to process a
single
I just made some major Win32 modifications in the past few days. Would
you try Cygwin compile and see if the following warnings are removed and
the rest of the system builds OK?
---
Reini Urban wrote:
[BTW: there's no
In prior versions of Postgres, it has never been possible to remotely
find out the data directory location being used by the postmaster
(at least not without hacking some C code, which only superusers may
do).
You can make about equally good arguments that this is a bug or that
it's a feature:
Tom Lane wrote:
I am sort of on the fence about this. I am thinking that it would be
good to expose this information, but *only* to superusers. It would not
take much code to add a GUC variable flag bit that prevents
non-superusers from examining the value of the GUC variable, and only a
little
Andrew Dunstan wrote:
Tom Lane wrote:
I am sort of on the fence about this. I am thinking that it would be
good to expose this information, but *only* to superusers. It would not
take much code to add a GUC variable flag bit that prevents
non-superusers from examining the value of
Bruce Momjian [EMAIL PROTECTED] writes:
If they are using tablespaces is it OK that anyone can see their
location?
Good point. Should we obscure pg_tablespace similarly to what we do for
pg_shadow?
regards, tom lane
---(end of
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If they are using tablespaces is it OK that anyone can see their
location?
Good point. Should we obscure pg_tablespace similarly to what we do for
pg_shadow?
Well, if we feel file locations are better left only visible to
On Fri, 8 Oct 2004, Gavin Sherry wrote:
I agree that = restricts people in a way we are not at the moment. AS
is a better idea but I also like IS, which makes more sense to me. IS is
currently on the func_name_keyword list -- I *think* we could use it.
What do you think?
Josh kindly pointed
Gavin,
I agree that = restricts people in a way we are not at the moment. AS
is a better idea but I also like IS, which makes more sense to me. IS is
currently on the func_name_keyword list -- I *think* we could use it.
What do you think?
I'll give you an example why not:
CALL some_sp (
Josh Berkus [EMAIL PROTECTED] writes:
I'll give you an example why not:
CALL some_sp ( user IS 19, session IS NULL );
However, Tom, couldn't AS confuse the parser when used to call a named
function in a SELECT clause?
I don't think so. We are talking about
SELECT f(42 AS a, col1
[ further response ... ]
Josh Berkus [EMAIL PROTECTED] writes:
Example:
SELECT user, session,
crypt_function ( seed AS 345, content AS pwd_col ) AS munged_pwd
FROM users;
I failed to look closely at your example before. Apparently you are
thinking of the syntax as being parameter
On Fri, 8 Oct 2004, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
I'll give you an example why not:
CALL some_sp ( user IS 19, session IS NULL );
However, Tom, couldn't AS confuse the parser when used to call a named
function in a SELECT clause?
I don't think so. We are
Bruce Momjian [EMAIL PROTECTED] writes:
Good point. Should we obscure pg_tablespace similarly to what we do for
pg_shadow?
Well, if we feel file locations are better left only visible to
super-users, we should. However, when managing disk space, aren't
normal users also often interested in
On Thu, Oct 07, 2004 at 11:47:55AM +0700, David Garamond wrote:
Joshua D. Drake wrote:
This brings up an interesting idea. What if it were possible to set
some kind of rules on DDL at database creation time? For example, I'd
like to be able to throw an error if somebody tries to name an
David Fetter [EMAIL PROTECTED] writes:
How big a project would it be to have generalized DDL triggers? Apart
from resource allocation, what are some downsides of providing such a
facility?
BEFORE triggers on the system catalogs are Right Out. In principle we
could support AFTER triggers,
On Thu, 7 Oct 2004, David Fetter wrote:
On Thu, Oct 07, 2004 at 11:47:55AM +0700, David Garamond wrote:
Joshua D. Drake wrote:
This brings up an interesting idea. What if it were possible to set
some kind of rules on DDL at database creation time? For example, I'd
like to be able to
Has this been resolved?
---
Shinji Teragaito wrote:
On Tue, 24 Aug 2004 00:39:55 -0400, Tom Lane [EMAIL PROTECTED] said:
Shinji Teragaito [EMAIL PROTECTED] writes:
I made a patch to let PostgreSQL work in the LP64
Bruce Momjian [EMAIL PROTECTED] writes:
Has this been resolved?
AFAIK everything is fixed. I put in Shinji's changes and some more of
my own. I did port testing on HP 11.11 and 11.23 a month or so ago and
found that we could build and pass regression on both gcc and vendor
cc on both
Reini Urban wrote:
Bruce Momjian schrieb:
I have applied all parts of your patch now.
Thanks. Core builds and works fine now. (plperl IPC problems aside)
But there's are still some more minor SHLIB glitches,
which only affects contrib, because -lpgport is missing for various dll's.
Bruce Momjian schrieb:
Reini Urban wrote:
Bruce Momjian schrieb:
I have applied all parts of your patch now.
Thanks. Core builds and works fine now. (plperl IPC problems aside)
But there's are still some more minor SHLIB glitches,
which only affects contrib, because -lpgport is missing for various
On Thu, 07 Oct 2004 15:32:16 -0400, Tom Lane [EMAIL PROTECTED] said:
Bruce Momjian [EMAIL PROTECTED] writes:
Has this been resolved?
AFAIK everything is fixed. I put in Shinji's changes and some more of
my own. I did port testing on HP 11.11 and 11.23 a month or so ago and
found that we
Shinji Teragaito [EMAIL PROTECTED] writes:
152c152
SHLIB_LINK+= `$(CC) -print-libgcc-file-name`
---
SHLIB_LINK+= `$(CC) $(LDFLAGS) -print-libgcc-file-name`
Okay. I'm slightly worried about odd LDFLAGS values confusing this, but
we can deal with that when
60 matches
Mail list logo
