On Sun, 17 Nov 2003, Greg Stark wrote:
Neil Conway [EMAIL PROTECTED] writes:
What does BEGIN actually do now, from a user's perspective?
I think you're thinking about this all wrong. BEGIN doesn't do anything.
It's not a procedural statement, it's a declaration. It declares that the
block
On Friday 14 November 2003 22:10, Jan Wieck wrote:
Shridhar Daithankar wrote:
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think the algorithm how much and how often
to flush can be
Hi,
in doc/man1/psql.1 there is a line:
Welcome to psql 7.4beta5, the PostgreSQL interactive terminal.
Tommi
Am Montag, 17. November 2003 02:23 schrieb Marc G. Fournier:
'k, I just moved the release into the /pub/source/v7.4 directory from the
v7.4beta one ... RC2 is still in place, so that I
Tom Lane kirjutas E, 17.11.2003 kell 02:08:
Neil Conway [EMAIL PROTECTED] writes:
Hmmm... I agree this behavior isn't ideal, although I can see the case
for viewing this as a mistake by the application developer: they are
assuming that they know exactly when transactions begin, which is not
Bruce Momjian kirjutas E, 17.11.2003 kell 02:31:
Defining now() as the first call seems pretty arbitrary to me. I can't
think of any time-based interface that has that API. And what if a
trigger called now() in an earlier query and you didn't even know about
it.
That would be OK. The whole
1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if
Without grouping WAL writes that does not fly. Iff however such grouping
is implemented that should deliver optimal performance. I don't think flushing
WAL to the OS early (before a tx commits) is necessary, since writing 8k or
-- value-independent transition function
CREATE AGGREGATE newcnt (
sfunc = int4inc, basetype = 'any', stype = int4,
initcond = '0'
);
COMMENT ON AGGREGATE newcnt (any) IS 'an any agg comment';
ERROR: syntax error at or near any at character 30
COMMENT ON AGGREGATE newcnt (any) IS NULL;
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where am I wrong?
I don't think any of this is relevant. There are a certain number of
blocks we have to get down to disk before we can declare a transaction
committed, and there are a certain number that we have to get down to
disk
Hi,
I suspect this a problem local to my machine, but I cannot compile with the
--with-java option... It fails like so
driver:
[copy] Copying 1 file to
/usr/local/install/postgresql-7.4/src/interfaces/jdbc/org/postgresql
[echo] Configured build for the JDBC3 edition driver with SSL
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly change column order,
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly change column order,
Sorry, I did find the offending driver in the end... And it is running
happily now.
Sorry for the noise
Adam
Hi,
I suspect this a problem local to my machine, but I cannot compile with the
--with-java option... It fails like so
driver:
[copy] Copying 1 file to
Neil Conway writes:
(b) Using the above scheme that attnum == attpos initially, there
won't be any gaps in the sequence of attpos values. That means
that if, for example, we want to move the column in position 50
to position 1, we'll need to change the position's of all
On Mon, 17 Nov 2003, Neil Conway wrote:
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't think you can speak of bloat for pg_attribute. But you
can speak of a problem when you want to do the old col = col + 1 in
the presence of a unique index.
I'm sorry, but I'm not sure what either of these comments mean -- can
you elaborate?
Jon Jensen [EMAIL PROTECTED] writes:
You're just saying it'd break old dumps, right? I'd assume COPY FROM
would use attpos ordering when writing out columns, or that every
user-visible interaction with the table pretends the columns are in
attpos order. So dumps would break no more or less
Hi all,
I don't think it's a FAQ, Is it possible to limit then number of
simultaneous connexions one can make to a particular databse.
E.G: I have 128 connexions max of witch I wan't to restrict at most 60 to
database x, leaving in the worst case 68 for all others...
Am I clear?
--
Olivier
It's a command line option for the server.
http://developer.postgresql.org/docs/postgres/app-postmaster.html
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 11:21 AM
To: pgsql-hackers list
Subject: [HACKERS] Connexions question
Oops. Never mind. I did not read your message carefully.
-Original Message-
From: Dann Corbit
Sent: Monday, November 17, 2003 11:51 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Connexions question
It's a command line option for the server.
Er, that's a per-server limit, not a per-database limit (which is what
he asked for), isn't it?
cheers
andrew
Dann Corbit wrote:
It's a command line option for the server.
http://developer.postgresql.org/docs/postgres/app-postmaster.html
-Original Message-
From: [EMAIL PROTECTED]
http://www.coyotegulch.com/acovea/index.html
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Hi,
I've searched through libpq and looked for global or static variables as
indicators of non-threadsafe code. I found:
- Win32 and BeOS: there is a global ioctlsocket_ret variable, but it
seems to be a dummy variable that is always discarded.
- pg_krb4_init(): Are the kerberos libraries
Yesterday I was a bit worried... I switched to SuSE just 2 weeks ago...
my newly installed databse server was waitinI thought that I would have
to wait so much to have RPMs for SuSE and today I see v7.4 compiled for
many flavors of SuSE, even for X86-64. Wow :)
Thanks :)
--
Daniele Orlandi
On Sun, Nov 02, 2003 at 07:25:38AM -0500, Rod Taylor wrote:
On Sat, 2003-11-01 at 20:58, Mark Wong wrote:
I don't remember making a conscious decision between the number and integer
database type. Is that a significant oversight on my part?
Numerics do exact math with support for
Folks,
Of course, while I was editing press releases at 2am, I started thinking about
our next version. It seems certain that the next release, in 6-9 months,
will have at a minimum the Windows port and ARC, if not Slony-I as well.
Given all that, don't people think it's time to jump to 8.0?
Josh Berkus [EMAIL PROTECTED] writes:
It seems certain that the next release, in 6-9 months, will have at
a minimum the Windows port and ARC, if not Slony-I as well.
Given all that, don't people think it's time to jump to 8.0?
It seems a little premature to speculate on what features may or
Josh Berkus writes:
Given all that, don't people think it's time to jump to 8.0?
As has been said before, many people think that a Windows port is the
least interesting feature ever to happen to PostgreSQL, so you're going to
have to come up with better reasons. Also note that most major
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a
Hello,
If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
appropriate.
Sincerely,
Joshua D. Drake
On Mon, 17 Nov 2003, Josh Berkus wrote:
Folks,
Of course, while I was editing press releases at 2am, I started thinking about
our next version. It seems certain that
As has been said before, many people think that a Windows port is the
least interesting feature ever to happen to PostgreSQL, so you're going to
Yes but these are people running Unix/Linux/BSD not Windows ;)
have to come up with better reasons. Also note that most major number
changes in
Shridhar Daithankar wrote:
On Friday 14 November 2003 22:10, Jan Wieck wrote:
Shridhar Daithankar wrote:
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think the algorithm how much
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people
On Mon, 17 Nov 2003, Josh Berkus wrote:
Given all that, don't people think it's time to jump to 8.0? Seems like
even 7.4 is hardly recognizable as the same database as 7.0.
Discussion like this tends to be more for just before beta, once we have
an idea what actually made it in :) You be
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)
I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period.
Hannu Krosing wrote:
Bruce Momjian kirjutas E, 17.11.2003 kell 02:31:
Defining now() as the first call seems pretty arbitrary to me. I can't
think of any time-based interface that has that API. And what if a
trigger called now() in an earlier query and you didn't even know about
it.
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)
I don't see how we could have tried for a 4-month
Tommi Maekitalo wrote:
Hi,
in doc/man1/psql.1 there is a line:
Welcome to psql 7.4beta5, the PostgreSQL interactive terminal.
Yea, sorry. It pulls the version number from the time those man pages
were built. Not sure how we could have prevented it.
--
Bruce Momjian
Joshua D. Drake wrote:
Hello,
If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
appropriate.
It might be interesting to track Oracle's version number viz. its
feature list. IOW, a PostgreSQL 8.0 database would be feature
equivalent to an Oracle 8.0 database. That would
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
On Mon, 17 Nov 2003, Marc G. Fournier
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Marc G. Fournier writes:
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
That was a
Right -- AFAICS, the only change in COPY compatibility would be if you
COPY TO'd a table and then changed the logical column order in some
fashion, you would no longer be able to restore the dump (unless you
specified a column list for the COPY FROM -- which, btw, pg_dump
does). I don't think it
Neil Conway writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
First, if you develop something today, the first time users would
realistically get a hand at it would be
I screwed up, and dropped a column when I shouldn't have.
I have *not* vacuumed this DB yet.
Is there any catalog mucking I can do to bring it back?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail:
Neil Conway wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't think you can speak of bloat for pg_attribute. But you
can speak of a problem when you want to do the old col = col + 1 in
the presence of a unique index.
I'm sorry, but I'm not sure what either of these comments mean
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end
Neil Conway wrote:
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly
Wait for confirmation from at least one other developer perhaps, buy you
can try this:
1. Set attisdropped to false for the attribute
2. Set the atttypid back to whatever the oid of the type of that column
is/was (Compare to an undropped similar column)
3. Use ALTER TABLE/SET NOT NULL on
--On Monday, November 17, 2003 19:36:08 -0600 Larry Rosenman
[EMAIL PROTECTED] wrote:
I screwed up, and dropped a column when I shouldn't have.
I have *not* vacuumed this DB yet.
Is there any catalog mucking I can do to bring it back?
Actually, I got lucky. pg_catalog.pg_attribute is what I
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
People are running their companies and lives off of PostgreSQL, they
--On Tuesday, November 18, 2003 09:59:32 +0800 Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Wait for confirmation from at least one other developer perhaps, buy you
can try this:
1. Set attisdropped to false for the attribute
2. Set the atttypid back to whatever the oid of the type of
On Tue, 18 Nov 2003, Christopher Kings-Lynne wrote:
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
April 1st, or 4 mos from last release, tends to be what we aim for with
all releases ... as everyone knows,
Joshua D. Drake [EMAIL PROTECTED] writes:
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
That would pretty much
Peter Eisentraut [EMAIL PROTECTED] writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle if it is better for
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already started, so April 1st is
Manfred Spraul wrote:
Hi,
I've searched through libpq and looked for global or static variables as
indicators of non-threadsafe code. I found:
- Win32 and BeOS: there is a global ioctlsocket_ret variable, but it
seems to be a dummy variable that is always discarded.
Right, and it is
Josh Berkus wrote:
Also note that most major number
changes in the past weren't because the features were cool, but because
the project has moved to a new phase. I don't see any such move
happening.
Now that is interesting. I missed that. Can you explain how that worked
with 7.0?
Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already
On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote:
Right -- AFAICS, the only change in COPY compatibility would be if you
COPY TO'd a table and then changed the logical column order in some
fashion, you would no longer be able to restore the dump (unless you
specified a column
Christopher Kings-Lynne writes:
BTW, one main consideration is that all the postgres admin apps will now
need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the
BTW, one main consideration is that all the postgres admin apps will now
need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they
need to do another. That seems
Matthew T. O'Connor [EMAIL PROTECTED] writes:
So 7.4 took about 4.5 months to get from feature freeze to release.
I think feature freeze is the important date that developers of new
features need to concern themselves with.
Rather than the length of the release cycle, I think it's the length
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Christopher Kings-Lynne writes:
BTW, one main consideration is that all the postgres admin apps will now
need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS
Neil Conway wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle
Matthew T. O'Connor wrote:
I agree with Peter's other comment, that the longer the development
cycle, the longer the beta / bug shakeout period, perhaps a shorter dev
cycle would yield a shorter beta period, but perhaps it would also
result in a less solid release.
Perhaps. Perhaps not.
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
what we can do to
Neil Conway writes:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a
On Mon, 17 Nov 2003, Neil Conway wrote:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does
eg. Someone who just knows how to use postgres could test my upcoming
COMMENT ON patch. (It's best if I myself do not test it) Someone with
more skill with a debugger can be asked to test unique hash indexes by
playing with concurrency, etc.
I forgot to mention that people who just have
--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Neil Conway writes:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part ...
other then the first beta, I post a note out to -announce and
On Mon, 17 Nov 2003, Larry Rosenman wrote:
I try to test stuff fairly frequently, and this time I didn't know when,
exactly, SCO would make the release of the updated compiler.
And there was no way you could predict that your contact there would take
off on holidays either :(
Since I can't just go in an remove all the v's from the directory names in
the ftp site, without breaking any links to the ftp servers, I just
created a new directory that contains the 'non-v' names, with symlink's to
the v'd directories ...
ftp://ftp.postgresql.org/pub/src/[167].*
vs
Mike Mascari [EMAIL PROTECTED] writes:
1) PITR
2) Distributed Tx
3) Replication
4) Nested Tx
5) PL/SQL Exception Handling
Of these PITR seems *by far* the most important. It makes the difference
between an enterprise-class database capable of running 24x7 with disaster
recovery plans, and
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't mean it's
useful.
I don't call porting Postgres to run well on something like 40% of the
Christopher Kings-Lynne wrote:
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on
dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't
mean it's
useful.
I don't call porting Postgres to run
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part
(1) Make the beta more
On Tue, 18 Nov 2003, Neil Conway wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think
Matthew T. O'Connor writes:
Absolutely! In addition, even if you don't consider win32 a platform to
run production databases on, the win32 port will help developers who
work from windows boxes, which is the certainly the most widely used
desktop environment.
At the risk of stating the
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I don't call porting Postgres to run well on something like 40% of the
world's servers (or whatever it is) just another port.
It could conveivably double Postgres's target audience, could attract heaps
of new users, new developers, new
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 10:04 PM
To: Matthew T. O'Connor
Cc: Christopher Kings-Lynne; Greg Stark; [EMAIL PROTECTED]
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Matthew T. O'Connor writes:
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 10:34 PM
To: Dann Corbit
Cc: Matthew T. O'Connor; Christopher Kings-Lynne; Greg Stark;
PostgreSQL Development
Subject: RE: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Dann
--- Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
I don't call porting Postgres to run well on something like 40% of the
world's servers (or whatever it is) just another port.
Statistics is a tricky thing. IMHO, there are plenty of things that are much
more important than win32 port.
-Original Message-
From: ow [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 10:39 PM
To: Christopher Kings-Lynne; Greg Stark
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
--- Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
I
The PostgreSQL group has recently had a patch submitted with a snippet
of code from FreeBSDs src/bin/mkdir/mkdir.c.
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27
Is this intentionally under the 4 clause license or does the copyright
from the website (2 clause) applied
88 matches
Mail list logo
