Thread: 7.1.2 release
Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight as 7.1.2. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 20:47 10/05/01 -0400, Bruce Momjian wrote: >Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight >as 7.1.2. > I have not applied the latest pg_dump patches, and I'm still working on a problem with the view extract. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Thu, 10 May 2001, Bruce Momjian wrote: > Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight > as 7.1.2. Not that I'm aware of ... I heard mention something about a couple of fixes, but we *just* put out 7.1.1 ... If ppl are affected by the bugs, use cvsup and set yoru tag to REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ...
> On Thu, 10 May 2001, Bruce Momjian wrote: > > > Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight > > as 7.1.2. > > Not that I'm aware of ... I heard mention something about a couple of > fixes, but we *just* put out 7.1.1 ... > > If ppl are affected by the bugs, use cvsup and set yoru tag to > REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ... That is fine. I am not crazy about doing it now either. It is just that Tom mentioned early in the week we need a release, and you said how about Friday. I will brand 7.1.2 so it is ready whenever we want it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> On Thu, 10 May 2001, Bruce Momjian wrote: > > > Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight > > as 7.1.2. > > Not that I'm aware of ... I heard mention something about a couple of > fixes, but we *just* put out 7.1.1 ... > > If ppl are affected by the bugs, use cvsup and set yoru tag to > REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ... > In fact, we can easily create a patch for this fix. It is only a few lines. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> That is fine. I am not crazy about doing it now either. It is just
> that Tom mentioned early in the week we need a release, and you said how
> about Friday. I will brand 7.1.2 so it is ready whenever we want it.
I think I said Friday, not Marc ... and I didn't hear anyone else
agreeing with me anyway ;-)
We should certainly wait until Philip is happy with the state of
pg_dump. Right now I don't know of any other open issues.
regards, tom lane
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> I agree with you because the bug is very critical.
Yes, I'd like to get that plpgsql bug fix out as soon as possible.
But the pg_dump things that Philip is fixing are important too,
so I think we should wait a couple more days for those.
(Philip, we are just talking about a few days, right?)
regards, tom lane
Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > That is fine. I am not crazy about doing it now either. It is just > > that Tom mentioned early in the week we need a release, and you said how > > about Friday. I will brand 7.1.2 so it is ready whenever we want it. > > I think I said Friday, not Marc ... and I didn't hear anyone else > agreeing with me anyway ;-) > Hmm I've thought no one has any objection :-). I agree with you because the bug is very critical. regards, Hiroshi Inoue
On Thu, 10 May 2001, Tom Lane wrote: > Hiroshi Inoue <Inoue@tpf.co.jp> writes: > > I agree with you because the bug is very critical. > > Yes, I'd like to get that plpgsql bug fix out as soon as possible. Isn't this only critical for those that are using it? Does it affect those that don't use plpgsql?
While you guys are still awake, I may as well ask this:
I gather that the following code goes though the heap and removes all check
contraints associated with a particular table, but how do I extend the code
to match both a table relid and the constraint name? Basically I'm just
asking how I express 'SQL SELECT' queries using the heap access functions?
rcrel = heap_openr(RelCheckRelationName, RowExclusiveLock);ScanKeyEntryInitialize(&key, 0, Anum_pg_relcheck_rcrelid,
F_OIDEQ, RelationGetRelid(rel));
rcscan = heap_beginscan(rcrel, 0, SnapshotNow, 1, &key);
while (HeapTupleIsValid(tup = heap_getnext(rcscan, 0))) simple_heap_delete(rcrel, &tup->t_self);
heap_endscan(rcscan);heap_close(rcrel, RowExclusiveLock);
Cheers,
Chris
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Friday, 11 May 2001 10:43 AM
> To: Hiroshi Inoue
> Cc: Bruce Momjian; Philip Warner; The Hermit Hacker;
> PostgreSQL-development
> Subject: Re: [HACKERS] 7.1.2 release
>
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > I agree with you because the bug is very critical.
>
> Yes, I'd like to get that plpgsql bug fix out as soon as possible.
>
> But the pg_dump things that Philip is fixing are important too,
> so I think we should wait a couple more days for those.
> (Philip, we are just talking about a few days, right?)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
The Hermit Hacker <scrappy@hub.org> writes:
> Isn't this only critical for those that are using it? Does it affect
> those that don't use plpgsql?
No, but I think it's pretty critical for those that do ...
regards, tom lane
At 22:43 10/05/01 -0400, Tom Lane wrote: >(Philip, we are just talking about a few days, right?) Yes - it's waiting on the problem Zoltan reported (the select from pg_rewrite etc). I can't reproduce the problem on any of my DBs. If worst comes to worst, I have a (nasty) workaround, but I'm more worried that it might reflect a larger problem with the way I have used column-select expressions in pg_dump. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> I gather that the following code goes though the heap and removes all check
> contraints associated with a particular table, but how do I extend the code
> to match both a table relid and the constraint name?
Add another ScanKey. Look at uses of ScanKeyEntryInitialize for examples.
regards, tom lane
Philip Warner <pjw@rhyme.com.au> writes:
> Yes - it's waiting on the problem Zoltan reported (the select from
> pg_rewrite etc). I can't reproduce the problem on any of my DBs.
I've just realized that the problem is a lot simpler than it appears.
The given string is too long for a NAME:
regression=# select ('_RET' || 'szallitolevel_tetele_ervenyes')::name; ?column?
---------------------------------_RETszallitolevel_tetele_erveny
(1 row)
When you write
select oid from pg_rewrite where rulename='_RETszallitolevel_tetele_ervenyes'
the unknown-type literal is coerced to NAME --- ie truncated --- and
then the comparison works. But when you write
select oid from pg_rewrite where rulename='_RET' || 'szallitolevel_tetele_ervenyes'
the result of the || will be type TEXT not type NAME. So the rulename
gets promoted to TEXT and texteq is used ... with the result that
_RETszallitolevel_tetele_ervenye does not match
_RETszallitolevel_tetele_ervenyes.
Solution: don't use ||, or explicitly cast its result to NAME:
select oid from pg_rewrite where rulename=('_RET' || 'szallitolevel_tetele_ervenyes')::name
regards, tom lane
At 01:28 11/05/01 -0400, Tom Lane wrote: >Philip Warner <pjw@rhyme.com.au> writes: >> Yes - it's waiting on the problem Zoltan reported (the select from >> pg_rewrite etc). I can't reproduce the problem on any of my DBs. > >I've just realized that the problem is a lot simpler than it appears. >The given string is too long for a NAME: Ung. That's a bit nasty for views: pjw=# create view szallitolevel_tetele_erveny01 as select * from t1; CREATE pjw=# create view szallitolevel_tetele_erveny02 as select * from t1; ERROR: Attempt to insert rule "_RETszallitolevel_tetele_erveny" failed: already exists But at least I can fix pg_dump now. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Thu, 10 May 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > Isn't this only critical for those that are using it? Does it affect > > those that don't use plpgsql? > > No, but I think it's pretty critical for those that do ... So, why not create a quick patch for those that need it, and let those with the capability pull from CVS/CVSup ... that is why we have them setup ...
Bruce Momjian writes: > Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight > as 7.1.2. Make sure you are labelling the documentation with the correct version. Thomas should set up his documentation build area for the current and stable branches, and Marc has to make sure that the mk-release picks up the right one. Right now it would probably pick up current, which is definitely not right. Man, this should be easier. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Philip Warner <pjw@rhyme.com.au> writes:
> I have not applied the latest pg_dump patches, and I'm still working on a
> problem with the view extract.
Philip, I see you applied some pg_dump patches yesterday. Have you
resolved all your outstanding issues, or is there still more you want
to do before 7.1.2?
regards, tom lane
> Bruce Momjian writes: > > > Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight > > as 7.1.2. > > Make sure you are labelling the documentation with the correct version. > Thomas should set up his documentation build area for the current and > stable branches, and Marc has to make sure that the mk-release picks up > the right one. Right now it would probably pick up current, which is > definitely not right. Man, this should be easier. I have stamped the SGML version file for each release appropriately. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 13:47 12/05/01 -0400, Tom Lane wrote: > >Philip, I see you applied some pg_dump patches yesterday. Have you >resolved all your outstanding issues, or is there still more you want >to do before 7.1.2? > Everything I know about is resolved. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
>> Philip, I see you applied some pg_dump patches yesterday. Have you
>> resolved all your outstanding issues, or is there still more you want
>> to do before 7.1.2?
> Everything I know about is resolved.
Okay, good. I did some experimentation this afternoon with dumping the
7.0 regression database using both native 7.0 pg_dump and the
current-sources one. Seemed to work pretty well, though I did make one
change: I think we should assume proisstrict = FALSE when dumping from a
7.0 db, not TRUE. The forcing consideration for this is that I was
getting "isstrict" markers on plpgsql_call_handler, which would be a
really nasty problem if it got into the field: people would report that
they couldn't get plpgsql functions to work with NULLs, and we'd be
unable to duplicate the misbehavior. More generally, it doesn't matter
for old C functions, because the fmgr_oldstyle wrapper will cause the
right things to happen, and I don't think we want to force strictness
for SQL or PL functions. (That's why I chose CREATE FUNCTION's default
to be non strict...)
regards, tom lane