8.1 Release Candidate 1 Bundled ...

Started by Marc G. Fournierabout 20 years ago6 messages
#1Marc G. Fournier
scrappy@postgresql.org

Take a look through it, will announce this evening ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

#2Devrim GUNDUZ
devrim@gunduz.org
In reply to: Marc G. Fournier (#1)
Re: 8.1 Release Candidate 1 Bundled ...

Hi,

On Sun, 30 Oct 2005, Marc G. Fournier wrote:

Take a look through it, will announce this evening ...

Could you please include RPMs in your announcement? They *will* be here:

http://developer.postgresql.org/~devrim/rpms/8.1/rc1

Regards,
--
Devrim GUNDUZ
Kivi Bili�im Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

From pgsql-hackers-owner@postgresql.org Sun Oct 30 06:34:51 2005

X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 94707DB3AE
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Sun, 30 Oct 2005 06:34:50 -0400 (AST)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 18217-05
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Sun, 30 Oct 2005 10:34:48 +0000 (GMT)
Received: from mail.nederland.net (mail.nederland.net [83.137.20.15])
by svr1.postgresql.org (Postfix) with ESMTP id 3CEA8DB3AD
for <pgsql-hackers@postgresql.org>; Sun, 30 Oct 2005 06:34:49 -0400 (AST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by romeo.computel.nl (Postfix) with ESMTP id D63C9141E9;
Sun, 30 Oct 2005 11:34:51 +0100 (CET)
Received: from mail.nederland.net ([127.0.0.1])
by localhost (romeo.computel.nl [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 06056-03; Sun, 30 Oct 2005 11:34:51 +0100 (CET)
Received: from balefirehome (balefire.demon.nl [212.238.240.59])
by romeo.computel.nl (Postfix) with ESMTP id 0FB70141E8;
Sun, 30 Oct 2005 11:34:50 +0100 (CET)
Message-ID: <002001c5dd3d$928d3b40$64c8a8c0@balefirehome>
From: "Sander Steffann" <steffann@nederland.net>
To: "Martijn van Oosterhout" <kleptog@svana.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <josh@agliodbs.com>,
"PostgreSQL-development" <pgsql-hackers@postgresql.org>
References: <200510281734.11285.josh@agliodbs.com> <7702.1130560067@sss.pgh.pa.us> <001f01c5dc87$e81a2390$64c8a8c0@balefirehome> <20051029131313.GD17490@svana.org> <11787.1130607762@sss.pgh.pa.us>
Subject: Re: FKs on temp tables: hard, or just omitted?
Date: Sun, 30 Oct 2005 11:34:56 +0100
Organization: Computel Standby BV
MIME-Version: 1.0
Content-Type: text/plain;
format=flowed;
charset="Windows-1252";
reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.023 required=5 tests=[AWL=0.023]
X-Spam-Score: 0.023
X-Spam-Level:
X-Archive-Number: 200510/1371
X-Sequence-Number: 75230

Hi,

Martijn van Oosterhout <kleptog@svana.org> writes:

You solve it by allowing other backends to lock and examine your
temporary tables. But AIUI temporary tables are not stored in shared
memory so how do you get a consistant view of it?

Not unsolvable, but very tricky.

Right, the problem isn't that "it can't be done", it's that "it can't be
done without giving up most of the performance advantages of temp tables".
Which seems like a bad tradeoff, at least to me ...

Ah, now I understand the problem :-)

And I think you are right. It would be a very bad tradeoff.
Sander

#3Magnus Hagander
mha@sollentuna.net
In reply to: Devrim GUNDUZ (#2)
Re: 8.1 Release Candidate 1 Bundled ...

Take a look through it, will announce this evening ...

Could you please include RPMs in your announcement? They
*will* be here:

http://developer.postgresql.org/~devrim/rpms/8.1/rc1

The developer.postgresql.org machine really isn't geared to handle
downloads.. Any reason you can't just stick it on the standard ftp sites
and have it mirrored along with everything else?

//Magnus

#4Devrim GUNDUZ
devrim@gunduz.org
In reply to: Magnus Hagander (#3)
Re: 8.1 Release Candidate 1 Bundled ...

Hi,

On Sun, 30 Oct 2005, Magnus Hagander wrote:

http://developer.postgresql.org/~devrim/rpms/8.1/rc1

The developer.postgresql.org machine really isn't geared to handle
downloads.. Any reason you can't just stick it on the standard ftp sites
and have it mirrored along with everything else?

This is taken from our spec:
# Pre-release RPM's should not be put up on the public ftp.postgresql.org server
# -- only test releases or full releases should be.

So thinking that:

* Beta and RC RPMs are used only by testers
* We use the beta and RC steps to build the new RPM sets, so that means
that actually they are not production quality looking from the RPM
perspective.

That's why I put them to developer site.

Another reason was that gunduz.org was unavailable for 2 months (and
putting the PGDG RPMs to my site does not sound good).

Regards,
--
Devrim GUNDUZ
Kivi Bili�im Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

From pgsql-hackers-owner@postgresql.org Sun Oct 30 17:32:21 2005

X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id B514BDA860;
Sun, 30 Oct 2005 17:32:18 -0400 (AST)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 49659-01; Sun, 30 Oct 2005 21:32:16 +0000 (GMT)
Received: from mx-2.sollentuna.net (mx-2.sollentuna.net [195.84.163.199])
by svr1.postgresql.org (Postfix) with ESMTP id 03D89DA696;
Sun, 30 Oct 2005 17:32:17 -0400 (AST)
Received: from ALGOL.sollentuna.se (janus.sollentuna.se [62.65.68.67])
by mx-2.sollentuna.net (Postfix) with ESMTP
id 456DF8F284; Sun, 30 Oct 2005 22:32:18 +0100 (CET)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: Re: 8.1 Release Candidate 1 Bundled ...
Date: Sun, 30 Oct 2005 22:32:12 +0100
Message-ID: <6BCB9D8A16AC4241919521715F4D8BCE92E7D1@algol.sollentuna.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [HACKERS] 8.1 Release Candidate 1 Bundled ...
thread-index: AcXdl9xj6wRa/807TRKbPwsG4HC65wAAUAPg
From: "Magnus Hagander" <mha@sollentuna.net>
To: "Devrim GUNDUZ" <devrim@gunduz.org>
Cc: "Marc G. Fournier" <scrappy@postgresql.org>,
<pgsql-hackers@postgresql.org>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.034 required=5 tests=[AWL=0.034]
X-Spam-Score: 0.034
X-Spam-Level:
X-Archive-Number: 200510/1380
X-Sequence-Number: 75239

http://developer.postgresql.org/~devrim/rpms/8.1/rc1

The developer.postgresql.org machine really isn't geared to handle=20
downloads.. Any reason you can't just stick it on the standard ftp=20
sites and have it mirrored along with everything else?

=20
This is taken from our spec:
# Pre-release RPM's should not be put up on the public=20
ftp.postgresql.org server # -- only test releases or full=20
releases should be.
=20
So thinking that:
=20
* Beta and RC RPMs are used only by testers
* We use the beta and RC steps to build the new RPM sets, so=20
that means that actually they are not production quality=20
looking from the RPM perspective.
=20
That's why I put them to developer site.
=20
Another reason was that gunduz.org was unavailable for 2=20
months (and putting the PGDG RPMs to my site does not sound good).

I agree with that part about gunduz.org. But I think it'd be better to
just have a separate subdirectory for beta/rc:s on the ftp site. There
is already a http://www.postgresql.org/ftp/binary/v8.1beta/ which has
the win32 beta/rc files, so I suggest adding required dirs and put the
RPMs there.

//Magnus

#5Lamar Owen
lowen@pari.edu
In reply to: Devrim GUNDUZ (#4)
Re: 8.1 Release Candidate 1 Bundled ...

The developer.postgresql.org machine really isn't geared to handle
downloads.. Any reason you can't just stick it on the standard ftp sites
and have it mirrored along with everything else?

This is taken from our spec:
# Pre-release RPM's should not be put up on the public ftp.postgresql.org
server
# -- only test releases or full releases should be.

So thinking that:

* Beta and RC RPMs are used only by testers
* We use the beta and RC steps to build the new RPM sets, so that means
that actually they are not production quality looking from the RPM
perspective.

By way of clarification, as I am the one who wrote that portion of the
spec file, an 'RPM prerelease' and a 'beta' weren't intended to be the
same thing; the line in the spec referenced was for my own use to remind
me that my own internal testing packages (with a release number 0.x)
weren't intended for public consumption. Devrim, you can remove that
section of the spec file at any time at this point, because you are using
CVS for the purpose that I was using 'prerelease' RPMs.

Historically, beta and release candidate RPM's were put on the main ftp
site but flagged as beta quality. I certainly appreciate your dilligence
in following those instructions I wrote long ago, but, thanks to your
smoother release process (in no small part due to the use of CVS) those
instructions are obsolete. Many thanks for being that dilligent!
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

#6Devrim GUNDUZ
devrim@gunduz.org
In reply to: Lamar Owen (#5)
Re: 8.1 Release Candidate 1 Bundled ...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Lamar,

On Mon, 31 Oct 2005, Lamar Owen wrote:

So thinking that:

* Beta and RC RPMs are used only by testers
* We use the beta and RC steps to build the new RPM sets, so that means
that actually they are not production quality looking from the RPM
perspective.

By way of clarification, as I am the one who wrote that portion of the
spec file, an 'RPM prerelease' and a 'beta' weren't intended to be the
same thing; the line in the spec referenced was for my own use to remind
me that my own internal testing packages (with a release number 0.x)
weren't intended for public consumption. Devrim, you can remove that
section of the spec file at any time at this point, because you are using
CVS for the purpose that I was using 'prerelease' RPMs.

Ok, I've removed that part from the spec files.

Historically, beta and release candidate RPM's were put on the main ftp
site but flagged as beta quality. I certainly appreciate your dilligence
in following those instructions I wrote long ago, but, thanks to your
smoother release process (in no small part due to the use of CVS) those
instructions are obsolete. Many thanks for being that dilligent!

:) Ok, I will be putting the beta and RC RPMs to FTP site from now on.

Regards,
- --
Devrim GUNDUZ
Kivi Bili�im Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDZ9Is4zE8DGqpiZARAku+AJ90HZHQNUeLQ+a7zy7ge2hFvNpLegCgqD0U
2yf2pDfmsSGrZZDBWBf7yZU=
=Wxyt
-----END PGP SIGNATURE-----

From pgsql-hackers-owner@postgresql.org Tue Nov 1 16:48:47 2005

X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 4A6FBDB6D3
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Tue, 1 Nov 2005 16:48:46 -0400 (AST)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 15212-07
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Tue, 1 Nov 2005 20:48:43 +0000 (GMT)
Received: from mx1.surnet.cl (mx1.surnet.cl [216.155.73.180])
by svr1.postgresql.org (Postfix) with ESMTP id 2C83BDB6CA
for <pgsql-hackers@postgresql.org>; Tue, 1 Nov 2005 16:48:43 -0400 (AST)
Received: from unknown (HELO cluster.surnet.cl) ([216.155.73.165])
by mx1.surnet.cl with ESMTP; 01 Nov 2005 17:50:39 -0300
X-IronPort-AV: i="3.97,276,1125892800";
d="scan'208"; a="21448617:sNHT33648240"
Received: from alvh.no-ip.org (200.85.218.142) by cluster.surnet.cl (7.0.043) (authenticated as alvherre@surnet.cl)
id 4350159700225AD6; Tue, 1 Nov 2005 17:48:45 -0300
Received: by alvh.no-ip.org (Postfix, from userid 1000)
id 0EE9DC2D450; Tue, 1 Nov 2005 17:49:49 -0300 (CLST)
Date: Tue, 1 Nov 2005 17:49:48 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Chris Browne <cbbrowne@acm.org>
Cc: pgsql-hackers@postgresql.org
Subject: Re: slru.c race condition
Message-ID: <20051101204948.GC21459@surnet.cl>
Mail-Followup-To: Chris Browne <cbbrowne@acm.org>,
pgsql-hackers@postgresql.org
References: <D1D2D51E3BE3FC4E98598248901F759402C88F12@ausmail2k4.aus.pervasive.com> <15543.1130714273@sss.pgh.pa.us> <20051031234731.GQ20349@pervasive.com> <20051101000259.GE12906@surnet.cl> <20051101005604.GU20349@pervasive.com> <21073.1130814779@sss.pgh.pa.us> <20051101142355.GB17904@surnet.cl> <20051101184944.GD20349@pervasive.com> <603bmg9mvb.fsf@dba2.int.libertyrms.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <603bmg9mvb.fsf@dba2.int.libertyrms.com>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=1.666 required=5 tests=[AWL=-0.253,
DNS_FROM_RFC_ABUSE=0.479, DNS_FROM_RFC_POST=1.44]
X-Spam-Score: 1.666
X-Spam-Level: *
X-Archive-Number: 200511/31
X-Sequence-Number: 75313

Chris Browne wrote:

jnasby@pervasive.com ("Jim C. Nasby") writes:

On Tue, Nov 01, 2005 at 11:23:55AM -0300, Alvaro Herrera wrote:

Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

AFAIK they're not using subtransactions at all, but I'll check.

Well, yeah, they are ... else you'd never have seen this failure.

Maybe it's in plpgsql EXCEPTION clauses.

Err, I forgot they're using Slony, which is probably using savepoints
and/or exceptions.

Slony-I does use exceptions in pretty conventional ways; it does *not*
make any use of subtransactions, because it needs to run on PG 7.3 and
7.4 that do not support subtransactions.

Hmm, does it use the BEGIN/EXCEPTION/END construct at all? Because if
it does, it won't work on 7.4; and if it doesn't, then it isn't using
savepoints in 8.0 either.

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Siempre hay que alimentar a los dioses, aunque la tierra est� seca" (Orual)