AW: [HACKERS] Re: timeout on lock feature
"Henryk Szal" [EMAIL PROTECTED] writes: YES, this feature should affect ALL locks. 'Timeout on lock' parameter says to server "I CAN'T WAIT WITH THIS TRANSACTION TOO LONG BECAUSE OF (ANY) LOCK", It still seems to me that what such an application wants is not a lock timeout at all, but an overall limit on the total elapsed time for the query. If you can't afford to wait to get a lock, why is it OK to wait (perhaps much longer) for I/O or computation? Yes, that is a valid argument. The only thing I can counter is that (in OLTP) it is usually easy to predict the amount of work that needs to be done for your own tx (we are typically talking about 1 - 200 ms here), but it is not easy to predict how long another session needs to complete it's transaction (the other session might be OLAP, vacuum ...). Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Another news story in need of 'enlightenment'
Thus spake Lamar Owen
This one probably needs the 'iron hand and the velvet paw' touch. The
iron hand to pound some sense into the author, and the velvet paw to
make him like having sense pounded into him. Title of article is 'Open
Source Databases Won't Fly' --
http://www.dqindia.com/content/enterprise/datawatch/101041201.asp
I'm not sure there was even a point in there. The article was rambling
and undirected. Completely apart from any content, this just seemed like
a badly written article. I'm not sure that it even merits consideration
in this forum.
I guess anyone can be published on the net.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
AW: [HACKERS] [BUG] views and functions on relations
In latest 7.1 (checked out 2 days ago from CVS), I see following behaviour: create table foo(x int4); create function xx(foo) returns int4 as ' return 0;' language 'plpgsql'; create view tv2 as select xx(foo) from foo; regression=# create function xx(foo) returns int4 as ' return 0;' language 'plpgsql'; CREATE regression=# \d tv2 ERROR: cache lookup of attribute 0 in relation 145121 failed Above function does not compile: regression=# select * from tv2; NOTICE: plpgsql: ERROR during compile of xx near line 1 ERROR: parse error at or near "return" Try to see whether the problem persists with a valid function. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Strange behaviour of to_date()
On Tue, Apr 17, 2001 at 07:46:19PM +0200, Mario Weilguni wrote:
I noticed a quite strange behaviour of to_char() in 7.0 and 7.1. It treats
abbreveated forms of a date completely wrong. Example:
-- this one is ok
mario=# select to_date('04.01.2001', 'dd.mm.');
to_date
2001-01-04
-- this is completly wrong, but NO error raised
mario=# select to_date('4.01.2001', 'dd.mm.');
to_date
0001-01-04
-- completly wrong as well
mario=# select to_date('4.1.2001', 'dd.mm.');
to_date
0001-01-04
Really bug? What you obtain from 'dd.mm.' in to_char()
test=# select to_char('04.01.2001'::date, 'dd.mm.');
to_char
04.01.2001
(1 row)
'04.01.2001' and '4.1.2001' are *different* strings with *different*
format masks
See (and read docs):
test=# select to_char('04.01.2001'::date, 'FMdd.FMmm.');
to_char
--
4.1.2001
(1 row)
test=# select to_date('4.1.2001', 'FMdd.FMmm.');
to_date
2001-01-04
(1 row)
Yes, Oracle support using not exact format mask, but Oracle's to_date
is very based on date/time and not support others things:
SVRMGR select to_date('333.222.4.1.2001', '333.222.FMdd.FMmm.') from
dual;
TO_DATE('
-
ORA-01821: date format not recognized
test=# select to_date('333.222.4.1.2001', '333.222.FMdd.FMmm.');
to_date
2001-01-04
(1 row)
or nice:
test=# select to_date('33304333.1.2001', '333dd333.FMmm.');
to_date
2001-01-04
(1 row)
And primarily Oracle's to_date() is designed for operation that in
PG is solved via timestamp/date cast. For example you can use in
Oracle to_date('4.1.2001') without format mask and it's same thing
as 4.1.2001::date cast('4.1.2001' as date) in PG.
The to_char()/to_date() works as say docs :-)
Better support for not exact masks is in my TODO fo 7.2.
Karel
--
Karel Zak [EMAIL PROTECTED]
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Another news story in need of 'enlightenment'
I can't seem to get at the original anymore, but we talked to Dr.
Soparkar, and is posted a 'followup' of the article to:
http://linuxtoday.com/news_story.php3?ltsn=2001-04-16-009-21-PS-EL-HE-0038
Since I can't seem to get to the original on dqindia.com, I can't comment
on what's changed ...
On Wed, 18 Apr 2001, D'Arcy J.M. Cain wrote:
Thus spake Lamar Owen
This one probably needs the 'iron hand and the velvet paw' touch. The
iron hand to pound some sense into the author, and the velvet paw to
make him like having sense pounded into him. Title of article is 'Open
Source Databases Won't Fly' --
http://www.dqindia.com/content/enterprise/datawatch/101041201.asp
I'm not sure there was even a point in there. The article was rambling
and undirected. Completely apart from any content, this just seemed like
a badly written article. I'm not sure that it even merits consideration
in this forum.
I guess anyone can be published on the net.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Re: No printable 7.1 docs?
Perhaps I'm stuck in the eighties when I did my thesis in LaTeX, but I was of the impression that what's considered good style in LaTeX *is* content-based markup. Sure, a LaTeXer may occasionally be forced to throw in low-level stuff like a \pagebreak to get nice looking results ... but I fail to understand how this is different from the output-oriented tweaking you do to the current Postgres docs. That particular operation is the same, and done for the same reasons. I'll submit that the time I take tweaking output for hardcopy is no more time that would be spent tweaking latex to get optimal appearance. Except that the LaTeXer does it once. You have to do it over again from scratch, very laboriously, every time you want to generate good output. This is a step forward? Not true. If you embed pagebreak commands *in the source* then those breaks *must* be reevaluated every time the docs change. If content is added or removed, the appropriate place for a page break will likely change, so things must be tweaked again. From source, not from something close to final form. Bottom line: I see very little reason to believe that SGML + available tools represents any real technical advance over TeX + its available tools. In fact, if one wants decent-looking output it seems to be a substantial regression. Perhaps it's only that TeX has more than a ten-year lead in being developed into a usable tool, but from what I can see from here, the SGML tools we are using are incredibly inferior to what's been available for a long time for TeX. No argument that TeX is a wonderful tool. But it is trading one set of problems for another, not fixing every criticism you have. At the moment, my life will be easier without having to argue religion, so I can get back to preparing docs ;) - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: No printable 7.1 docs?
Thomas Lockhart [EMAIL PROTECTED] writes: This is a step forward? Not true. If you embed pagebreak commands *in the source* then those breaks *must* be reevaluated every time the docs change. If content is added or removed, the appropriate place for a page break will likely change, so things must be tweaked again. Of course, but my point is that you don't have to revisit such decisions in areas of the docs that haven't changed since last time. The importance of this depends on the stability of the docs, naturally... No argument that TeX is a wonderful tool. But it is trading one set of problems for another, not fixing every criticism you have. Agreed --- but the toolchain we are currently using seems to have considerably more than its fair share of problems. At the moment, my life will be easier without having to argue religion, so I can get back to preparing docs ;) Certainly we aren't going to change toolchains at this point in the 7.1 cycle. I'm just opining that it would make sense to take another look at an SGML-to-TeX-based process in the future --- especially if we have someone who is willing to put active effort into improving the docs toolchain. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AW: [HACKERS] timeout on lock feature
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: It is not something that makes anything unrelyable or less robust. How can you argue that? The presence of a lock timeout *will* make operations fail that otherwise would have succeeded; moreover that failure will be pretty unpredictable (at least from the point of view of the application that issued the command). That qualifies as "unreliable and not robust" in my book. A persistent SET variable also opens up the risk of completely unwanted failures in critical operations --- all you have to do is forget to reset the variable when the effect is no longer wanted. (Murphy's Law guarantees that you won't find out such a mistake until the worst possible time. That's even less robust.) The only way PG could apply reasonable timeouts would be for the application to dictate them, That is exactly what we are talking about here. The *real* problem is that the application cannot determine reasonable timeouts either. Perhaps the app can decide how long it is willing to wait overall, but how can it translate that into the low-level notion of an appropriate lock timeout? It does not know how many locks might get locked in the course of a query, nor which locks they are exactly, nor what the likely distribution of wait intervals is for those locks. Given that, using a lock timeout "feature" is just a crapshoot. If you say "set lock timeout X", you have no real idea how that translates to application-visible performance nor how big a risk you are taking of inducing unwanted failures. You don't even get to average out the uncertainty across a whole query, because if any one of the lock waits exceeds X, your query blows up. Yet making X large destroys the usefulness of the feature entirely, so there will always be a strong temptation to set it too low. This is the real reason why I've been holding out for restricting the feature to a specific LOCK TABLE statement: if it's designed that way, at least you know which lock you are applying the timeout to, and have some chance of being able to estimate an appropriate timeout. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUG] views and functions on relations
Alex Pilosov [EMAIL PROTECTED] writes: In latest 7.1 (checked out 2 days ago from CVS), I see following behaviour: create table foo(x int4); create function xx(foo) returns int4 as ' return 0;' language 'plpgsql'; create view tv2 as select xx(foo) from foo; users=# \d tv2 ERROR: cache lookup of attribute 0 in relation 21747 failed Okay, this is a simple oversight in ruleutils.c: the rule dumper doesn't have logic to handle whole-tuple function arguments, such as (foo) in the above example. Will fix. HOWEVER, 'select * from tv2' succeeds (sometimes). Sometimes it fails with the same error (cache lookup failed). The ruleutils.c bug cannot explain this however, since ruleutils won't even be invoked. Can you find a sequence to reproduce it? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
AW: AW: [HACKERS] timeout on lock feature
It is not something that makes anything unrelyable or less robust. How can you argue that? The presence of a lock timeout *will* make operations fail that otherwise would have succeeded; moreover that failure will be pretty unpredictable (at least from the point of view of the application that issued the command). That qualifies as "unreliable and not robust" in my book. A persistent SET variable also opens up the risk of completely unwanted failures in critical operations --- all you have to do is forget to reset the variable ?? So what, when you e.g. forget to commit you are also in trouble, I do not see anything special here. when the effect is no longer wanted. (Murphy's Law guarantees that you won't find out such a mistake until the worst possible time. That's even less robust.) My OLTP clients set it to 30 sec right after connect and leave it at that. The only way PG could apply reasonable timeouts would be for the application to dictate them, That is exactly what we are talking about here. The *real* problem is that the application cannot determine reasonable timeouts either. Perhaps the app can decide how long it is willing to wait overall, Yes, that is it. As I tried to explain earlier, the amount of work that needs to be done for the own tx (in OLTP) is pretty well predictable, but the work of other clients is not. but how can it translate that into the low-level notion of an appropriate lock timeout? It does not know how many locks might get locked in the course of a query, nor which locks they are exactly, nor what the likely distribution of wait intervals is for those locks. The above would imho be a wrong approach at determining the timeout. Given that, using a lock timeout "feature" is just a crapshoot. If you say "set lock timeout X", you have no real idea how that translates to application-visible performance nor how big a risk you are taking of inducing unwanted failures. You don't even get to average out the uncertainty across a whole query, because if any one of the lock waits exceeds X, your query blows up. Yet making X large destroys the usefulness of the feature entirely, so there will always be a strong temptation to set it too low. This is the real reason why I've been holding out for restricting the feature to a specific LOCK TABLE statement: if it's designed that way, at least you know which lock you are applying the timeout to, and have some chance of being able to estimate an appropriate timeout. I do not agree, but such is life :-) BTW: for distributed txns you need a lock timeout feature anyway, because detecting remote deadlocks between two or more different servers would be very complicated. And I do think PostgreSQL will need remote db access a la long. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] theory of distributed transactions / timeouts
"A Z" == Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
PS: where can I find more on the distributed txn plans for PostgreSQL? Thanks.
A Z BTW: for distributed txns you need a lock timeout feature
A Z anyway, because detecting remote deadlocks between two or
A Z more different servers would be very complicated. And I do
A Z think PostgreSQL will need remote db access a la long.
A typical distributed transaction management system would consist of
- a transaction manager for that particular transaction
- an associated log manager
- an optional associated lock manager (depending on transaction type:
pessimistic, optimistic, etc)
- one or more resource managers (usually storage)
and thus the lock manager would have a single point of reference for
the existence of a transaction or not. The "distributed" part in that
scenario would be that one {log|lock|resource} manager could be client
to several transaction managers simultaneously. The problem of
deadlock detection is that of cyclic dependency-detection among
several transaction managers. Pessimistic Transaction Managers do use
locks and understand their semantics, thus they can communicate with
their peers that are accessing the shared pool of locks.
I would agree that the simplest solution for deadlock detection is a
timeout, but it certainly is not the only one.
Most desirable would be a measure to choose which transaction to
abort, which simultaneously avoids starvation (no more cycles, ever
for txn X), upper limits (txns beyond X objects / locks / cycles /
... cannot happen), etc.. A timeout mechanism is not going to
approach this measure, but an analysis of the dependency matrix with
the associated information on resource usage of each transaction might
get close.
so long,
Oliver
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE: AW: [HACKERS] timeout on lock feature
This is the real reason why I've been holding out for restricting the feature to a specific LOCK TABLE statement: if it's designed that way, at least you know which lock you are applying the timeout to, and have some chance of being able to estimate an appropriate timeout. As I pointed before - it's half useless. And I totally do not understand why to object feature 1. that affects users *only when explicitly requested*; 2. whose implementation costs nothing - ie has no drawbacks for overall system. It was general practice in project so far: if user want some feature and it doesn't affect others - let's do it. What's changed? Vadim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [BUG] views and functions on relations
On Wed, 18 Apr 2001, Tom Lane wrote: The ruleutils.c bug cannot explain this however, since ruleutils won't even be invoked. Can you find a sequence to reproduce it? Sorry, I was mistaken. The error I get for select is this: ERROR: cache lookup for type 0 failed This is a far harder to trigger bug, and actually, it doesn't happen in this simple case (oops), and the only test case I have involves 2 tables and 3 stored procedures. It is not related to views at all, just doing the underlying select causes the problem. Taking out _any_ stored procedure from the query removes the problem. FWIW, this is what I see in server error log: ERROR: cache lookup for type 0 failed DEBUG: Last error occured while executing PL/pgSQL function cust_name DEBUG: while putting call arguments to local variables And this is the query: SELECT cust_name(a) FROM customers AS a, addresses AS b WHERE b.cust_id=a.cust_id and b.oid=get_billing_record(a.cust_id) and cust_balance(a.cust_id)0 Removing either get_billing_record or cust_balance conditions or cust_name selection leaves the problem. Unfortunately, each function is very long, and involves lots of tables and it'd make no sense to post this all to the list, so I'm going to try to narrow down the problem more to get a good reproducible result, but if the above helps any in diagnostic, it'd be great ;) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [PATCHES] Fix for psql core dumping on bad user
D. Hageman writes: The postgresql interactive terminal will dump core on any script that is run via the -f command line option if their exists a connect line without a valid user. An example connect line is in one of the attached files. Okay, I've found the problem. When the connection fails, psql momentarily runs without a valid database connection. When it does that, the multibyte encoding has the invalid value -1. (You need to compile with multibyte enabled to reproduce this.) With that value, PQmblen() has trouble when it parses the next line. Perhaps PQmblen() should simply return 1 when it is passed an invalid encoding. In any case it should do better than dump core. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] [BUG?] tgconstrrelid doesn't survive a dump/restore
tgconstrrelid (in pg_trigger) holds table references in a RI trigger.
The value in this field is not successfully recreated after a
dump/restore.
---
If I create a simple relationship:
create table p (id int primary key);
create table c (pid int references p);
and query the system table for the RI triggers:
select tgrelid, tgname, tgconstrrelid from pg_trigger
where tgisconstraint;
I get (as expected) the trigger information:
tgrelid | tgname | tgconstrrelid
-++---
29122 | RI_ConstraintTrigger_29135 | 29096
29096 | RI_ConstraintTrigger_29137 | 29122
29096 | RI_ConstraintTrigger_29139 | 29122
(3 rows)
However, if I dump this database:
[joel@olympus joel]$ pg_dump -sN test1 | grep -v - -- test1
CREATE TABLE "p" (
"id" integer NOT NULL,
Constraint "p_pkey" Primary Key ("id")
);
CREATE TABLE "c" (
"id" integer NOT NULL
);
CREATE CONSTRAINT TRIGGER "unnamed" AFTER INSERT OR UPDATE ON
"c" NOT DEFERRABLE INITIALLY
IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE
"RI_FKey_check_ins" ('unnamed',
'c', 'p', 'UNSPECIFIED', 'id', 'id');
CREATE CONSTRAINT TRIGGER "unnamed" AFTER DELETE ON "p" NOT
DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW EXECUTE PROCEDURE "RI_FKey_noaction_del" ('unnamed',
'c', 'p', 'UNSPECIFIED', 'id', 'id');
CREATE CONSTRAINT TRIGGER "unnamed" AFTER UPDATE ON "p" NOT
DEFERRABLE INITIALLY IMMEDIATE
FOR EACH ROW EXECUTE PROCEDURE "RI_FKey_noaction_upd" ('unnamed',
'c', 'p', 'UNSPECIFIED', 'id', 'id');
If I drop the database and recreate from the dump:
drop database test1;
create database test1 with template=template0;
\c test1
\i test1
and re-run the query on the pg_trigger table:
select tgrelid, tgname, tgconstrrelid from pg_trigger
where tgisconstraint;
PG has lost the information on which table was being referred to
(tgconstrrelid):
tgrelid | tgname | tgconstrrelid
-++---
29155 | RI_ConstraintTrigger_29168 | 0
29142 | RI_ConstraintTrigger_29170 | 0
29142 | RI_ConstraintTrigger_29172 | 0
(3 rows)
Thee referential integrity still *works* though --
test1=# insert into p values (1);
INSERT 29174 1
test1=# insert into c values (1);
INSERT 29175 1
test1=# insert into c values (2);
ERROR: unnamed referential integrity violation - key referenced from
c not found in p
test1=# update p set id=2;
ERROR: unnamed referential integrity violation - key in p still
referenced from c
test1=# delete from p;
ERROR: unnamed referential integrity violation - key in p still
referenced from c
The problem is that I've use tools that examine tgconstrrelid to figure
reverse engineer which relationships exist.
Is this a bug? Am I misunderstanding a feature?
(This was run with 7.1RC4; it's possible that this bug doesn't exist in
the release 7.1. I haven't been able to get the CVS server to work for
about 48 hours, so I haven't been able to upgrade.)
Thanks!
--
Joel Burton [EMAIL PROTECTED]
Director of Information Systems, Support Center of Washington
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [BUG] views and functions on relations
On Wed, 18 Apr 2001, Alex Pilosov wrote: This is a far harder to trigger bug, and actually, it doesn't happen in this simple case (oops), and the only test case I have involves 2 tables and 3 stored procedures. It is not related to views at all, just doing the underlying select causes the problem. Taking out _any_ stored procedure from the query removes the problem. Oh yes. One thing I forgot: It all worked in 7.0 and it only broke after upgrading to 7.1 -alex ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] CRN article not updated
I just checked the CRN PostgreSQL article at: http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670 I see no changes to the article, even though Vince our webmaster, Geoff Davidson of PostgreSQL, Inc, and Dave Mele of Great Bridge have requested it be fixed. Not sure what we can do now. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] problems with corrupted db on v7.0.3 on linux 2.2.x
I am in the middle of a rather nasty experience that I hope someone out there can help solve. My hard disk partition with the postgres data directory got full. I tried to shut down postgres so I could clear some space, nothing happened. So I did a reboot. On restart (after clearing some pg_sorttemp.XX files), I discovered that all my tables appear empty! When I check in the data directories of the databases, I see that the files for each table have data (they are still of the size as before). I've been running some experiments on another machine and notice that if I remove the pg_log file, databases seem to disappear (or data to become invisible). So I am guessing that postgres is looking in one place and deciding there is no data. Now I need to get my data of course! Any solutions?? My programming skills are generally very good so if it involves some code I'd have no problem. How do I get a dump of the raw data (saw copy-style output) from the table files? Please help! Thanks Paul Bagyenda ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [BUG?] tgconstrrelid doesn't survive a dump/restore
Joel Burton [EMAIL PROTECTED] writes: tgconstrrelid (in pg_trigger) holds table references in a RI trigger. The value in this field is not successfully recreated after a dump/restore. Yes, this problem was noted a couple months ago. AFAIK it was not fixed for 7.1, but I concur that it should be fixed. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: AW: [HACKERS] timeout on lock feature
One idea Tom had was to make it only active in a transaction, so you do: BEGIN WORK; SET TIMEOUT TO 10; UPDATE tab SET col = 3; COMMIT Tom is concerned people will do the SET and forget to RESET it, causing all queries to be affected by the timeout. And what? Queries would be just aborted. It's not critical event to take responsibility from user. Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: No printable 7.1 docs?
5) We have been working for translating docs into Japanese using
EUC_JP encoding. Converting to HTML is no problem, but we cannot
get correct results for sgml- RTF conversion at all. The
translated docs are just not be able to read, showing random
characters. It seems that openjade supports multibyte encodings at
least according to their manuals, but I can not get it working. I
have asked to dssslist but I have not gotten usefull helps yet.
A qustion comes to my mind: Is really sgml is an appropriate doc
format for us? For me, LaTeX seems more handy. It can generate HTML
using latex2html, and of course can produce beautiful hard copies
AUTOMATICALLY for English and other languages including Japanese.
Tatsuo, when I added SGML reference pages to the back of my book, I took
the HTML-generated output from SGML and loaded that into LaTeX. I did
have to do a few things:
convert SGML to HTML
html2latex
add * to \subsection* ?
remove \newline
remove \backslash
remove \begin_inset Figure { ? } to ?
remove trailing space from Description
no table conversion
change $$ to $ $
no SQL query conversion, all on one line , program listing and synopsis
space-period and space-comma
It actually was pretty quick. The fixes were more cleaning up strange
conversion from HTML to LaTeX.
As far as I can see, SGML gives us rich content tags, so we can do
things like pull the SGML ref manual pages headings right into pgsql's
help system. However, what it doesn't give you is much control over
appearance except how to map the tags to appearance. You can't tweek
appearance in SGML unless you make special tags for certain appearances.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: AW: [HACKERS] timeout on lock feature
[ Charset ISO-8859-1 unsupported, converting... ] This is the real reason why I've been holding out for restricting the feature to a specific LOCK TABLE statement: if it's designed that way, at least you know which lock you are applying the timeout to, and have some chance of being able to estimate an appropriate timeout. As I pointed before - it's half useless. And I totally do not understand why to object feature 1. that affects users *only when explicitly requested*; 2. whose implementation costs nothing - ie has no drawbacks for overall system. It was general practice in project so far: if user want some feature and it doesn't affect others - let's do it. What's changed? This is another reason to make it be SET TIMEOUT ... because then we don't have to have this NOWAIT tacked on to every command. It keeps the parser and manual pages cleaner, and it is a non-standard extension. One idea Tom had was to make it only active in a transaction, so you do: BEGIN WORK; SET TIMEOUT TO 10; UPDATE tab SET col = 3; COMMIT Tom is concerned people will do the SET and forget to RESET it, causing all queries to be affected by the timeout. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Real/effective user
Tom Lane writes: 1. "real user" = what you originally authenticated to the postmaster. 2. "session user" = what you can SET if your real identity is a superuser. 3. "current user" = effective userid for permission checks. We could have a Boolean variable "authenticated user is superuser" which would serve as the permission to execute SET SESSION AUTHENTICATION, while we would not actually be making the identity of the real/authenticated user available (so as to not confuse things unnecessarily). if a setuid function does a CREATE, shouldn't the created object be owned by the setuid user? I'm not sure that I *want* to accept the SQL spec on this point. Me neither. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Modified driver to better handle NULL values...y
Send over a context diff and we can get it into 7.2. You may want to shoot it to the JDBC list too. [ Charset ISO-8859-1 unsupported, converting... ] Hi, I have just modified the jdbc 7.1rc4 source to let the PreparedStatement handle null values in setXXX methods gracefully... According to JDBC a setXXX method should send a NULL if a null value is supplied (and not raise an exception or other) How can I contribute? Jeroen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: No printable 7.1 docs?
Bruce Momjian writes: However, what it doesn't give you is much control over appearance except how to map the tags to appearance. You can't tweek appearance in SGML unless you make special tags for certain appearances. How do you derive this conclusion? SGML gives you a boatload of ways to tweak appearance through style sheets. No need to make new tags either (although it sometimes doesn't hurt). -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Another news story in need of 'enlightenment'
On Tue, Apr 17, 2001 at 01:31:43PM -0400, Lamar Owen wrote: This one probably needs the 'iron hand and the velvet paw' touch. The iron hand to pound some sense into the author, and the velvet paw to make him like having sense pounded into him. Title of article is 'Open Source Databases Won't Fly' -- http://www.dqindia.com/content/enterprise/datawatch/101041201.asp This one is best just ignored. It's content-free, just a his frightened opinions. The only thing that will change his mind is the improvements planned for releases 7.2 and 7.3, and lots of deployments. Few will read his rambling. My head hurt after I read it. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AW: [HACKERS] timeout on lock featurey
[ Charset ISO-8859-1 unsupported, converting... ] One idea Tom had was to make it only active in a transaction, so you do: BEGIN WORK; SET TIMEOUT TO 10; UPDATE tab SET col = 3; COMMIT Tom is concerned people will do the SET and forget to RESET it, causing all queries to be affected by the timeout. And what? Queries would be just aborted. It's not critical event to take responsibility from user. Hey, I agree. If the users wants the TIMEOUT, give it to them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
Joel Burton [EMAIL PROTECTED] writes: Do we know if the problem is in pg_dump, or is there no way to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER statement? IIRC, pg_dump is just failing to transfer the value; it needs to emit an additional clause in the CREATE CONSTRAINT command to do so. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: No printable 7.1 docs?y
Bruce Momjian writes: However, what it doesn't give you is much control over appearance except how to map the tags to appearance. You can't tweek appearance in SGML unless you make special tags for certain appearances. How do you derive this conclusion? SGML gives you a boatload of ways to tweak appearance through style sheets. No need to make new tags either (although it sometimes doesn't hurt). You can control the appearance of tags, but can you make certain tags appear differently from other tags of the same time. I assume you are saying style sheets do that. Do you have to do the style sheet for each type of output? I would assume you do. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
On Wed, 18 Apr 2001, Tom Lane wrote: Joel Burton [EMAIL PROTECTED] writes: tgconstrrelid (in pg_trigger) holds table references in a RI trigger. The value in this field is not successfully recreated after a dump/restore. Yes, this problem was noted a couple months ago. AFAIK it was not fixed for 7.1, but I concur that it should be fixed. Jan/Philip/Tom -- Do we know if the problem is in pg_dump, or is there no way to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER statement? (I've read the dev docs on RI, but I haven't seen anyplace that documents what the arguments for the call are exactly, and a muddled wading through the source didn't help much.) If there are no better suggestions for the before-the-real-fix fix, I could make RI_pre_dump() and RI_post_dump() functions that would stick this information into another table so that I won't lose that info. (Or, can I always rely on digging it out of the preserved fields in pg_trig?) Thanks! -- Joel Burton [EMAIL PROTECTED] Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] CRN article not updated
On Wed, Apr 18, 2001 at 02:22:48PM -0400, Bruce Momjian wrote: I just checked the CRN PostgreSQL article at: http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670 I see no changes to the article, even though Vince our webmaster, Geoff Davidson of PostgreSQL, Inc, and Dave Mele of Great Bridge have requested it be fixed. If _you_ had been deluged with that kind of vitriol, what kind of favors would you feel like doing? Not sure what we can do now. It's too late. "We" screwed it up. (Thanks again, guys.) The responses have done far more lasting damage than any article could ever have done. The horse is dead. The best we can do is to plan for the future. 1. What happens the next time a slightly inaccurate article is published? 2. What happens when an openly hostile article is published? Will our posse ride off again with guns blazing, making more enemies? Will they make us all look to potential users like a bunch of hotheaded, childish nobodies? Or will we have somebody appointed, already, to write a measured, rational, mature clarification? Will we have articles already written, and handed to more responsible reporters, so that an isolated badly-done article can do little damage? We're not even on Oracle's radar yet. When PG begins to threaten their income, their marketing department will go on the offensive. Oracle marketing is very, very skillful, and very, very nasty. If they find that by seeding the press with reasonable-sounding criticisms of PG, they can prod the PG community into making itself look like idiots, they will go to town on it. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] timeout on lock feature
On Wed, Apr 18, 2001 at 09:54:11AM +0200, Zeugswetter Andreas SB wrote: In short, I think lock timeout is a solution searching in vain for a problem. If we implement it, we are just encouraging bad application design. I agree with Tom completely here. In any real-world application the database is the key component of a larger system: the work it does is the most finicky, and any mistakes (either internally or, more commonly, from misuse) have the most far-reaching consequences. The responsibility of the database is to provide a reliable and easily described and understood mechanism to build on. It is not something that makes anything unrelyable or less robust. It is also simple: "I (the client) request that you (the backend) dont wait for any lock longer than x seconds" Many things that are easy to say have complicated consequences. Timeouts are a system-level mechanism that to be useful must refer to system-level events that are far above anything that PG knows about. I think you are talking about different kinds of timeouts here. Exactly. I'm talking about useful, meaningful timeouts, not random timeouts attached to invisible events within the database. The only way PG could apply reasonable timeouts would be for the application to dictate them, That is exactly what we are talking about here. No. You wrote elsewhere that the application sets "30 seconds" and leaves it. But that 30 seconds doesn't have any application-level meaning -- an operation could take twelve hours without tripping your 30-second timeout. For the application to dictate the timeouts reasonably, PG would have to expose all its lock events to the client and expect it to deduce how they affect overall behavior. but the application can better implement them itself. It can, but it makes the program more complicated (needs timers or threads, which violates your last statement "simplest interface". It is good for the program to be more complicated if it is doing a more complicated thing -- if it means the database may remain simple. People building complex systems have an even greater need for simple components than people building little ones. What might be a reasonable alternative would be a BEGIN timeout: report failure as soon as possible after N seconds unless the timer is reset, such as by a commit. Such a timeout would be meaningful at the database-interface level. It could serve as a useful building block for application-level timeouts when the client environment has trouble applying timeouts on its own. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: CRN article not updated
If _you_ had been deluged with that kind of vitriol, what kind of favors
would you feel like doing?
Well, one person's opinion on the article that was perhaps expressed a
little harshly shouldn't cause the company to cover their ears and hum when
their article is in need of multiple corrections (as pointed out by many people,
some involved professionally with PostgreSQL and some not).. I did go through
and read some other articles written by this author -- they're all pretty bad
and filled with half-researched statements.
The article also made it seems as if Great Bridge owned and developed
PostgreSQL, which is of course totally false. That stepped on some fingers I'm
*sure*.
It's too late. "We" screwed it up. (Thanks again, guys.)
The responses have done far more lasting damage than any article
could ever have done. The horse is dead.
There isn't really a "we", is there? The PostgreSQL community isn't any kind
of entity that can be governed.. Great Bridge and PostgreSQL INC are such
entites and I'm sure they both handled the situation differently than the people
that sent in their personal opinions..
The best we can do is to plan for the future.
1. What happens the next time a slightly inaccurate article is published?
The author and publisher will probably get flamed by angry PostgreSQL users,
demanding the article be corrected :-)
Regardless of it being right or good for the (commercial) success of
PostgreSQL, people will get pissed and express some pretty harsh opinions when
something they know and love is being insulted or otherwise attacked.
2. What happens when an openly hostile article is published?
See above, take result of above and cube the intensity factor. :-)
Will our posse ride off again with guns blazing, making more enemies?
Will they make us all look to potential users like a bunch of hotheaded,
childish nobodies?
Who is "we"? Even if we ("we" being you and I) come up with something we
think is best we can't force others to do what ever that may be. Result? Someone
is always going to get angry and let the person(s) attacking know what's on
their mind.
Or will we have somebody appointed, already, to write a measured,
rational, mature clarification? Will we have articles already written,
and handed to more responsible reporters, so that an isolated badly-done
article can do little damage?
Great Bridge and their marketing people will do this.. Maybe? After all,
the PostgreSQL users/developers don't have to market their product, they're not
selling anything! (I do know some of them now work for Great Bridge, though)
We're not even on Oracle's radar yet. When PG begins to threaten their
income, their marketing department will go on the offensive. Oracle
marketing is very, very skillful, and very, very nasty. If they find
that by seeding the press with reasonable-sounding criticisms of PG,
they can prod the PG community into making itself look like idiots,
they will go to town on it.
This is something for companies, like Great Bridge, to deal with and just
isn't an issue for the PostgreSQL development/user community as we're not
marketing anything :-)
After saying all that, let me say this.. I use PostgreSQL and have been
using it for several years now, I think it's the best RDBMS out there for me and
I have recommend (and used) it for every database-driven project I've done to
date. I haven't had any trouble convincing clients to use PostgreSQL over Oracle
(and everyone that wants some software written always wants to use Oracle!). I
present the facts of PostgreSQL and in every one of the cases I've been involved
in, PostgreSQL is simply the best choice, everyone ends up happy..
To all involved in the development of PostgreSQL : THANKS!
-Mitch
Life is good. Be happy.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] timeout on lock featurey
What might be a reasonable alternative would be a BEGIN timeout: report failure as soon as possible after N seconds unless the timer is reset, such as by a commit. Such a timeout would be meaningful at the database-interface level. It could serve as a useful building block for application-level timeouts when the client environment has trouble applying timeouts on its own. Now that is a nifty idea. Just put it on one command, BEGIN, and have it apply for the whole transaction. We could just set an alarm and do a longjump out on timeout. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] timeout on lock feature
On Wed, Apr 18, 2001 at 07:33:24PM -0400, Bruce Momjian wrote: What might be a reasonable alternative would be a BEGIN timeout: report failure as soon as possible after N seconds unless the timer is reset, such as by a commit. Such a timeout would be meaningful at the database-interface level. It could serve as a useful building block for application-level timeouts when the client environment has trouble applying timeouts on its own. Now that is a nifty idea. Just put it on one command, BEGIN, and have it apply for the whole transaction. We could just set an alarm and do a longjump out on timeout. Of course, it begs the question why the client couldn't do that itself, and leave PG out of the picture. But that's what we've been talking about all along. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] [BUG] views and functions on relations
Here's more info on the bug: background: function cust_name(customers) returns varchar; Query in question: SELECT cust_name(a) FROM customers AS a, addresses AS b WHERE b.cust_id=a.cust_id and b.oid=get_billing_record(a.cust_id) and cust_balance(a.cust_id)0 First, my idea of what's happening: Tuple in question contains the row from 'customers' table. Something (when the query is evaluated, before cust_name function is called) sets the tupdesc-natts=0, however, everything else in that tupdesc is right (all the attrs are present and have correct values and atttypes), and tuple-t_data-t_natts is correct (12). When SPI_getbinval is called, it checks tuple-t_data-t_natts, and works OK, but, however, when SPI_gettypeid is called, it checks tupledesc-nattrs, and returns 0. Question: Should SPI_gettypeid look at tuple-t_data-t_natts (to do that, it needs to be passed tuple along with tupdesc)? Or some other code should be fixed to properly set tupledesc-nattrs? NOTE: when I removed the check in SPI_gettypeid, it _also_ fixed the '\d viewname' bug, so these two bugs are related (i.e. you cannot see \d because nattrs is set incorrectly). You may have more luck tracing the code which improperly sets nattrs than me... Hoping for proper fix, -alex traceback: #0 elog (lev=-1, fmt=0x45d4b340 "cache lookup for type %u failed") at elog.c:119 #1 0x45d4693e in exec_cast_value (value=1791, valtype=0, reqtype=23, reqinput=0x82bfdb0, reqtypelem=0, reqtypmod=-1, isnull=0xbfffeb6f "") at pl_exec.c:2682 #2 0x45d45f19 in exec_assign_value (estate=0xbfffec40, target=0x82cdd88, value=1791, valtype=0, isNull=0xbfffeb6f "") at pl_exec.c:2173 #3 0x45d4687a in exec_move_row (estate=0xbfffec40, rec=0x0, row=0x82bfcc8, tup=0x827a170, tupdesc=0x827a130) at pl_exec.c:2629 #4 0x45d43e64 in plpgsql_exec_function (func=0x82b3188, fcinfo=0x828e364) at pl_exec.c:331 #5 0x45d41f57 in plpgsql_call_handler (fcinfo=0x828e364) at pl_handler.c:128 #6 0x80b78ad in ExecMakeFunctionResult (fcache=0x828e350, arguments=0x826eb28, econtext=0x826fc98, isNull=0xbfffed37 "", isDone=0xbfffed68) at execQual.c:796 #7 0x80b794e in ExecEvalFunc (funcClause=0x826ead8, econtext=0x826fc98, isNull=0xbfffed37 "", isDone=0xbfffed68) at execQual.c:890 #8 0x80b7d1c in ExecEvalExpr (expression=0x826ead8, econtext=0x826fc98, isNull=0xbfffed37 "", isDone=0xbfffed68) at execQual.c:1215 #9 0x80b7fbb in ExecTargetList (targetlist=0x826e6a0, nodomains=19, targettype=0x8284620, values=0x8285100, econtext=0x826fc98, isDone=0xbfffef08) at execQual.c:1536 #10 0x80b8215 in ExecProject (projInfo=0x82850d8, isDone=0xbfffef08) at execQual.c:1764 #11 0x80bcd9a in ExecNestLoop (node=0x826e5c0) at nodeNestloop.c:245 #12 0x80b6b76 in ExecProcNode (node=0x826e5c0, parent=0x826e5c0) at execProcnode.c:297 #13 0x80b5eee in ExecutePlan (estate=0x826f770, plan=0x826e5c0, operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, destfunc=0x8285de0) at execMain.c:973 #14 0x80b5463 in ExecutorRun (queryDesc=0x826f758, estate=0x826f770, feature=3, count=0) at execMain.c:233 #15 0x80f76b3 in ProcessQuery (parsetree=0x82433e8, plan=0x826e5c0, dest=Remote) at pquery.c:295 #16 0x80f62bb in pg_exec_query_string ( query_string=0x8243090 "select * from outstanding_balances;", dest=Remote, parse_context=0x8218730) at postgres.c:810 #17 0x80f71e6 in PostgresMain (argc=4, argv=0xb1e0, real_argc=8, real_argv=0xbaf4, username=0x81cbf69 "sw") at postgres.c:1908 #18 0x80e14c3 in DoBackend (port=0x81cbd00) at postmaster.c:2111 #19 0x80e10ac in BackendStartup (port=0x81cbd00) at postmaster.c:1894 #20 0x80e0436 in ServerLoop () at postmaster.c:992 #21 0x80dfe63 in PostmasterMain (argc=8, argv=0xbaf4) at postmaster.c:682 #22 0x80c4055 in main (argc=8, argv=0xbaf4) at main.c:151 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: [PATCHES] Fix for psql core dumping on bad user
D. Hageman writes: The postgresql interactive terminal will dump core on any script that is run via the -f command line option if their exists a connect line without a valid user. An example connect line is in one of the attached files. Okay, I've found the problem. When the connection fails, psql momentarily runs without a valid database connection. When it does that, the multibyte encoding has the invalid value -1. (You need to compile with multibyte enabled to reproduce this.) With that value, PQmblen() has trouble when it parses the next line. Perhaps PQmblen() should simply return 1 when it is passed an invalid encoding. In any case it should do better than dump core. Will fix. Also I will change the "invalid" encoding to a default i.e. SQL_ASCII, not -1. -- Tatsuo Ishii ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: No printable 7.1 docs?
Tatsuo, when I added SGML reference pages to the back of my book, I took
the HTML-generated output from SGML and loaded that into LaTeX. I did
have to do a few things:
convert SGML to HTML
html2latex
add * to \subsection* ?
remove \newline
remove \backslash
remove \begin_inset Figure { ? } to ?
remove trailing space from Description
no table conversion
change $$ to $ $
no SQL query conversion, all on one line , program listing and synopsis
space-period and space-comma
It actually was pretty quick. The fixes were more cleaning up strange
conversion from HTML to LaTeX.
Looks nice, but I'm afraid I have to do all the work above for 489
HTML files:-)
What I'm doing now is trying to fix openjade. It is written in C++,
and I hate C++, no way...
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [BUG] views and functions on relations
Alex Pilosov [EMAIL PROTECTED] writes: Something (when the query is evaluated, before cust_name function is called) sets the tupdesc-natts=0, Ugh. You verified the natts is wrong in the tupdesc? Question: Should SPI_gettypeid look at tuple-t_data-t_natts (to do that, it needs to be passed tuple along with tupdesc)? Or some other code should be fixed to properly set tupledesc-nattrs? The tupdesc natts *must* match the actual tuple, else all sorts of things will go wrong. I don't think SPI_gettypeid is broken. NOTE: when I removed the check in SPI_gettypeid, it _also_ fixed the '\d viewname' bug, so these two bugs are related (i.e. you cannot see \d because nattrs is set incorrectly). That seems moderately unlikely, since \d doesn't depend on SPI... You may have more luck tracing the code which improperly sets nattrs than me... Hard to do without a working (failing ;-)) example to look at. Have you had any luck reducing your example? Alternatively, would you be willing to give me telnet or ssh access to your machine, and I'll look at the problem in situ? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [BUG] views and functions on relations
Alex Pilosov [EMAIL PROTECTED] writes: Something (when the query is evaluated, before cust_name function is called) sets the tupdesc-natts=0, FWIW, I have just looked through all the code that sets natts fields, and I don't believe that any of it can set a tupdesc's natts field to zero. Therefore the zeroing must be an accidental stomp of some kind. Since natts is the first field in a tupdesc, it seems plausible that this might happen if some bit of code misinterprets a tupdesc pointer as something else. However, that makes the odds of finding the problem by staring at code even lower. I really need to get after this with a debugger... BTW, are you building with --enable-cassert? If not I strongly recommend it for chasing this sort of problem. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: No printable 7.1 docs?y
It actually was pretty quick. The fixes were more cleaning up strange conversion from HTML to LaTeX. Looks nice, but I'm afraid I have to do all the work above for 489 HTML files:-) What I'm doing now is trying to fix openjade. It is written in C++, and I hate C++, no way... I cat'ed them all together, pulled them up in an editor with macros, and went to town for a few hours. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
At 16:30 18/04/01 -0400, Tom Lane wrote: IIRC, pg_dump is just failing to transfer the value; it needs to emit an additional clause in the CREATE CONSTRAINT command to do so. From memory, this is one of the non-standard SQL things that pg_dump still does (ie. definining the constraint using rule definitions). I'll see if I can find a way of constructing the FK constraint properly, but don't hold your breath. 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 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: [BUG?] tgconstrrelid doesn't survive a dump/restore
At 16:25 18/04/01 -0400, Joel Burton wrote: Do we know if the problem is in pg_dump, or is there no way to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER statement? It's because pg_dump is not designed to dump these constraints *as* constraints. We just need to make pg_dump clever enough to do that. 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 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [BUG] views and functions on relations
Alex Pilosov [EMAIL PROTECTED] writes: Here's more info on the bug: background: function cust_name(customers) returns varchar; Query in question: SELECT cust_name(a) FROM customers AS a, addresses AS b WHERE b.cust_id=a.cust_id and b.oid=get_billing_record(a.cust_id) and cust_balance(a.cust_id)0 I think I see the problem. Is your query being executed via a mergejoin plan with an explicit sort on customers? Does the failure go away if you force a nestloop join? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
