On Fri, 2004-04-30 at 04:02, Bruce Momjian wrote:
Let me also add that I am not terribly worried about having the feature
to restore to an arbitrary point in time for 7.5. I would much rather
have a good PITR solution that works cleanly in 7.5 and add it to 7.6,
than to have retore to an
Rob Butler wrote:
$369 for 4GB of storage in a compact flash card is not all that bad.
$189 for 2.2GB is very reasonable when you consider the 512MB CF is
going for $149!
The current cheap workaround to get a Hitachi (ne IBM) 4GB microdrive is
to buy a Creative Muvo2 4GB and open it up to
Basically it is updating the logs as soon as it receives the
notifications. Writing 16 MB of xlogs could take some time.
In my experience with archiving logs, 16 Mb is on the contrary way too
small for a single log. The overhead of starting e.g. a tape session
is so high that you cannot
Are there some ports available to various devices?
What is the lowest memory footprint PostgreSQL has achieved?
[8Mb was last quote]
How little disk space has anyone achieved?
Is that an available port, or just a set of configure options?
Is there a definitive list of supported ports?
* Handle sync() by opening all file opened since the last
fsync and fsync'ing those
- Tom's got this one, as is the most crucial outstanding part
Yes, this is defintly the largest part of the code missing.
* Win32 installer
- I believe Magnus already has something in this
Yes, it was vague. The question is now that we are a month away, do
we
want to target June 1, mid-June, or July 1.
If I may humbly chime in here...there currently is no binary
packing for the win32 port. Magnus is currently working on
an installer/service manager (dubbed 'longer
Andrew Dunstan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Not quite yet - yesterday I got hold of a windows box for the first time
in months and had significant building problems (the symlink problem and
others). This needs to be robust. I will be sending in some fixes in due
It definitly is there fro Windows Server 2003, in the new port. But
since you are talking handhelds, are you possibly referring
to Windows
Mobile 2003? That is a whole different beast, and *not* included in
the
win32 part (no Win CE variants are)
Nor are they likely to be at a
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 30 April 2004 11:40
To: Simon Riggs; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Small OS ports Handheld devices
It definitly is there fro Windows Server 2003, in the new
port. But since you are talking
Am Freitag, 30. April 2004 12:45 schrieb Magnus Hagander:
A question about this though - do we want the installer source (required
to build the MSI - not the MSI itself, of course) in main CVS?
We don't have any other packaging-related files in our CVS (for various good
reasons), so I don't
Thomas Hallgren said:
Andrew Dunstan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Not quite yet - yesterday I got hold of a windows box for the first
time
in months and had significant building problems (the symlink problem
and others). This needs to be robust. I will be
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 30 April 2004 13:01
To: Dave Page; Simon Riggs; [EMAIL PROTECTED]
Subject: RE: [HACKERS] Small OS ports Handheld devices
Not having looked at the code, I think you are going to have
a much easier time
I read in the manual that the libpq functions PQputline(conn, cmd) and
PQendcopy(conn) have been deprecated and that PQputCopyData(conn, cmd,
sizeof(cmd)) and PQputCopyEnd(conn, msg) are the replacements.
I'm trying to convert a program that works just fine with the old
functions. I assume I'm
On Fri, 30 Apr 2004, Peter Eisentraut wrote:
Am Freitag, 30. April 2004 12:45 schrieb Magnus Hagander:
A question about this though - do we want the installer source (required
to build the MSI - not the MSI itself, of course) in main CVS?
We don't have any other packaging-related files in
Marc G. Fournier wrote:
On Fri, 30 Apr 2004, Peter Eisentraut wrote:
Am Freitag, 30. April 2004 12:45 schrieb Magnus Hagander:
A question about this though - do we want the installer source (required
to build the MSI - not the MSI itself, of course) in main CVS?
We don't have any
On Fri, Apr 30, 2004 at 06:12:35AM -0700, Tony Reina wrote:
CString cmd, msg;
cmd.Format(1\t\2\t{3,4,5}\n);
* PQputCopyData(conn, cmd, sizeof(cmd));
cmd.Format(\\.\n);
* PQputCopyData(conn, cmd, sizeof(cmd));
* PQputCopyEnd(conn, msg);
Old C++
On Fri, Apr 30, 2004 at 12:52:10AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In current (as of a couple hours ago) clean CVS tip sources, without any
of my local changes, I'm getting a postmaster segfault when trying to
connect to a non existant database.
Alvaro,
Dear hackers,
It seems to me that the current default setup for a new database which is
given to some user is not consistent (createdb -O calvin foo or
CREATE DATABASE foo WITH OWNER calvin).
Indeed, although the database belongs to the owner, the public schema
still belongs to the database
AFAICS this ambiguity is built into the SQL standard, and in fact it's
possible to generate cases that are legally parseable either way:
SELECT foo.x = ANY((SELECT bar.y FROM bar)) FROM foo;
[...]
So I think that the SQL committee shot themselves in the foot when they
decided it
Alvaro Herrera [EMAIL PROTECTED] writes:
In current (as of a couple hours ago) clean CVS tip sources, without any
of my local changes, I'm getting a postmaster segfault when trying to
connect to a non existant database.
Alvaro, did you figure this out? I've been mostly distracted
[EMAIL PROTECTED] (Tony Reina) writes:
* PQputCopyData(conn, cmd, sizeof(cmd));
I'm a bit rusty on C++ string mashing, but surely sizeof() is not the
correct way to determine the number of bytes presently stored in a
variable-length string?
* PQputCopyEnd(conn, msg);
You want to
I think we fixed it since then.
---
Fabien COELHO wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In current (as of a couple hours ago) clean CVS tip sources, without any
of my local changes, I'm getting a
Andrew Payne wrote:
My concern about a single company, as all of us are, is that we kill the
community that created the software, which then burdens the single
company to steer development, leading to disaster.
Understood, and that's the potential catch-22. This is the problem with
Bruce wrote:
Remember, we all came to PostgreSQL because of the community
development, so we can't expect us to get excited about something that
risks that just to win, as you say. If we had gone in this direction
with Great Bridge, we would have seriously injured PostgreSQL and it
might
The difference is that you could now correct for Great Bridge's problems,
which include but are not limited to: timing (4 years has changed a lot for
commercial acceptance of open source), funding ($25m was too much), and
strategy (this is not an quick attempt to copy Red Hat).
I think such a
Marc G. Fournier wrote:
Well, that's an okay position if your time horizon is measured in days.
But I would like to see us using that code on all platforms before 7.5
feature freeze. It's silly to be carrying that code around and not
using it, when we have constant problems with the
Marc G. Fournier wrote:
No, I agree that that would be foolish ... but there has also been alot
done on the code over the past few months that even *one* of those
features should be enough to put it over the top ...
OK, what is the plan for feature freeze?
As we going for June 1,
Hackers,
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
alvherre=# begin;
BEGIN
alvherre=# prepare tres as select 3;
PREPARE
alvherre=# rollback;
ROLLBACK
alvherre=# execute tres;
?column?
--
3
(1 fila)
--
Alvaro Herrera
Does ecpg need to use the same timezone database as the backend?
I just committed code so it will not, but I am not sure.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts
On Fri, 30 Apr 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
No, I agree that that would be foolish ... but there has also been alot
done on the code over the past few months that even *one* of those
features should be enough to put it over the top ...
OK, what is the plan
Marc G. Fournier wrote:
On Fri, 30 Apr 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
No, I agree that that would be foolish ... but there has also been alot
done on the code over the past few months that even *one* of those
features should be enough to put it over the top
I am seeing a hung regression test just after numerology on Unix.
If you set USE_PGTZ to yes in Makefile.global and define USE_PGTZ in
pg_config.h, you might see it too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+
Does ecpg need to use the same timezone database as the backend?
I just committed code so it will not, but I am not sure.
I think it should not use it, for the following reasons:
* When ecpg is used to write a program, this is a client program. I'd
expect a client program to follow the
On Thu, Apr 29, 2004 at 09:30:12PM -0300, Marc G. Fournier wrote:
June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd
to the Win32 Native port being finished ...
I seem to remember the same argument at 7.4 time. I don't use
Windows, I think it's a bletcherous system, but
Bruce Momjian said:
Marc G. Fournier wrote:
No no ... the date isn't floating on Win32 ... the date is floating on
one of the major features (PITR, 2PC, etc) ... if Win32 happens to be the
first major feature, so be it, but it is not contigent on Win32 ...
So you are floating the entire
Bruce Momjian said:
Does ecpg need to use the same timezone database as the backend?
I just committed code so it will not, but I am not sure.
surely all clients should be utterly ignorant of what the backend uses?
cheers
andrew
---(end of
Hello,
Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.
This could also lead to other things. For example if we have Win32 and
PITR calling it 7.5 is a mistake (IMHO) it should
be 8.0
Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.
We could go for September 1st, which would mean most are back from
holidays, in order to do beta testing ... and no, I'm
On Fri, 30 Apr 2004, Joshua D. Drake wrote:
Hello,
Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.
We could go for September 1st, which would mean most are back from
holidays, in order
On Fri, 30 Apr 2004, Joshua D. Drake wrote:
Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.
We could go for September 1st, which would mean most are back from
holidays, in order to
Andrew Dunstan wrote:
Bruce Momjian said:
Does ecpg need to use the same timezone database as the backend?
I just committed code so it will not, but I am not sure.
surely all clients should be utterly ignorant of what the backend uses?
OK, just asking the question to be sure. I was a
Why don't we just set a freeze of August 1st? Give everyone just a
little extra time. No float. If it doesn't make
it by August 1st, it doesn't make it.
We could go for September 1st, which would mean most are back from
holidays, in order to do beta testing ... and no, I'm not
Fabien COELHO [EMAIL PROTECTED] writes:
As a temporary fix, what about _ANY and _SOME as aggregate names?
Ick :-(. The use of leading underscores is an ugly C-ism that we should
not propagate into SQL names.
How about bool_or() and bool_and()? Or at least something based on OR
and AND? I
For me even September 1st does not seem too late. Major version up
bring users pains including backup/restore application
imcompatibilty... IMO to justify those pains we need to give users
major enhancements. Honestly I don't understand why we should rush the
major version up.
I agree with
Tom Lane wrote:
Fabien COELHO [EMAIL PROTECTED] writes:
As a "temporary" fix, what about "_ANY" and "_SOME" as aggregate names?
Ick :-(. The use of leading underscores is an ugly C-ism that we should
not propagate into SQL names.
I second this... the whole __ is
Maybe we should take a vote on the cuttoff date scheduling. Marc, is
this something that can be voted on by the group?
---
Tatsuo Ishii wrote:
Why don't we just set a freeze of August 1st? Give everyone just a
little
Alvaro Herrera [EMAIL PROTECTED] writes:
Is this expected? If so, why? I'd expect the prepared stmt to be
deallocated.
prepare.c probably should have provisions for rolling back its state to
the start of a failed transaction ... but it doesn't.
Before jumping into doing that, though, I'd
On Fri, 30 Apr 2004, Bruce Momjian wrote:
Maybe we should take a vote on the cuttoff date scheduling. Marc, is
this something that can be voted on by the group?
At this time, no ... in a months time, let's revisit it and see where the
various things are sitting ... quite frankly, we've spent
I am getting farther with the timezone library on Unix.
First, I realized that the share/timezone library doesn't have a
localtime file by default, so the PostgreSQL server doesn't know the
local timezone. I added that and got:
test= select current_timestamp;
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
strace'ing the postmaster suggested me that the dbname string in
utils/init/postinit.c, the InitPostgres function, is the culprit.
In fact, if I apply the following patch to tcop/postgres.c the
whole thing stops happening.
else if (argc
Hi
thanx and sorry that I asked such a simple question in postgres-hackers
list
but the complexity which i feel on that basis please allow me to
explain my problem further.
As i am working on sorting order , length and substring functions for
Hindi text(Indian Language)...
Here is
51 matches
Mail list logo
