Re: [HACKERS] troubleshooting pointers
Joe Conway [EMAIL PROTECTED] writes: Tom Lane wrote: It's not unlikely that those issues are exactly due to not having rescan handled properly. What misbehavior are you seeing? Hmm, that might just be it. When I select from a view based on a function which returns a base type, I only get the first row. When I select from a view which is based on a function returning a composite type, it triggers an assertion. I've traced the latter down to a slot pointer which is reset to NULL somewhere. Um, that's probably not it then. Rescan would only come into play for a plan node that's being used as the inside of a join, or some other contexts more complicated than this. A simple view ought to make no difference at all in the generated plan --- perhaps there's some bit of the planner that you missed teaching about function RTEs or FunctionScan plan nodes? Anyway, I plan to review and apply your patch today, if I don't run into any major problems. Will look to see if I see a reason for the view trouble. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Native Win32, How about this?
A binary version of PostgreSQL for Windows should not use the cygwin dll. I know and understand there is some disagreement with this position, but in this I'm sure about this. That may ultimately be desirable. In the short term, it is likely preferable to use cygwin. It is only necessary to point at MySQL for an example. Cygwin is used there. http://www.mysql.com/downloads/mysql-3.23.html It is being used widely, crap or not. Cygwin may not ultimately be the ideal thing to use; we don't yet live in Pangloss' Best of All Possible Worlds, and thus have to live with some things not being ideal. If having the installer install Cygwin as well as the DBMS makes it easy to have something usable soon, and this allows 100,000 WinFolk to try out PostgreSQL, then that's a Big Win. Out of 100K users, surely two or three may be attracted into working on a more Panglossian solution. It may be fair to say that none of those 100K folk would be using PostgreSQL to support HA applications involving hundreds of GB of data. That's _fine_. If there are new 100K folk using PostgreSQL/cygwin, _some_ of them will outgrow its capabilities, and come looking for improvements. And as they're Windows users, accustomed to having to pay hefty amounts to Microsoft to get support no better than that provided by the Psychic Friends Network (see http://www.bmug.org/news/articles/MSvsPF.html), they'll doubtless be prepared to have to pay _something_ in order for PostgreSQL/Win3K-Enterprise Edition to become available. That seems a not too unreasonable path towards the Best of All Possible Worlds. There may be a bit of hyperbole in the above, but any time Voltaire gets quoted, that's likely to happen :-). -- (reverse (concatenate 'string gro.gultn enworbbc)) http://www.cbbrowne.com/info/wp.html Eagles may soar, but weasels don't get sucked into jet engines. -- (concatenate 'string cbbrowne ntlug.org) http://www.cbbrowne.com/info/multiplexor.html It's a little known fact that the Dark Ages were caused by the Y1K problem. msg16930/pgp0.pgp Description: PGP signature
Re: [HACKERS] Nested transactions RFC
Manfred Koizar [EMAIL PROTECTED] writes: TransactionId GetParentXact(TransactionId xnum) uses pg_subtrans to find the parent transaction of xnum. This is not only extremely expensive, but in practice would cause infinite recursion: any attempt to validate the commit state of a row in pg_subtrans would result in a recursive attempt to search pg_subtrans. I don't think we can do table access from inside the tqual.c routines. A practical implementation, which would cost little except tuple header space (and yes I know that won't make you happy) would require 3 fields instead of 2 for both the min and the max: transaction ID subtransaction ID command ID First check the transaction ID: if aborted or (in-progress and not mine), tuple is not visible. Next, if the subtransaction ID is not zero, similarly check it. Finally, if xid and sub-xid are both mine, the command ID has to be checked. In this scenario, subtransactions commit or abort by marking their pg_clog entries, but no one else will care until the parent transaction commits. So there is no extra state anywhere except for the stack of active transaction numbers inside each backend. Possibly we could use techniques similar to what you already suggested for cmin/cmax to reduce the amount of physical storage needed for the six logical fields involved. regards, tom lane PS: unfortunately, tuple validity checking is only a small part of what has to be done to support subtransactions. The really nasty part is in fixing error recovery inside the backend so that (most) errors can be dealt with by aborting only the innermost subtransaction. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Set Returning Functions (SRF) - request for patch review and comment
On Monday 06 May 2002 18:51, Joe Conway wrote: (...) Request for help: - So far I've tested with SQL and C functions. (...) Can you post an example of a function in C? (I'm trying out your patch from Friday). Thanks, Ian Barwick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bug? in current cvs with bigint datatype
Barry Lind [EMAIL PROTECTED] writes: create table test (cola bigint); update test set cola = 100; ERROR: column cola is of type 'bigint' but expression is of type 'double precision' You will need to rewrite or cast the expression dtoi8 is currently marked not proimplicit. People seem to have lost interest in the discussion thread about which coercions should be allowed implicitly, but the issues still need to be resolved before 7.3. This particular example perhaps says that when assigning to a table column, we should allow not-proimplicit coercions to be invoked implicitly anyway. Since there isn't any question about either the source type or the target type, allowing this case doesn't seem to pose any risk of surprising choices being made. Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] internal voting
[Note, I've changed the headers so everyone on the original distribution list is getting a copy via Bcc, including -hackers. It was the simplest way I could think of making certain the discussion moved to -interfaces as Marc requested.] On Sat, 11 May 2002, Bartus Levente wrote: ... I think, there is no connection (should not be) between the versions of the pgaccess and the versions of the pgsql. Pgaccess is a visual tool for pgsql, that can be developed freely without having anything to do with the pgsql developement. Yes. So I cannot understand why the majority of the oppinions says that pgaccess should stay in the shadow of the pgsql. Who said shadow? FWIW, I'd never have bothered about pgaccess, that's even I'd even known about it, if it hadn't come in the main postgres tree. Breaking this tight connection we can help pgaccess to develop as fast as it can, and we let free space for other projects to appear. For me the first thing is to make my daily job as good and fast as I can. And this is much easier with using the best tool for the particular problem. This is why I started to make patches to this project. Sorry but I can't wait for the next pgsql release to have this patches included in the package. Uhoh, now we have a problem, unless your version is going to form the initial repository or there's little or no impact across the preexisting code. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Nested transactions RFC
Tom,
reading my message again and your response, I see, that some points
were a bit unclear.
On Fri, 10 May 2002 13:12:21 +0200, I wrote:
|if it is acceptable for subtransactions to use up transaction numbers,
Of course, use up is nonsense, as it sounds like use all
available; this should have been use or draw from the pool of.
Should have listened better to my English teacher :-)
On Sat, 11 May 2002 11:51:37 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
TransactionId GetParentXact(TransactionId xnum) uses pg_subtrans to
find the parent transaction of xnum.
This is not only extremely expensive, but in practice would cause
infinite recursion: any attempt to validate the commit state of a
row in pg_subtrans would result in a recursive attempt to search
pg_subtrans. I don't think we can do table access from inside the
tqual.c routines.
I wrote:
|It needs an additional system table
|pg_subtrans (child XactId PRIMARY KEY, parent XactId).
But no! Table is not the correct word for what I mean. I rather
want something living outside transactions and not accessed via normal
SQL statements. It is to be handled by highly specialized and
optimized routines, because fast access is crucial for the whole
proposal. That's why I called a really fast implementation of
pg_subtrans a challenge. I had pg_clog in mind, but didn't find the
right words.
A practical implementation, which would cost little except tuple header
space (and yes I know that won't make you happy) would require 3 fields
:-)
instead of 2 for both the min and the max:
transaction ID
subtransaction ID
command ID
This was my first attempt. I've dismissed it for several reasons.
First check the transaction ID: if aborted or (in-progress and not
mine), tuple is not visible.
I agree up to here.
Next, if the subtransaction ID is not
zero, similarly check it.
Now imagine
BEGIN 1;
BEGIN 2;
BEGIN 3;
INSERT tup3;
COMMIT 3;
ROLLBACK 2;
COMMIT 1;
Then in tup3 we would have xid==1 and subxid==3, both of which are
committed, but nevertheless tup3 is invisible, because xact 2 aborted.
Finally, if xid and sub-xid are both mine,
the command ID has to be checked.
In this scenario, subtransactions commit or abort by marking their
pg_clog entries, but no one else will care until the parent transaction
commits. So there is no extra state anywhere except for the stack
of active transaction numbers inside each backend.
A *stack* of _active_ transaction numbers is not sufficient, we need
the whole *tree* of _all_ transactions belonging to the current top
level transaction. This is, want I wanted to model in my pg_subtrans
table. And pg_subtrans cannot be a private structure, because it
has to be inspected by other transactions too (cf. example above).
PS: unfortunately, tuple validity checking is only a small part of what
has to be done to support subtransactions. The really nasty part is
in fixing error recovery inside the backend so that (most) errors can
be dealt with by aborting only the innermost subtransaction.
Is this really related to subtransactions? The current behaviour is,
that an error not only aborts the offending command, but the whole
(top level) transaction. My proposal doesn't change anything
regarding this. Though I agree it would be desirable to have finer
grained error handling.
You have quoted only small parts of my posting. Do you agree to the
rest? Or didn't you bother to comment, because you considered the
whole proposal refuted by your counter-arguments? I'll be fine either
way, I just want to know.
BTW, there's something missing from my visibility checks:
|if (IsCurrentTransaction(xmin)) {
here we have to add or xmin is one of my (grand)*parents.
And of course, it would be nice to have named savepoints:
BEGIN;
BEGIN foo;
BEGIN bar;
...
ROLLBACK foo;
COMMIT; -- top level transaction
Servus
Manfred
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Set Returning Functions (SRF) - request for patch review
Ian Barwick wrote: On Monday 06 May 2002 18:51, Joe Conway wrote: (...) Request for help: - So far I've tested with SQL and C functions. (...) Can you post an example of a function in C? (I'm trying out your patch from Friday). Thanks, Ian Barwick See contrib/dblink. The version in cvs HEAD has two that return sets -- dblink() which returns an int, and dblink_get_pkey() which returns text. I don't have an example that returns a composite type though. I'll make one of those for testing some time next week. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] troubleshooting pointers
Tom Lane wrote: Um, that's probably not it then. Rescan would only come into play for a plan node that's being used as the inside of a join, or some other contexts more complicated than this. A simple view ought to make no difference at all in the generated plan --- perhaps there's some bit of the planner that you missed teaching about function RTEs or FunctionScan plan nodes? Anyway, I plan to review and apply your patch today, if I don't run into any major problems. Will look to see if I see a reason for the view trouble. (Sorry for the slow response -- been out all day) Actually I found late last night that when the view is used, the RTE is a RangeVar, so the RangeFunction code never gets executed. So I think your comment above is right on. That may well explain both problems. I'll start looking again tonight. Thanks, Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
