Thread: list server problems?
Hi! I am getting mails from this list <pgsql-general@postgresql.org> although - AFAIR :-) - I do not have subscribed. Masi
Same here...... > Hi! > > I am getting mails from this list <pgsql-general@postgresql.org> although - AFAIR :-) - I do not have subscribed. > > Masi > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
2003 m. Sausio 28 d., Antradienis 10:38: > Hi! > > I am getting mails from this list <pgsql-general@postgresql.org> although - > AFAIR :-) - I do not have subscribed. And you are not alone ;-) -- Marius Žalinauskas
I subscribed once or twice, over 6 months ago, but never received any mail from the list (until now). Maybe someone's fixed what was broken? Gizmo wrote: > > Same here...... > > > Hi! > > > > I am getting mails from this list <pgsql-general@postgresql.org> > although - AFAIR :-) - I do not have subscribed. > > > > Masi -- Regards, Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. "Um ... those are IP addresses the quarterback guy yells out, right?" "No, A.J. ... they're wild guesses at your I.Q." -- User Friendly
IT'S FIXED!!!!!!!!!!!!!!!!! Now that was a shock... Tony Grant -- www.tgds.net Library management software toolkit, redhat linux on Sony Vaio C1XD, Dreamweaver MX with Tomcat and PostgreSQL
Same here. Looks like someone mass subscribed us. Gizmo (gizmo@thegremlins.net) wrote: > Same here...... > > > > Hi! > > > > I am getting mails from this list <pgsql-general@postgresql.org> > although - AFAIR :-) - I do not have subscribed. > > > > Masi > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html
On 28 Jan 2003 at 5:13, Travis Bauer wrote: > Same here. Looks like someone mass subscribed us. Or mass initialized the general list with already known pg guys..;-) Regards, Shridhar ----------------------------------------------------------- Shridhar Daithankar LIMS CPE Team Member, PSPL. mailto:shridhar_daithankar@persistent.co.in Phone:- +91-20-5678900 Extn.270 Fax :- +91-20-5678901 -----------------------------------------------------------
On Tue, 28 Jan 2003, Shridhar Daithankar wrote: > On 28 Jan 2003 at 5:13, Travis Bauer wrote: > > > Same here. Looks like someone mass subscribed us. > > Or mass initialized the general list with already known pg guys..;-) Are the efforts in progress to unsubscribe those of us who shouldn't be subscribed? Regards. Gordan
Daryl Tester wrote: > I subscribed once or twice, over 6 months ago A fine time for a "ME TOO!" I subscribed lonnnnnggg ago, wrote the list manager OVER and OVER about not receiving list messages...NEVER a response... I switched to MySQL... :-/ -Ron
Hi! I have following problem: I have created a table with some fields, then I dropped last field (integer) and added one extra field (integer). Then I have created a function which returns record of table type. I have selected a record from table and returned it, but the values in last field are wrong (missing). It looks like that it takes the dropped field instead of the last field. Damjan CREATE OR REPLACE FUNCTION damjan_test111(integer) RETURNS public.fk_test AS ' DECLARE rec fk_test%ROWTYPE; siteid ALIAS FOR $1; BEGIN FOR rec IN SELECT * FROM public.fk_test WHERE i = siteid LOOP RETURN rec; END LOOP; END; ' LANGUAGE 'plpgsql';
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I subscribed once or twice, over 6 months ago the same for me. Subscribed posted and unsubscribed long ago too. I have not subscribed again . Should I unsubscribe again myself ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+No6X33a3jGkLTgcRAqnSAJsEPr3jyz3unPs6QQg/Niw2xbs5wQCgjbH2 gyzWAAc93l5k6UEGkbixPQ4= =oA5P -----END PGP SIGNATURE-----
At 05:19 28.1.2003 -0800, Ron wrote the following message: >A fine time for a "ME TOO!" I subscribed lonnnnnggg ago, wrote the list >manager OVER and OVER about not receiving list messages... I had problems only with general lists, other lists were working fine. I used newsgroup during this time and Elen's summaries. >NEVER a >response... Well, all these people have other work to do as well. We should respect that. >I switched to MySQL... :-/ Just because of that? Pity. Pgsql is very nice database which needs some quality time from its users to perform even better. Tomaz
I shut everything down last night and rebuilt the subscriber database for pgsql-general (it was corrupted) ... apologies to those that may have unsubscribed at some point, and are now re-subscribed ... the rebuild process doesn't seem to know how to deal with that too well yet ... On Tue, 28 Jan 2003, Daryl Tester wrote: > I subscribed once or twice, over 6 months ago, but never received > any mail from the list (until now). Maybe someone's fixed what > was broken? > > Gizmo wrote: > > > > Same here...... > > > > > Hi! > > > > > > I am getting mails from this list <pgsql-general@postgresql.org> > > although - AFAIR :-) - I do not have subscribed. > > > > > > Masi > > > > -- > Regards, > Daryl Tester, Software Wrangler and Bit Herder, IOCANE Pty. Ltd. > > "Um ... those are IP addresses the quarterback guy yells out, right?" > "No, A.J. ... they're wild guesses at your I.Q." -- User Friendly > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
On Tue, 28 Jan 2003, Gordan Bobic wrote: > On Tue, 28 Jan 2003, Shridhar Daithankar wrote: > > > On 28 Jan 2003 at 5:13, Travis Bauer wrote: > > > > > Same here. Looks like someone mass subscribed us. > > > > Or mass initialized the general list with already known pg guys..;-) > > Are the efforts in progress to unsubscribe those of us who shouldn't be > subscribed? No, as we don't know who shouldn't be subscribeed ... plesae send in an unsubscribe request to get back off the list ...
Please unsubscribe me.
Sorry, but one of the replies I got implies that I need a password to unsubscribe. I don't have it any more. Can you please remove me off the list? Thanks. Gordan
Unsubscribe me thanx
On Tue, 28 Jan 2003 10:40 am, you wrote: > Same here...... > > > Hi! > > > > I am getting mails from this list <pgsql-general@postgresql.org> > > although - AFAIR :-) - I do not have subscribed. Same here. I am subscribed to newsgroup only. -- Peter Nixon mailto:peter@peternixon.net Phone: +90 535 3707 126 http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Tuesday 28 January 2003 09:38, you wrote: > I am getting mails from this list <pgsql-general@postgresql.org> although - > AFAIR :-) - I do not have subscribed. me too... -- Il male non cresce mai così bene come quando ha un ideale davanti a sè (Karl Kraus) ----------------------------------------------------------------- gianpaolo racca gianpaolo@preciso.net http://www.preciso.net
Dear Administrator/Moderator,
I had subscribed to this group and I need only the digest version.
But I am getting every post to this group as an individual mail. I
understand there was some problem with this earlier. Has it been
solved? What should I do to get only the digest version. Thanking you,
Yours sincerely,
D.Shanmugasundaram.
On Tue, 2003-01-28 at 14:15, gianpaolo racca wrote:
> On Tuesday 28 January 2003 09:38, you wrote:
> > I am getting mails from this list <pgsql-general@postgresql.org> although -
> > AFAIR :-) - I do not have subscribed.
>
> me too...
>
> --
> Il male non cresce mai così bene come quando ha
> un ideale davanti a sè (Karl Kraus)
> -----------------------------------------------------------------
> gianpaolo racca
> gianpaolo@preciso.net
> http://www.preciso.net
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
On Wed, 29 Jan 2003, Francisco J Reyes wrote: > On Tue, 28 Jan 2003, Marc G. Fournier wrote: > > > No, as we don't know who shouldn't be subscribeed ... plesae send in an > > unsubscribe request to get back off the list ... > > > Was/is there a simmilar problem with ther performance list? Several months > back when the announcement was sent about the performance list I tried > several times to subscribe, but never got a notification. There might have been, but right now a verification of all databases comes up with no error (please note, this is not a PgSQL database backend, Majordomo2 uses a DB3 backend) ... you migth try again and see, as I know the list itself is fairely active ...
unsubscribe
Please unsubscribe me too. -- %HAV-A-NICEDAY email mailto:steve@zeropps.uklinux.net Steve web http://www.zeropps.uklinux.net/ or http://start.at/zero-pps 1:24am up 38 days, 1:44, 1 user, load average: 1.00, 1.05, 1.18
On Tue, 28 Jan 2003, Marc G. Fournier wrote: > No, as we don't know who shouldn't be subscribeed ... plesae send in an > unsubscribe request to get back off the list ... Was/is there a simmilar problem with ther performance list? Several months back when the announcement was sent about the performance list I tried several times to subscribe, but never got a notification.
unsubscribe
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Christopher Kings-Lynne wrote:
> I want to fix this bug, however I can't see how the example below is
> failing... (Obeys dropped columns) I'm not up with my SRFs, so would
> someone be able to post a concise SQL script that demonstrates the failure?
>
> I can see in the code that it should be failing, but I need a demonstrated
> example...
Here is a self contained example using cvs tip:
CREATE TABLE fk_test (f1 int, f2 int);
insert into fk_test(f1, f2) values(1, 21);
insert into fk_test(f1, f2) values(2, 22);
ALTER TABLE fk_test DROP COLUMN f2;
ALTER TABLE fk_test ADD COLUMN f3 int;
insert into fk_test(f1, f3) values(3, 33);
insert into fk_test(f1, f3) values(4, 34);
regression=# select * from fk_test ;
f1 | f3
----+----
1 |
2 |
3 | 33
4 | 34
(4 rows)
CREATE OR REPLACE FUNCTION test()
RETURNS SETOF fk_test AS '
DECLARE
rec fk_test%ROWTYPE;
BEGIN
FOR rec IN SELECT * FROM fk_test LOOP
RETURN NEXT rec;
END LOOP;
RETURN;
END;
' LANGUAGE 'plpgsql';
regression=# select * from test();
f1 | f3
----+----
1 |
2 |
3 |
4 |
(4 rows)
Joe
Christopher Kings-Lynne wrote:
> I want to fix this bug, however I can't see how the example below is
> failing... (Obeys dropped columns) I'm not up with my SRFs, so would
> someone be able to post a concise SQL script that demonstrates the failure?
>
> I can see in the code that it should be failing, but I need a demonstrated
> example...
Taking it a bit further...
CREATE TABLE fk_test (f1 int, f2 int);
insert into fk_test(f1, f2) values(1, 21);
insert into fk_test(f1, f2) values(2, 22);
ALTER TABLE fk_test DROP COLUMN f2;
ALTER TABLE fk_test ADD COLUMN f3 int;
insert into fk_test(f1, f3) values(3, 33);
insert into fk_test(f1, f3) values(4, 34);
CREATE OR REPLACE FUNCTION test()
RETURNS SETOF fk_test AS '
DECLARE
rec fk_test%ROWTYPE;
BEGIN
FOR rec IN SELECT * FROM fk_test LOOP
RETURN NEXT rec;
END LOOP;
RETURN;
END;
' LANGUAGE 'plpgsql';
regression=# select * from test();
f1 | f3
----+----
1 |
2 |
3 |
4 |
(4 rows)
regression=# ALTER TABLE fk_test DROP COLUMN f3;
ALTER TABLE
regression=# select * from test();
f1
----
1
2
3
4
(4 rows)
regression=# ALTER TABLE fk_test ADD COLUMN f3 int;
ALTER TABLE
regression=# select * from test();
WARNING: Error occurred while executing PL/pgSQL function test
WARNING: line 5 at return next
ERROR: Wrong record type supplied in RETURN NEXT
CREATE OR REPLACE FUNCTION test()
RETURNS SETOF fk_test AS '
DECLARE
rec fk_test%ROWTYPE;
BEGIN
FOR rec IN SELECT * FROM fk_test LOOP
RETURN NEXT rec;
END LOOP;
RETURN;
END;
' LANGUAGE 'plpgsql';
regression=# select * from test();
f1 | f3
----+----
1 |
2 |
3 |
4 |
(4 rows)
Joe
Joe Conway <mail@joeconway.com> writes:
> Taking it a bit further...
There are (at least) two distinct problems involved here. One is
getting plpgsql to deal correctly with rowtypes that include dropped
columns. The other is getting it to react when someone alters a table
whose rowtype is relied on by already-compiled functions.
The former problem is just a small matter of programming in plpgsql;
I'm not sure what the best way to do it is, but it's clearly just
plpgsql's issue. The latter problem calls for a ton of infrastructure
that we haven't got :-(
regards, tom lane
Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: > > Taking it a bit further... > > There are (at least) two distinct problems involved here. One is > getting plpgsql to deal correctly with rowtypes that include dropped > columns. The other is getting it to react when someone alters a table > whose rowtype is relied on by already-compiled functions. > > The former problem is just a small matter of programming in plpgsql; > I'm not sure what the best way to do it is, but it's clearly just > plpgsql's issue. The latter problem calls for a ton of infrastructure > that we haven't got :-( Hmm, well... - Keeping timestamps of when the table definition was last changed and when the function was last compiled, and then having the language interpreter check the two before executing the function (and recompile it when the function is out of date) would solve the problem (and require relatively little additional infrastructure), but I would expect the performance hit to be too high to be worth it. - Alternatively, the language compiler could record a dependency between the function and the table (assuming this isn't done already), and be told to recompile the function when the table definition changes. This gets real messy when you're talking about doing this in a transaction, unless the compilation itself is something that can be rolled back (it wouldn't surprise me in the least if the compiled definition is stored in a table already and thus can be rolled back). - Alternatively, recompilation could be made a manual thing, e.g. ALTER FUNCTION blah RECOMPILE. It would still be a win for this to be transaction-capable. -- Kevin Brown kevin@sysexperts.com
Is there any TODO's here? --------------------------------------------------------------------------- Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: > > Taking it a bit further... > > There are (at least) two distinct problems involved here. One is > getting plpgsql to deal correctly with rowtypes that include dropped > columns. The other is getting it to react when someone alters a table > whose rowtype is relied on by already-compiled functions. > > The former problem is just a small matter of programming in plpgsql; > I'm not sure what the best way to do it is, but it's clearly just > plpgsql's issue. The latter problem calls for a ton of infrastructure > that we haven't got :-( > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073