On Sun, 25 Sep 2005, Tom Lane wrote:
Alternatively: why are we forbidding the value 24:00:00 anyway? Is
there a reason not to allow the hours field to exceed 23?
One reason is because it's what the standard demand. Another is that it
isn't a proper time, just like feb 31 isn't a proper date.
Hello,
I have a very old postgres 6.4 installation. I'm trying to connect to it
from a fresh, up-to-date Debian-host, but I'm constantly getting (from DBI
and PHP as well) this error message:
# ./update_dns.pl
DBI connect('dbname=dns;host=sql;authtype=password','dns',...) failed:
On Mon, Sep 26, 2005 at 09:59:53AM +0200, Micha? J?czalik wrote:
Connection with psql works OK. Connecting from different (older) hosts
with DBI/PHP works perfect as well. Something must have changed in recent
versions of libpq and now it doesn't work. I looked into source code and
found
On Mon, 26 Sep 2005, Martijn van Oosterhout wrote:
On Mon, Sep 26, 2005 at 09:59:53AM +0200, Micha? J?czalik wrote:
Connection with psql works OK. Connecting from different (older) hosts
with DBI/PHP works perfect as well. Something must have changed in recent
versions of libpq and now it
Common problem with inheritance is that references work ONLY with top table
and are not propagated to children.
Is it possible to write triggers (like utils/adt/ri_triggers.c) which will
act on INSERT/UPDATE/DELETE and check/cascade/restrict properly ?
pg_attribute, pg_inherits inherits can be
Michal Jeczalik wrote:
On Mon, 26 Sep 2005, Martijn van Oosterhout wrote:
On Mon, Sep 26, 2005 at 09:59:53AM +0200, Micha? J?czalik wrote:
Connection with psql works OK. Connecting from different (older) hosts
with DBI/PHP works perfect as well. Something must have changed in
recent
Actually, I think there is a case where 24:00 is a proper time. Isn't
it used for adding leap seconds ?
Dave
On 26-Sep-05, at 3:39 AM, Dennis Bjorklund wrote:
On Sun, 25 Sep 2005, Tom Lane wrote:
Alternatively: why are we forbidding the value 24:00:00 anyway? Is
there a reason not to
Dave Cramer [EMAIL PROTECTED] writes:
Actually, I think there is a case where 24:00 is a proper time. Isn't
it used for adding leap seconds ?
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
I suppose there's another
=?iso-8859-2?Q?Micha=B3_J=EAczalik?= [EMAIL PROTECTED] writes:
I have a very old postgres 6.4 installation. I'm trying to connect to it
from a fresh, up-to-date Debian-host, but I'm constantly getting (from DBI
and PHP as well) this error message:
# ./update_dns.pl
DBI
Hello pgsql-hackers,
When I try to execute the next SQL statement, sever was crashed:
DELETE FROM ma_data WHERE id in (-1,212803,. );
... - is 500k text like id separated by ,. Its about 10 values.
Run from pgplsql function, like EXECUTE st;.
postgresql-2005-09-25_00.log:
On Mon, Sep 26, 2005 at 10:28:48AM +0200, Michal Jeczalik wrote:
Heh, that's what I'm currently doing, but it's not so easy to compile 6.4
on a new system. configure states that the compiler cannot create
executables, but I ripped this check out of it. Anyway, something goes
wrong while
On Mon, 26 Sep 2005, Tom Lane wrote:
Actually, I think there is a case where 24:00 is a proper time. Isn't
it used for adding leap seconds ?
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
Yes, and it can go up to
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
Yes, and it can go up to 23:59:60.99 (depending on how many fractional
seconds one want).
On Mon, 26 Sep 2005, Tom Lane wrote:
Yes, and it can go up to 23:59:60.99 (depending on how many fractional
seconds one want).
That's an urban legend. There never have been, and never will be, two
leap seconds instituted in the same minute. We really should reject
anything larger
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?= [EMAIL PROTECTED]
writes:
When I try to execute the next SQL statement, sever was crashed:
DELETE FROM ma_data WHERE id in (-1,212803,. );
... - is 500k text like id separated by ,. Its about 10 values.
I wouldn't be too
[ looking again... ]
=?Windows-1251?Q?=C0=ED=E4=F0=E5=E9_=D0=E5=EF=EA=EE?= [EMAIL PROTECTED]
writes:
max_stack_depth = 65536 # min 100, size in KB
Hmm, maybe this is the problem. Are we sure Windows will allow a 64M stack?
regards, tom lane
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 26 September 2005 15:47
To: Андрей Репко
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Server process exited with unexpected
status 128.
[ looking again... ]
Dave Page dpage@vale-housing.co.uk writes:
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
max_stack_depth = 65536 # min 100, size in KB
Hmm, maybe this is the problem. Are we sure Windows will
allow a 64M stack?
Looks like we used 4MB in the backend by default:
Tom Lane [EMAIL PROTECTED] writes:
That's an urban legend. There never have been, and never will be, two
leap seconds instituted in the same minute. We really should reject
anything larger than '23:59:60'.
I don't understand. The last second of a normal minute goes from 59.0 to
59.999
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 26 September 2005 16:01
To: Dave Page
Cc: Андрей Репко; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Server process exited with unexpected
status 128.
Dave Page dpage@vale-housing.co.uk writes:
On 9/26/05, Dennis Bjorklund wrote:
On Sun, 25 Sep 2005, Tom Lane wrote:
Alternatively: why are we forbidding the value 24:00:00 anyway? Is
there a reason not to allow the hours field to exceed 23?
One reason is because it's what the standard demand.
Could you cite that? The only thing I
On Mon, 26 Sep 2005, Tom Lane wrote:
=?iso-8859-2?Q?Micha=B3_J=EAczalik?= [EMAIL PROTECTED] writes:
I have a very old postgres 6.4 installation. I'm trying to connect to it
from a fresh, up-to-date Debian-host, but I'm constantly getting (from DBI
and PHP as well) this error message:
#
Joshua D. Drake wrote:
Hannu Krosing wrote:
On L, 2005-09-24 at 20:25 -0700, Joshua D. Drake wrote:
Actually this also probably would not gain you much in 8.1
as vacuum in theory is already dealing with itself.
Interesting. Could you explain it in a more detailed way ?
How does
Jochem van Dieten [EMAIL PROTECTED] writes:
On 9/26/05, Dennis Bjorklund wrote:
One reason is because it's what the standard demand.
Could you cite that? The only thing I can find in the SQL standard is
that the hour field in an INTERVAL can not exceed 23, not datetimes.
SQL99 has
Dennis Bjorklund [EMAIL PROTECTED] writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If TD is the datetime data
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
No, I think the usual notation for a leap-second is '23:59:60'.
We do allow 60 in the seconds field for this purpose.
Yes, and it can go up to 23:59:60.99 (depending on how many fractional
On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote:
Joshua D. Drake wrote:
Autovacuum is integrated into the backend for 8.1
Can I set the autovacuum parameter per table instead of per
engine ?
Yes.
--
Alvaro Herrera Architect,
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Do the sql standard say anything on the matter?
It doesn't seem very helpful. AFAICS, we should interpret storing
'23:59:59.99' into a TIME(0) field as a cast from TIME(2) to TIME(0),
and the spec defines that as
15) If TD
On Mon, 26 Sep 2005, Tom Lane wrote:
b) If SD is TIME WITHOUT TIME ZONE, then TV is SV, with
implementation-defined rounding or truncation if necessary.
So it's implementation-defined what we do.
Truncation would avoid the problem but of course loses some of the
On Mon, 26 Sep 2005, Michael Paesold wrote:
to be something else than the libpq expects. But how to fix it?! Has the
protocol change or what?
Umm, I think the protocol version is up to 3 or 4 now. I think libpq
supports all the way back to 7.0, I don't know if anyone tests earlier
than that.
We have what may be a bug in beta2. We have two databases running beta2,
one on Linux and one on Windows. The hardware is identical. The
configurate files are identical. They are being fed identical streams
of data modifications (primarily inserts, very few deletes). We've been
running this
Patch applied. Thanks.
---
Marko Kreen wrote:
On Fri, Aug 12, 2005 at 10:27:16PM -0400, Bruce Momjian wrote:
Where are we going with this patch? It doesn't test specific OS's known
to fail.
I hoped people more
Here are the open items for 8.1:
PostgreSQL 8.1 Open Items
=
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or
from http://www.postgresql.org/developer/beta.
Changes
---
Win32 signal
Folks,
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant effort to parse. For
example, pqa, a very
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
b) If SD is TIME WITHOUT TIME ZONE, then TV is SV, with
implementation-defined rounding or truncation if necessary.
So it's implementation-defined what we do.
IMHO Since 23:59:59.99 probably means the last milliseconds of this
day,
[ Joe, would you review this? ]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
/contrib move to pgfoundry
Is this actually happening?
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG -
On 9/26/05, David Fetter [EMAIL PROTECTED] wrote:
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard
Tom Lane wrote:
Hm, so the proposal is round unless that would produce 24:00:00, in
which case truncate? Seems a bit ugly but it would follow the letter
of the spec, and avoid rejecting inputs that we used to accept. It's
still not very clear what to do with '23:59:60.9' though.
I'd handle
-Original Message-
From: Ron Peacetree [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 24, 2005 3:31 AM
To: Dann Corbit; pgsql-hackers@postgresql.org; pgsql-
[EMAIL PROTECTED]
Subject: RE: [HACKERS] [PERFORM] Releasing memory during External
sorting?
From: Dann Corbit [EMAIL
David Fetter wrote:
Simple logging is a default that should probably not change, but I'm
thinking that for people who want to find something out from the logs,
we could see about a kind of plugin architecture which would enable
things like:
* CSV
* YAML
* XML
* Piped logs, as Apache can do
Interesting. I am thinking we could put markers like '|' in the log
output, and then have some secondary process either remove them or add
special formatting to match the requested output format.
---
David Fetter wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new
Joshua D. Drake wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
/contrib move to pgfoundry
Is this actually happening?
Josh has talked about it, but not sure where he is.
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still
David Fetter wrote:
Folks,
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now, they're (sometimes just barely ;)
human-readable, but they take significant effort to parse. For
Joshua D. Drake [EMAIL PROTECTED] writes:
/contrib move to pgfoundry
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new servers.
The modules proposed to be moved out aren't actively maintained now;
if they were
On Sun, Sep 25, 2005 at 10:10:22AM +0300, Hannu Krosing wrote:
Also, not sure if this matters, but they're occasionally getting errors
like 'Did not find relation named table that exists' (where 'table
that exists' is the name of some table that is in the catalog) from \d.
Does anyone know
On Sun, Sep 25, 2005 at 11:50:14AM -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Perhaps VACUUM could send some statistics after each N pages and this
would then be available through something similar to pg_statistics
table.
Why not just have it send some text to be
On Sat, Sep 24, 2005 at 08:25:30PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
Would it be difficult to vacuum as part of a dump? The reasoning behind
this is that you have to read the table to do the dump anyway, so it
would be a good time to be able to piggy-back other operations
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
- query is truncated due to UDP restrictions.
Are you confusing the logs with pg_stat_activity?
Not confused. I'm talking about the case where statement logging is
enabled, I could have mentioned that...
Regards,
Andreas
As a work-around, you can use the scripts at
http://cvs.distributed.net/viewcvs.cgi/stats-sql/tools/
On Thu, Sep 22, 2005 at 02:16:58PM -0400, Jonathan Beit-Aharon wrote:
Hi,
I'm not a member of this list, so please CC me on responses and
discussion.
After a system crash PostgreSQL startup
On Sun, Sep 25, 2005 at 10:10:22AM +0300, Hannu Krosing wrote:
On L, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c
David Fetter wrote:
...log file formats in 8.0
* CSV
* YAML
* XML
* Piped logs, as Apache can do
* DB handle. I know this one will be controversial.
[...]
1. Am I the only one who would wants an option for machine-readable logs?
I'd very much like a format that can be easily loaded into
Andreas Pflug [EMAIL PROTECTED] writes:
- query is truncated due to UDP restrictions.
Are you confusing the logs with pg_stat_activity?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Jim C. Nasby [EMAIL PROTECTED] writes:
* Add options to pg_config to show the share_dir, sysconfdir,
pkgincludedir, and localedir
Should that be marked as a beginner TODO?
It could, but I think it's going to get DONE in the next few days as
a necessary step in fixing the pgxs relocatability
Jim C. Nasby [EMAIL PROTECTED] writes:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
It's presumably mostly in the pg_table_is_visible() calls. Not sure if
we can do much to speed those up, but: how
Should that be marked as a beginner TODO?
On Thu, Sep 22, 2005 at 11:04:23PM -0400, Bruce Momjian wrote:
Added to TODO:
* Add options to pg_config to show the share_dir, sysconfdir,
pkgincludedir, and localedir
On Mon, Sep 26, 2005 at 01:13:08PM -0400, Christopher Petrilli wrote:
On 9/26/05, David Fetter [EMAIL PROTECTED] wrote:
I've run into something that concerns me. It's pretty much an 8.2
issue, but I'm hoping to stimulate some discussion on it. It's
PostgreSQL's log files. Right now,
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
/contrib move to pgfoundry
Well pgFoundry isn't ready to have a load of code that is
that actively maintained put on it. It still needs to be moved to
its new servers.
The modules proposed to be moved out
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
The modules proposed to be moved out aren't actively maintained now;
if they were we'd probably be keeping them in core.
Speaking as a pgFoundry admin, I would say if they aren't actively
maintained we don't want them either.
On Mon, Sep 26, 2005 at 01:23:03PM -0500, Jim C. Nasby wrote:
Is there any particular reason why psql doesn't re-run a query that
failed due to disconnect from the server after re-connecting? I've
thought maybe it's because it might somehow be dangerous, but I can't
think of any case where
From: Ron Peacetree [EMAIL PROTECTED]
Sent: Sep 24, 2005 6:30 AM
Subject: Re: [HACKERS] [PERFORM] Releasing memory during External sorting?
... the amount of IO done is the most
important of the things that you should be optimizing for in
choosing an external sorting algorithm.
snip
Since
Is there any particular reason why psql doesn't re-run a query that
failed due to disconnect from the server after re-connecting? I've
thought maybe it's because it might somehow be dangerous, but I can't
think of any case where that's actually true.
--
Jim C. Nasby, Sr. Engineering Consultant
Bruce Momjian wrote:
[ Joe, would you review this? ]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
The patch itself is
Changes
---
Win32 signal handling patch (Magnus)
Unless someone else steps up to doing this one, please remove it from
the list. I will not have time to dig into this patch before 8.1.
//Magnus
---(end of broadcast)---
TIP 9: In versions
Jim C. Nasby [EMAIL PROTECTED] writes:
Is there any particular reason why psql doesn't re-run a query that
failed due to disconnect from the server after re-connecting? I've
thought maybe it's because it might somehow be dangerous, but I can't
think of any case where that's actually true.
You
Tom Lane wrote:
Speaking as a pgFoundry admin, I would say if they aren't actively
maintained we don't want them either. pgFoundry is not a dumping ground
for modules that are dying.
I didn't say they were dying --- the ones we thought were dead, we
already dropped. I was responding
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Ron Peacetree
Sent: Monday, September 26, 2005 10:47 AM
To: pgsql-hackers@postgresql.org; pgsql-performance@postgresql.org
Subject: [HACKERS] [PERFORM] A Better External Sort?
From:
On Sat, Sep 24, 2005 at 12:13:11PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
For that matter, we can't even guarantee that they work at all: not
all platforms even *have* int64 types.
What platforms that PG
Ron,
Having rested my brain for the last few days, your theory made for
interesting reading... Rather than argue the technical specs, I'd
love to see an implementation :)
-JonahOn 9/26/05, Dann Corbit [EMAIL PROTECTED] wrote:
-Original Message- From: [EMAIL PROTECTED]
Jim C. Nasby [EMAIL PROTECTED] writes:
So what happens if you attempt to put a value greater than 2^32 into a
bigint on a non-int64 platform?
You get the same error as if you tried to store a value greater than 2^64.
regards, tom lane
---(end of
I had originally been planning to back-port this fix:
http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
as far as 7.2. I've completed the back-port as far as 7.3, but found
that 7.2 would be significantly more work because the API of
heap_fetch() would need to change from what
Hi,
On Mon, 26 Sep 2005, Tom Lane wrote:
snipped
This brings up the question of whether we should officially abandon
support for 7.2 and/or later branches. I don't think anyone is planning
on supporting old branches forever, but when do we stop?
I have a corporate need to keep supporting
If a database is created with a 64 bit version of initdb, would a 32bit
backend be able to talk to it? Likewise, would a backend compiled by a
different compiler be able to?
If there was some kind of incompatability, would the backend just refuse
to start, or would it start and start silently
Devrim GUNDUZ [EMAIL PROTECTED] writes:
There are some 7.3 users around (I remember some on Slony lists, etc),
therefore we should keep supporting it. But maybe we can announce that
7.3 will become unsupported after XXX time so that people will know
before we abandon the support. The best
Jim C. Nasby [EMAIL PROTECTED] wrote
If a database is created with a 64 bit version of initdb, would a 32bit
backend be able to talk to it? Likewise, would a backend compiled by a
different compiler be able to?
The key problem I believe is the serials of ALIGNOF macros. Especially for
Gerbil's looking better lately:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=gerbilbr=REL8_0_STABLE
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Qingqing Zhou [EMAIL PROTECTED] writes:
Jim C. Nasby [EMAIL PROTECTED] wrote
If a database is created with a 64 bit version of initdb, would a 32bit
backend be able to talk to it? Likewise, would a backend compiled by a
different compiler be able to?
The key problem I believe is the serials
Tom Lane wrote:
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like X amount of time after the release of the
following major version. But X probably has to depend on how big
the compatibility gotchas are in the following version, so we're still
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Tom Lane wrote:
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like X amount of time after the release of the
following major version. But X probably has to depend on how big
the compatibility gotchas are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
3. How to show that a value is continued? As you can see below I use
...
I remember a discussion on this before but couldn't find it in the
archives. Either a reference or some other hints would be appreciated.
I think we liked the + character.
I looked at the recently noted problem that pgxs builds only work
if the installation paths recorded in Makefile.global are accurate;
which pretty much breaks our claim to supporting relocatable
installations.
What I propose we do about this is change the path setup section
of Makefile.global to
Michael Fuhr [EMAIL PROTECTED] writes:
Gerbil's looking better lately:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=gerbilbr=REL8_0_STABLE
Yeah. We've been poking at it off-list, and it seems that the problem
was a local build failure due to not having a clean copy of the
repository (ye
[ Forgot to answer this part ]
Devrim GUNDUZ [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
I have a corporate need to keep supporting 7.3, at least to the extent
of critical bug fixes, because Red Hat is still on the hook to support
that version in RHEL3 for awhile longer.
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: We will attempt to maintain support
of each major version for 3 years after its release, although this will
not always be possible. After that time any major support
Alvaro Herrera wrote:
On Mon, Sep 26, 2005 at 05:41:24PM +0200, Gaetano Mendola wrote:
Joshua D. Drake wrote:
Autovacuum is integrated into the backend for 8.1
Can I set the autovacuum parameter per table instead of per
engine ?
Yes.
Finally :-)
good work.
Regards
Gaetano Mendola
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: We will attempt to maintain support
of each major version for 3 years after its release, although this will
not always be possible. After that
Jim C. Nasby wrote:
If a database is created with a 64 bit version of initdb, would a 32bit
backend be able to talk to it? Likewise, would a backend compiled by a
different compiler be able to?
Not in my experience at least from going 32 bit intel to 64bit opteron.
If there was some kind
On Mon, 26 Sep 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: We will attempt to maintain support
of each major version for 3 years after its release, although this will
not always be possible.
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
I'd prefer to measure the time from the release of the follow-on
version, so I'd make it 2 years from release of following major
version; that would give people a clearer idea of the time frame
in which they're
This sounds reasonable to me ... I think it is more then most software
projects do, isn't it?
To translate that into reality: 7.2 (2002-02-04) would be dead already,
and 7.3 (2002-11-27) will be dead around the time we are likely to
release 8.1. Do people feel comfortable with that? It
Joshua D. Drake [EMAIL PROTECTED] writes:
I think there should be levels of support.
There already are, in that only fairly major bugs get backpatched to the
way-back releases. I think that's right --- the older a release is, the
more it means that people still using it value stability over the
On Mon, Sep 26, 2005 at 05:57:08PM -0400, Tom Lane wrote:
I had originally been planning to back-port this fix:
http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
as far as 7.2. I've completed the back-port as far as 7.3, but
found that 7.2 would be significantly more work
The question at hand is when are we willing to pull the plug
completely and declare that even security holes and data-loss risks
won't get fixed.
It is definitely a sensitive issue because we (my community hat on) want
to make sure
and not alienate people because we won't support a version
Tom,
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that. I'm hesitant to push that idea very hard myself, because it would
On Mon, Sep 26, 2005 at 09:27:28PM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: We will attempt to maintain support
of each major version for 3 years after
A nice pg_upgrade utility would make a big difference. Clearly an
in-place upgrade is possible, but maintaining is hard. There are two
broad ways of running a pg_upgrade project - one that is entirely
independent of the main codebase and one that puts requirements on the
main codebase
Steve Atkins [EMAIL PROTECTED] writes:
We'll be skipping 8.0 completely and the next step will probably be to
8.1.something (or possibly 8.2.something, depending on how bizgres
looks in 3 months time).
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no*
There are several places in both backend and tools that forget to check the
return value of malloc(). For example(8.0.1),
backend/port/dynloader/beos.c/pg_dlopen()
backend/bootstrap/bootstrap.c/AddStr()
port/strdup.c/strdup()
bin/pg_dump/common.c/findParentsByOid()
...
I am
1 - 100 of 105 matches
Mail list logo
