Heads up: 7.3.3 this Wednesday

Tom Lane wrote:

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),
God willin' an' the creek don't rise. If anyone's got anything you've
been planning to fix in the 7.3 branch, now is a real good time to get
it done.

Funny you should ask :-)

Here's a fix for a bug in connectby (crashes when called as a targetlist
function instead of as a table function). The patch is against cvs HEAD,
but should also be applied to the 7.3 branch, I think.

Thanks,

Joe

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),
God willin' an' the creek don't rise. If anyone's got anything you've
been planning to fix in the 7.3 branch, now is a real good time to get
it done.

Only thing is that %rowtype and dropped columns business - but I think you
indicated that would be a 7.4 fix...I think it's a bit too complex for me...

Chris

Joe Conway <mail@joeconway.com> writes:

Here's a fix for a bug in connectby (crashes when called as a targetlist
function instead of as a table function). The patch is against cvs HEAD,
but should also be applied to the 7.3 branch, I think.

Right-o, applied in both branches.

regards, tom lane

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Only thing is that %rowtype and dropped columns business - but I think you
indicated that would be a 7.4 fix...I think it's a bit too complex for me...

I think only low-risk bug fixes need apply for 7.3 at this point ... the
dropped-col thing needs some study ...

regards, tom lane

On Fri, 16 May 2003, Tom Lane wrote:

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),
God willin' an' the creek don't rise. If anyone's got anything you've
been planning to fix in the 7.3 branch, now is a real good time to get
it done.

I think Bruce should check his mail box for unapplied patches.
I suspect some of our patches are still waiting for attention.

Oleg

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Oleg Bartunov <oleg@sai.msu.su> writes:

On Fri, 16 May 2003, Tom Lane wrote:

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),

I think Bruce should check his mail box for unapplied patches.
I suspect some of our patches are still waiting for attention.

Bruce is going to be mostly out of the loop on this release (he's out of
town this weekend, and planning a server upgrade Monday). So if you've
got any problems, let me know about 'em.

I have just finished digging through the pgsql-patches archives back to
February, and found only a few small things that seemed appropriate for
back-patching. I do seem to recall seeing some fixes from you and
Teodor recently, though. Could you check REL7_3_STABLE CVS tip against
what you have, and either resubmit any missing patches or point me to
where they're archived?

regards, tom lane

I sended it before (24 Apr), but I don't sure that it applied.

This patch fixes nt[]-int[] operation

Tom Lane wrote:

Oleg Bartunov <oleg@sai.msu.su> writes:

On Fri, 16 May 2003, Tom Lane wrote:

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),

I think Bruce should check his mail box for unapplied patches.
I suspect some of our patches are still waiting for attention.

Bruce is going to be mostly out of the loop on this release (he's out of
town this weekend, and planning a server upgrade Monday). So if you've
got any problems, let me know about 'em.

I have just finished digging through the pgsql-patches archives back to
February, and found only a few small things that seemed appropriate for
back-patching. I do seem to recall seeing some fixes from you and
Teodor recently, though. Could you check REL7_3_STABLE CVS tip against
what you have, and either resubmit any missing patches or point me to
where they're archived?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
Teodor Sigaev E-mail: teodor@sigaev.ru

Teodor Sigaev <teodor@sigaev.ru> writes:

I sended it before (24 Apr), but I don't sure that it applied.
This patch fixes nt[]-int[] operation

Yeah, you're right, it hadn't been applied yet. Done now; thanks!

regards, tom lane

Tom Lane wrote:

pgsql-core have agreed to put out a 7.3.3 release on Wednesday (5/21),
God willin' an' the creek don't rise. If anyone's got anything you've
been planning to fix in the 7.3 branch, now is a real good time to get
it done.

I've seen no problems with the deferred trigger patch (which addresses
a performance issue with deferred triggers) you gave me some time ago.
Is this something that's likely to be included in 7.3.3?

--
Kevin Brown kevin@sysexperts.com

Kevin Brown <kevin@sysexperts.com> writes:

I've seen no problems with the deferred trigger patch (which addresses
a performance issue with deferred triggers) you gave me some time ago.
Is this something that's likely to be included in 7.3.3?

I've been wondering myself about whether to include Jan's patch that
reduces foreign-key deadlocks. Neither of these patches have gotten
enough testing (that I know of) to make me feel very comfortable about
dropping them into 7.3.3 ... but on the other hand, they could be pretty
significant fixes.

Any votes pro or con? Who else can report successful use of either of
these patches?

regards, tom lane

I've seen no problems with the deferred trigger patch (which
addresses a performance issue with deferred triggers) you gave me
some time ago. Is this something that's likely to be included in
7.3.3?

I've been wondering myself about whether to include Jan's patch that
reduces foreign-key deadlocks. Neither of these patches have gotten
enough testing (that I know of) to make me feel very comfortable
about dropping them into 7.3.3 ... but on the other hand, they could
be pretty significant fixes.

Any votes pro or con? Who else can report successful use of either
of these patches?

I've been using the deferred triggers patch in production for about a
month without any problems. I'm definitely for that as well as Jan's
patch, though I haven't used it. Anything to help out FK's and I'm
game. :)

If someone needs the clean patch for 7.3 of the deferred triggers, the
patch is at the URL below. The one originally posted didn't merge 100%
cleanly to my 7.3.2 sources.

http://people.FreeBSD.org/~seanc/patch_postgresql-7.3.2::src::backend::utils::adt::ri_triggers.c

-sc

--
Sean Chittenden

Is is possible to make it a build time switch so many folks can beta test
it for us, so to speak? I'd certainly be willing to test it out a bit,
but we don't have time to test it before 7.3.3 comes out.

That would allow us to basically test the deferred triggers in a
relatively stable code base (7.3) on semi-production machines (i.e. the
ones running batch files at night and such) long before 7.4 goes beta.

Or is it too complex or ugly to put something like that into configure and
the code? Just a thought.

On Fri, 16 May 2003, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

Is is possible to make it a build time switch so many folks can beta test
it for us, so to speak?

I doubt it'd get tested enough to notice, if it's not in the default
build.

I actually think that both of these are pretty good candidates to put
into 7.3.3. I'm just trying to adopt an appropriately paranoid stance
and ask hard questions about how much they've been tested. Between
Kevin and Sean it seems that the deferred-triggers change has gotten
enough testing to warrant some trust, but I'm not hearing anything
about the FK-deadlock one :-(.

BTW, if anyone is looking for that patch, it was at
http://archives.postgresql.org/pgsql-hackers/2003-04/msg00260.php

regards, tom lane

Is is possible to make it a build time switch so many folks can beta test
it for us, so to speak?

I doubt it'd get tested enough to notice, if it's not in the default
build.

I actually think that both of these are pretty good candidates to put
into 7.3.3. I'm just trying to adopt an appropriately paranoid stance
and ask hard questions about how much they've been tested. Between
Kevin and Sean it seems that the deferred-triggers change has gotten
enough testing to warrant some trust, but I'm not hearing anything
about the FK-deadlock one :-(.

BTW, if anyone is looking for that patch, it was at
http://archives.postgresql.org/pgsql-hackers/2003-04/msg00260.php

Are there any test cases to get this bug to fire? I haven't had any
problems with this particular bug so I can apply this patch, but I
can't promise that my use of the patch will result in anything useful
other than, "nothing's broke yet" since I haven't had any real
problems with 7.3.2 other than the deferred trigger speed. Off hand,
I don't see why this patch would cause any problems if it were
applied. -sc

--
Sean Chittenden

Sean Chittenden <sean@chittenden.org> writes:

BTW, if anyone is looking for that patch, it was at
http://archives.postgresql.org/pgsql-hackers/2003-04/msg00260.php

Are there any test cases to get this bug to fire? I haven't had any
problems with this particular bug so I can apply this patch, but I
can't promise that my use of the patch will result in anything useful
other than, "nothing's broke yet" since I haven't had any real
problems with 7.3.2 other than the deferred trigger speed.

"Nothing's broke yet" would be a useful report. I just would like to
see some more mileage on the beast before we let it loose on the
unsuspecting world. Test cases aren't really the point --- we know what
we expect them to do. It's the cases we didn't think of that worry me
at times like this.

regards, tom lane

On Fri, 16 May 2003, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

Is is possible to make it a build time switch so many folks can beta test
it for us, so to speak?

I doubt it'd get tested enough to notice, if it's not in the default
build.

Well, we could reverse that and make it the default, and if you find a FK
problem folks can turn it off.

But that probably is sub optimal too.

Did that 'prevent cluster on partial and non-NULL indexes' patch get
backported?

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

Did that 'prevent cluster on partial and non-NULL indexes' patch get
backported?

This one?

2003-03-02 23:37 tgl

* src/backend/commands/: cluster.c (REL7_3_STABLE), cluster.c:
Prevent clustering on incomplete indexes: partial indexes are
verboten, as are non-amindexnulls AMs unless first column is
attnotnull.

regards, tom lane

I doubt it'd get tested enough to notice, if it's not in the default
build.

I actually think that both of these are pretty good candidates to put
into 7.3.3. I'm just trying to adopt an appropriately paranoid stance
and ask hard questions about how much they've been tested. Between
Kevin and Sean it seems that the deferred-triggers change has gotten
enough testing to warrant some trust, but I'm not hearing anything
about the FK-deadlock one :-(.

BTW, if anyone is looking for that patch, it was at
http://archives.postgresql.org/pgsql-hackers/2003-04/msg00260.php

7.3.2: I applied the above patch and did install and restarted postgresql,
but the 'deadlock detected' error on FK update still exist. The below is
the test case. Someone *advice* me, if it the above mentioned patch is not
intended to address the below case.

Test case:

test_pg=# CREATE TABLE prim_test (id int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'prim_test_pkey'
for table 'prim_test'
CREATE TABLE
test_pg=# CREATE TABLE for_test (id int references prim_test(id), name
text);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE TABLE
test_pg=# INSERT INTO prim_test VALUES ('1');
INSERT 4383707 1
test_pg=# INSERT INTO prim_test VALUES ('2');
INSERT 4383708 1
test_pg=# INSERT INTO for_test VALUES (1, 'foo');
INSERT 4383710 1
test_pg=# INSERT INTO for_test VALUES (2, 'bar');
INSERT 4383711 1

t1:
test_pg=# BEGIN ;
BEGIN
test_pg=# UPDATE for_test set name ='FOO' where id = 1;
UPDATE 1
test_pg=# UPDATE for_test set name ='Bar' where id = 2;
UPDATE 1

t2:
test_pg=# BEGIN ;
BEGIN
test_pg=# UPDATE for_test set name = 'BAR' where id = 2;
UPDATE 1
test_pg=# UPDATE for_test set name = 'Foo' where id = 1;
ERROR: deadlock detected

regards,
bhuvaneswaran