Re: AW: BLERe: AW: AW: [HACKERS] relation ### modified while in use
At 18:31 24/10/00 +0900, Hiroshi Inoue wrote: > > >Zeugswetter Andreas SB wrote: > >> > > > Are there many applications which have many SELECT statements(without >> > > > FOR UPDATE) in one tx ? >> > > >> > > Why not ? >> > > >> > It seems to me that multiple SELECT statements in a tx has little >> > meaning unless the tx is executed in SERIALIZABLE isolation level. >> >> E.g. a table is accessed multiple times to select different data >> in an inner application loop. No need for serializable here. >> > >And seems no need to execute in one tx. >Hmm,we seems to be able to call a cleanup procedure >internally which is equivalent to 'commit' after each >consecutive read-only statement. Is it a problem ? I have not followed the entire thread, but if you are in a serializable OR repeatable-read transaction, I would think that read-only statements will need to keep some kind of lock on the rows they read (or the table). 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 |/
Re: [HACKERS] Fallback behavior for "UNKNOWN" types -- proposed change
> I would suggest a slightly different rule, but maybe it comes out at the > same place in the end: if we can't find a unique match treating UNKNOWN > the way we do now, try again assuming it is TEXT (or at least string > category). As you say, this is reasonable given that the original > literal looked like a string. Yeah, it is the same thing in the end, since the *only* place I've changed in the code is the block which used to bail out when seeing a "category conflict". I assumed you would have an opinion ;) If anyone else has concerns before seeing the effects of the change in the development tree, speak up! Of course, if we see troubles after commit, things can change or revert... Oh, and UNKNOWNNUMERIC sounds like a plausible concept too. - Thomas
[HACKERS] Re: [PATCHES] add darwin/osxpb support to cvs
>Next time you can make your patch with "diff -crN" so that you don't have >to create a separate tarball. No problem. I tried just doing a diff with cvs but wasn't able to get the -N option to work. This is the first time I've ever tried patching unix software so I'm sorry if it's a bit messy. Thanks for you help in getting it right. > > - the config.guess and config.sub files have been updated by apple to >> support their new os. i don't think these changes have been folded >> back in to the main archive yet > >I installed the latest ones from GNU which claim to support it according >to the ChangeLog. I'll try checking out the new versions and see if they work. I can send you a diff with the ones I have here if you want to see the additions Apple made. > > I've followed the BeOS example of including the necessary sem.h >> declarations in src/include/port/darwin.h. this is rather messy at the >> moment and can be dumped once apple releases a version of PB with sysv >> sem built into the kernel. > >The include/port/beos.h isn't really a shining example of how to do this. >This file is include *everywhere*, but we don't want to know about >semaphores everywhere. I'd prefer it if you use the QNX approach and >symlink sem.h into an include directory (e.g., /usr/local/include/sys), >since it's only temporary anyway. I agree it's rather messy. I originally had just used the sym link in /usr/local/include, but as I said, some of the newer Darwin kernels have the sysv sem.h file already there and I was worried about people overwriting it. If you think it's fair to put this responsibility on the end user, I'm ok with that. I just thought it might be nice to check and see if the semaphore implementation was already there, and if not, build the necessary parts. I'll switch it back to the way it was. >I'm also somewhat concerned about the dynloader.c because it's under the >Apache license which has a funny advertisement clause. Comments from >someone? I wondering about this too. I'll try emailing Wilfredo Sanchez and see if I can get the code outside the Apache license. This would probably be easiest. >The compiler probably predefines something like __darwin__, which you >should use. You can find out with It doesn't actually provide __darwin__ but as I mentioned in a previous post, Apple is suggesting people use __APPLE__ combined with __ppc__ or __i386__ for the different darwin builds. The section in s_lock.c should probably be changed to reflect this instead of using DARWIN_OS. >And finally, what's up with this: > >CFLAGS='-O0 -g -traditional-cpp' > >? What's wrong with the "modern-cpp"? Apple's "modern-cpp" called cpp-precomp uses some strange parsing that breaks on several files in the postgresql build. They are still working on it apparently and are suggesting people simply use the -traditional-cpp flag when this happens instead of trying to update the files. Thanks again for all your comments and suggestions. Bruce
[HACKERS] Bogus-looking SSL code in postmaster wait loop
The postmaster contains this code just before it waits for input:
#ifdef USE_SSL
for (curr = DLGetHead(PortList); curr; curr = DLGetSucc(curr))
{
if (((Port *) DLE_VAL(curr))->ssl &&
SSL_pending(((Port *) DLE_VAL(curr))->ssl) > 0)
{
no_select = true;
break;
}
}
if (no_select)
FD_ZERO(&rmask);/* So we don't accept() anything below */
#endif
I am not sure exactly what SSL_pending() is defined to mean, but as
near as I can tell, whenever SSL_pending() returns true, the postmaster
will completely ignore every other input-ready condition. This spells
"denial of service" from where I sit: a nonresponsive SSL client will
cause the postmaster to freeze up for all other clients.
Can anyone who knows about SSL defend or even explain the above code?
I am strongly inclined to just dike it out.
regards, tom lane
Re: [HACKERS] length coerce for bpchar is broken since 7.0
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> bpcharin() will most definitely NOT fix the problem, because it often
> >> will not know the target column's typmod, if indeed there is an
> >> identifiable target column at all.
>
> > Can you give me any example for this case?
>
> UPDATE foo SET bpcharcol = 'a'::char || 'b'::char;
>
> UPDATE foo SET bpcharcol = upper('abc');
>
> In the first case bpcharin() will be invoked, but not in the context
> of direct assignment to a table column, so it won't receive a valid
> typmod. In the second case bpcharin() will never be invoked at all,
> because upper takes and returns text --- so 'abc' is not a bpchar
> constant but a text constant. You have to be sure that the parser
> handles type length coercion correctly, and I think the cleanest way to
> do that is to fix exprTypmod so that it knows how typmod is defined in
> the MULTIBYTE case.
In those cases above bpchar() will be called anyway, so I don't see
MULTIBYTE length coerce problems there.
--
Tatsuo Ishii
[HACKERS] Re: [PATCHES] binary operators on integers
Peter Eisentraut <[EMAIL PROTECTED]> writes: > This patch was installed, with xor as "#". The parser still needs work. > Besides the known issue of "|", this also parses funny: > => select 5 & ~ 6; > ERROR: Unable to identify a right operator '&' for type 'int4' I think we're kind of stuck on that, at least in terms of a solution specifically for ~ --- I don't think we should be wiring knowledge of whether specific operators are prefix/suffix/infix into the grammar. It might perhaps be possible to tweak the grammar so that operand operator operator operand is generically resolved as operand infix-op (prefix-op operand) and not (operand postfix-op) infix-op operand the way it is now. Given that postfix operators are relatively seldom used, this seems a more sensible default --- but I suppose somewhere out there is an application that will break. (At least it probably won't break silently.) Comments anyone? regards, tom lane
Re: [HACKERS] relation ### modified while in use
Vadim Mikheev wrote: > > > > In my understanding,locking levels you provided contains > > > > an implicit share/exclusive lock on the corrsponding > > > > pg_class tuple i.e. AccessExclusive Lock acquires an > > > > exclusive lock on the corresping pg_class tuple and > > > > other locks acquire a share lock, Is it right ? > > > > > > No. Access...Locks are acquired over target table > > > (table' oid is used as key for lmgr hash table), > > > not over corresponding pg_class tuple, in what case > > > we would use pg_clas' oid + table' oid as key > > > (possibility I've described below). > > > > > > > Yes,I know that "lock table" doesn't touch the correpon > > ding pg_class tuple at all. However isn't it equivalent ? > > >From what POV? > Lock manager will allow two simultaneous exclusive locks using these > different methods (keys) and so we can interpret (use) them differently. > Seems my first explanation was really bad,sorry. When I saw Access(Share/Exclusive)Lock for the first time, I thought what they are for. For VACUUM ? Yes. For DROP TABLE ? Yes. For ALTER TABLE ? Maybe yes... Oracle doesn't have VACUUM and probably handles the other cases using dictionary lock mechanism. Unfortunately we've had no dictionary lock mechanism. Don't Access(..)Lock locks compensate the lack of dictionary lock mechanism ? Regards. Hiroshi Inoue
Re: [HACKERS] Re: how to access backend pid from libpq ?
Hannu Krosing <[EMAIL PROTECTED]> writes: > Ok, I found it from the libpq source: PQbackendPID > I still think it could be documented ;) It is. regards, tom lane
[HACKERS] [Fwd: [CORE SDI ADVISORY] MySQL weak authentication]
I am forwarding this not to belittle MySQL, but to hopefully help in the
development of our own encryption protocol for secure password
authentication over the network.
The point being is that if we offer the protocol to do it, we had better
ensure its security, or someone WILL find the hole. Hopefully it will
be people who want to help security and not exploit it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Original Message
Subject: [CORE SDI ADVISORY] MySQL weak authentication
Date: Mon, 23 Oct 2000 19:09:24 -0300
From: Iván Arce <[EMAIL PROTECTED]>
Reply-To: Iván Arce <[EMAIL PROTECTED]>
Organization: Core-SDI, Buenos Aires, Argentina
To: [EMAIL PROTECTED]
CORE SDI
http://www.core-sdi.com
Vulnerability Report for MySQL Authentication
Vulnerability
Date Published: 2000-10-23
Advisory ID: CORE-20001023
Bugtraq ID: 1826
CVE CAN: Not currently assigned.
Title: MySQL Authentication Vulnerability
Class: Design Error
Remotely Exploitable: Yes
Locally Exploitable: No
Vulnerability Description:
The "MySQL Database Engine" uses an authentication scheme designed
to prevent the flow of plaintext passwords over the network and
the storage of them in plaintext. For that purpose a challenge-response
mechanism for authentication has been implemented on all versions
of MySQL. Slight variations are to be found between version 3.20
and 3.21 and above.
Regrettably, this authentication mechanism is not cryptographically
strong. Specifically, each time a user executes this mechanism,
information allowing an attacker to recover this user's password is
leaked. Using an attack of our design, described in the "Technical
details" section of this advisory, an eavesdropper is able to recover
the user's password after witnessing only a few executions of this
protocol, and thence is able to authenticate to the database engine
impersonating a valid user.
Vulnerable Packages/Systems:
All versions of MySQL
Solution/Vendor Information/Workaround:
The vendor is aware of the problems described and suggests
encrypting the traffic between client and server to prevent
exploitation.
For further details refer to:
http://www.mysql.com/documentation/mysql/commented/manual.php?section=Securi
ty
Plans to implement a stronger authentication mechanism are being
discussed for future versions of MySQL.
Additionally, advisories and information on security issues
in MySQL can be obtained from:
http://www.securityfocus.com/bid/1147
http://www.securityfocus.com/bid/975
http://www.securityfocus.com/bid/926
Vendor notified on: October 19th, 2000
Credits:
These vulnerabilities were found and researched by Ariel "Wata"
Waissbein, Emiliano Kargieman, Carlos Sarraute, Gerardo Richarte and
Agustin "Kato" Azubel of CORE SDI, Buenos Aires, Argentina.
This advisory was drafted with the help of the SecurityFocus.com
Vulnerability Help Team. For more information or assistance drafting
advisories please mail [EMAIL PROTECTED]
Technical Description - Exploit/Concept Code:
1. The challenge/response mechanism
The challenge-response mechanism devised in MySQL does the following:
From mysql-3.22.32/sql/password.c:
/***
The main idea is that no passwords are sent between client & server on
connection and that no passwords are saved in mysql in a decodable
form.
MySQL provides users with two primitives used for authentication: a
hash function and a (supposedly) random generator. On connection a
random
string is generated by the server and sent to the client. The client,
using as input the hash value of the random string he has received and
the hash value of his password, calculates a new string using the
random generator primitive.
This 'check' string is sent to the server, where it is compared with a
string generated from the stored hash_value of the password and the
random string.
The password is saved (in user.password) by using the PASSWORD()
function in mysql.
Example:
update user set password=PASSWORD("hello") where user="test"
This saves a hashed number as a string in the password field.
**/
To accomplish that purpose several functions and data structures are
implemented:
mysql-3.22.32/include/mysql_com.h:
struct rand_struct {
unsigned long seed1,seed2,max_value;
double max_value_dbl;
};
mysql-3.22.32/sql/password.c:
void randominit(struct rand_struct *rand_st,ulong seed1, ulong seed2)
Initializes the PRNG, used by versions 3.21 and up
static void old_randominit(struct rand_struct *rand_st,ulong seed1)
Initializes the PRNG, used by versions up to 3.20
double rnd(struct rand_struct *rand_st)
Provides a random floating point (double) number taken from
the
Re: [HACKERS] Mailing list archives available?
On Tue, 24 Oct 2000, Vince Vielhaber wrote:
> On Tue, 24 Oct 2000, The Hermit Hacker wrote:
>
> >
> > http://www.postgresql.org/mhonarc has them all listed .. not sure how to
> > get there from the Web site ... Vince?
>
> There are links from both the Developer's Corner and User's Lounge ->
> General Info.
Ya know, I've gone in and looked several times and my eye always gets draw
down to the section titled ' Mailing Lists '? :) Can you put lnks from
the 'pgsql-{admin,announce,general,etc}' in that section to the archives
as well, so its a bit easier to find? And maybe 'bold' the words "mailing
lists" in the General Info section, so that it stands out a bit more? :)
> > Vince.
>
>
> >
> > On Mon, 23 Oct 2000, Krzysztof Kowalczyk wrote:
> >
> > > Are mailing list archives of various postgresql mailing list available
> > > anywhere?
> > >
> > > I know they were some time ago but I couldn't find any link on
> > > www.postgresql.org now. I subscribed to a list mainly because I want to
> > > monitor the progress but the amount of messages kills my inbox. It would
> > > be really convenient for me if I could just browse the archives on web
> > > once in a while.
> > >
> > > Krzysztof Kowalczyk
> > >
> > >
> >
> > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> > Systems Administrator @ hub.org
> > primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
> >
> >
>
> --
> ==
> Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
> 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
> Online Campground Directoryhttp://www.camping-usa.com
>Online Giftshop Superstorehttp://www.cloudninegifts.com
> ==
>
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
[HACKERS] looks like we forgot something...
Tried a build from today's checkins, and we didn't find -lperl... mkdir blib/arch mkdir blib/arch/auto mkdir blib/arch/auto/plperl mkdir blib/lib/auto mkdir blib/lib/auto/plperl /bin/cc -c -I../../../src/include -I/usr/local/include -O-DVERSION=\"0.10\" -DXS_VERSION=\"0.10\" -Kpic -I/usr/local/lib/perl5/5.00503/i386-svr5/CORE plperl.c UX:acomp: WARNING: "/usr/local/lib/perl5/5.00503/i386-svr5/CORE/perl.h", line 1474: macro redefined: DEBUG /bin/cc -c -I../../../src/include -I/usr/local/include -O-DVERSION=\"0.10\" -DXS_VERSION=\"0.10\" -Kpic -I/usr/local/lib/perl5/5.00503/i386-svr5/CORE eloglvl.c /bin/perl -I/usr/local/lib/perl5/5.00503/i386-svr5 -I/usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/5.00503/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.00503/ExtUtils/typemap SPI.xs >xstmp.c && mv xstmp.c SPI.c /bin/cc -c -I../../../src/include -I/usr/local/include -O-DVERSION=\"0.10\" -DXS_VERSION=\"0.10\" -Kpic -I/usr/local/lib/perl5/5.00503/i386-svr5/CORE SPI.c UX:acomp: WARNING: "/usr/local/lib/perl5/5.00503/i386-svr5/CORE/perl.h", line 1474: macro redefined: DEBUG UX:acomp: WARNING: "SPI.c", line 73: end-of-loop code not reached UX:acomp: WARNING: "SPI.c", line 88: end-of-loop code not reached UX:acomp: WARNING: "SPI.c", line 103: end-of-loop code not reached UX:acomp: WARNING: "SPI.c", line 118: end-of-loop code not reached UX:acomp: WARNING: "SPI.c", line 133: end-of-loop code not reached UX:acomp: WARNING: "SPI.c", line 149: end-of-loop code not reached Running Mkbootstrap for plperl () chmod 644 plperl.bs LD_RUN_PATH="" /bin/cc -o blib/arch/auto/plperl/plperl.so -G -Wl,-Bexport -L/usr/local/lib plperl.o eloglvl.o SPI.o /usr/local/lib/perl5/5.00503/i386-svr5/auto/Opcode/Opcode.so -L/usr/local/lib/perl5/5.00503/i386-svr5/CORE -lperl UX:ld: ERROR: library not found: -lperl gmake[4]: *** [blib/arch/auto/plperl/plperl.so] Error 1 gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/plperl' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/plperl' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
[HACKERS] Re: [PATCHES] add darwin/osxpb support to cvs
Bruce Hartzler writes: > this patch and tar archive will add support for the darwin/osxpb to the current cvs >tree. Next time you can make your patch with "diff -crN" so that you don't have to create a separate tarball. > - the config.guess and config.sub files have been updated by apple to > support their new os. i don't think these changes have been folded > back in to the main archive yet I installed the latest ones from GNU which claim to support it according to the ChangeLog. > - the situation with darwin's implementation of sysv semaphores is in > progress at the moment (the shm/ipc support *is* there and seems to > work fine). so this patch uses HAVE_SYS_SEM_H to conditionally build HAVE_SYS_SEM_H is a preprocessor symbol, not a makefile variable. > the src/backend/port/darwin semaphore code (borrowed from qnx4). If you could arrange it, could you use the same files as QNX, perhaps with an #ifdef here or there > I've followed the BeOS example of including the necessary sem.h > declarations in src/include/port/darwin.h. this is rather messy at the > moment and can be dumped once apple releases a version of PB with sysv > sem built into the kernel. The include/port/beos.h isn't really a shining example of how to do this. This file is include *everywhere*, but we don't want to know about semaphores everywhere. I'd prefer it if you use the QNX approach and symlink sem.h into an include directory (e.g., /usr/local/include/sys), since it's only temporary anyway. Also, overriding configure results (à la #undef HAVE_UNION_SEMUN) isn't cool. I'm also somewhat concerned about the dynloader.c because it's under the Apache license which has a funny advertisement clause. Comments from someone? > - i'm a bit confused over the __powerpc__ tas function in s_lock.c > (there i assume for the ppc-linux port). it doesn't compile at all on > darwin so i just added a version that does work on darwin under > DARWIN_OS. it's potentially a bit confusing and s_lock.c should > probably be changed to include a better conditional. The compiler probably predefines something like __darwin__, which you should use. You can find out with touch foo.h cc -E -dM foo.h rm foo.h And finally, what's up with this: CFLAGS='-O0 -g -traditional-cpp' ? What's wrong with the "modern-cpp"? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Fallback behavior for "UNKNOWN" types -- proposed change
Thomas Lockhart <[EMAIL PROTECTED]> writes: > I propose that we modify the heuristic slightly, so that if there are > function matches with arguments from different categories, and if one or > more of the possible matches comes from the "string" category, then that > category is preferred. I would suggest a slightly different rule, but maybe it comes out at the same place in the end: if we can't find a unique match treating UNKNOWN the way we do now, try again assuming it is TEXT (or at least string category). As you say, this is reasonable given that the original literal looked like a string. BTW, I have been thinking that numeric literals ought to be initially assigned a new pseudo-type "UNKNOWNNUMERIC", which would eventually get coerced to one specific numeric type along the same lines as type assignment for string literals. This looks like it might help deal with the problems of float8 vs. numeric, etc. Don't have a complete proposal worked out yet, though. regards, tom lane
AW: AW: BLERe: AW: AW: [HACKERS] relation ### modified while in use
> > > > > Are there many applications which have many SELECT statements(without > > > > > FOR UPDATE) in one tx ? > > > > > > > > Why not ? > > > > > > > It seems to me that multiple SELECT statements in a tx has little > > > meaning unless the tx is executed in SERIALIZABLE isolation level. > > > > E.g. a table is accessed multiple times to select different data > > in an inner application loop. No need for serializable here. > > > > And seems no need to execute in one tx. Yes there is, if you need to do dml based on the results of the inner loop select statement. > Hmm,we seems to be able to call a cleanup procedure > internally which is equivalent to 'commit' after each > consecutive read-only statement. Is it a problem ? Which would, in the locking sense be the same thing as releasing the shared lock after each read only statement. It would only be done if the current tx did not modify any data yet. This is imho an awkward praxis that we should avoid at all costs. I have seen Oracle apps that start out with an update to a dummy table, just to be sure the transaction started. This is nonsense, that we imho don't want to copy. Also the result would be, that the first readonly statements are allowed to see schema changes, but selects after the first DML would not :-( Andreas
Re: [HACKERS] Two-phase commit
i'm developing one. a library for batch transactions, so you can continue processing in the middle of the file(or table) in case an abort happens. it can support multi-databases. i think i can share it to freshmeat. On Tue, 24 Oct 2000 13:52:38 +0200, [EMAIL PROTECTED] wrote: > Hello, > anyone thought about implementing two-phase commit to > be able to support distributed transactions ? > I have no clue how complex it would be, someone knows ? > > devik > > ___ Say Bye to Slow Internet! http://www.home.com/xinbox/signup.html
[HACKERS] Fallback behavior for "UNKNOWN" types -- proposed change
The parser has some heuristics to try to match up existing functions and operators when not all types are known apriori. We've had this capability since v6.4, with some modest evolution since then. Currently, if there is more than one function, say, which *could* match the specified query, and if the arguments with unspecified types (typically looking like a bare SQL9x string) come from different "categories" of types (e.g. integer and string, or float and date) then the parser throws an error about not finding the function. I propose that we modify the heuristic slightly, so that if there are function matches with arguments from different categories, and if one or more of the possible matches comes from the "string" category, then that category is preferred. There are two good reasons for this, and one bad reason ;) : 1) the original query carries "string" semantics, so it is a reasonable fallback interpretation for the query. 2) a string fallback will make things like select tstampfield at time zone 'pst' from t1; and select tstampfield at time zone interval '-08:00' from t1; possible (oh, btw, I've got patches to implement "at time zone..."), where currently select tstampfield at time zone 'pst' from t1; fails and requires that 'pst' be specified as "text 'pst'". 3) some braindead "compatibility tests" from some competing open-source database projects have poorly designed queries which interpret this lack of fallback as a lack of support for database features. So instead of getting extra points for having *more* capabilities in a particular area, they claim that we don't support anything in that area. Most annoying, and it is not likely to change. Comments? I've got code which implements the fallback for functions, and presumably the same for operators will be easy to do... - Thomas
Re: [HACKERS] relation ### modified while in use
> > > In my understanding,locking levels you provided contains > > > an implicit share/exclusive lock on the corrsponding > > > pg_class tuple i.e. AccessExclusive Lock acquires an > > > exclusive lock on the corresping pg_class tuple and > > > other locks acquire a share lock, Is it right ? > > > > No. Access...Locks are acquired over target table > > (table' oid is used as key for lmgr hash table), > > not over corresponding pg_class tuple, in what case > > we would use pg_clas' oid + table' oid as key > > (possibility I've described below). > > > > Yes,I know that "lock table" doesn't touch the correpon > ding pg_class tuple at all. However isn't it equivalent ? >From what POV? Lock manager will allow two simultaneous exclusive locks using these different methods (keys) and so we can interpret (use) them differently. Vadim
Re: [HACKERS] Re: Add support for
Tom Lane writes: > >> Actually, given your description of the problem, I'm half > >> inclined to revert the whole patch and instead make configure's > >> test for availability of first include > >> , so that that configure test will succeed on IRIX > >> etc. > > Pete, > After looking at this I'm confused again. The configure test > consists of seeing whether cpp will process > > #include > > without complaint. I can well believe that the full C compilation > process will generate errors if is included without > also including , but it's a little harder to believe > that cpp alone will complain. Could you double-check this? > > It would be useful to look at the config.log file generated by the > configure run that's reporting tcp.h isn't found. It should > contain the error messages generated by failed tests. On IRIX 6.5.5m I get the following error. The header is included by (nearly!) all of the standard headers. It is the IRIX equivalent of config.h if you will. In order to preprocess this test on IRIX a system header such as must precede . The logical choice of header to use is as tcp.h is supplying values for levels defined in in.h. This is an IRIX bug but I think that we need to work around it. configure:4349: checking for netinet/tcp.h configure:4359: cc -E conftest.c >/dev/null 2>conftest.out cc-1035 cc: WARNING File = /usr/include/sys/endian.h, Line = 32 #error directive: " must be included before ." #error " must be included before ." ^ configure: failed program was: #line 4354 "configure" #include "confdefs.h" #include -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
[HACKERS] RE: [INTERFACES] RE: JDBC now needs updates for large objects
Yes, the joins were one of the reasons I was going to do it. If no one starts a list by Saturday, then I'll start one when I go through JDBC. Peter -- Peter Mount Enterprise Support Officer, Maidstone Borough Council Email: [EMAIL PROTECTED] WWW: http://www.maidstone.gov.uk All views expressed within this email are not the views of Maidstone Borough Council -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 24, 2000 1:44 PM To: Peter Mount Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [INTERFACES] RE: JDBC now needs updates for large objects Peter Mount <[EMAIL PROTECTED]> writes: > Idea: As we have this type of query in more than one part of the source tree > (ie: psql, jdbc, probably odbc), should we have a section in the > documentation containing common queries, like: retrieving a list of tables, > views etc? That's a good thought. It'd be a useful practice to review such standard queries from time to time anyway. For example, now that outer joins work, a lot of psql's backslash-command queries could be simplified (don't need the UNION ALL WITH SELECT NULL hack). Anyone have time to work up a list? regards, tom lane
Re: [HACKERS] Re: Add support for
Pete Forman <[EMAIL PROTECTED]> writes: > On IRIX 6.5.5m I get the following error. The header is > included by (nearly!) all of the standard headers. It is the IRIX > equivalent of config.h if you will. > configure:4349: checking for netinet/tcp.h > configure:4359: cc -E conftest.c >/dev/null 2>conftest.out > cc-1035 cc: WARNING File = /usr/include/sys/endian.h, Line = 32 > #error directive: " must be included before ." > #error " must be included before ." >^ > configure: failed program was: > #line 4354 "configure" > #include "confdefs.h" > #include How bizarre. One would think it'd make more sense to just include the desired file, instead of going belly-up like that. > In order to preprocess this test on IRIX a system header such as > must precede . The logical choice of header > to use is as tcp.h is supplying values for levels > defined in in.h. > This is an IRIX bug but I think that we need to work around it. Roger, will do. regards, tom lane
Re: [HACKERS] Mailing list archives available?
On Tue, 24 Oct 2000, The Hermit Hacker wrote:
>
> http://www.postgresql.org/mhonarc has them all listed .. not sure how to
> get there from the Web site ... Vince?
There are links from both the Developer's Corner and User's Lounge ->
General Info.
Vince.
>
> On Mon, 23 Oct 2000, Krzysztof Kowalczyk wrote:
>
> > Are mailing list archives of various postgresql mailing list available
> > anywhere?
> >
> > I know they were some time ago but I couldn't find any link on
> > www.postgresql.org now. I subscribed to a list mainly because I want to
> > monitor the progress but the amount of messages kills my inbox. It would
> > be really convenient for me if I could just browse the archives on web
> > once in a while.
> >
> > Krzysztof Kowalczyk
> >
> >
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
>
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
Online Giftshop Superstorehttp://www.cloudninegifts.com
==
[HACKERS] Re: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.cxlogutils.c)
Vadim B. Mikheev - CVS writes: > Date: Tuesday, October 24, 2000 @ 05:56:09 > Author: vadim > > Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/access/transam > from hub.org:/home/projects/pgsql/tmp/cvs-serv70071/backend/access/transam > > Modified Files: > xact.c xlog.c xlogutils.c > > - Log Message - > > WAL misc We seem to be missing a file "src/include/access/xlogutils.h". -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] regress issues: UW7.1.1/PG7.1dev/GCC
Larry Rosenman writes: > comments .. failed > geometry .. failed > *** expected/comments.out Fri Jul 14 10:43:55 2000 > --- results/comments.out Sun Oct 22 19:38:45 2000 > *** > *** 42,47 > --- 42,48 > */ > /* This block comment surrounds a query which itself has a block comment... > SELECT /* embedded single line */ 'embedded' AS x2; > + ERROR: Unterminated /* comment > */ > SELECT -- continued after the following block comments... > /* Deeply nested comment. I'll bet lunch that the test driver is using an old psql that didn't know about nested comments. Similar for the plpgsql failure. You should use gmake installcheck to run the tests with the improved driver. The geometry failure is to be expected, all the others have passed for me on your box. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: [INTERFACES] RE: JDBC now needs updates for large objects
Peter Mount <[EMAIL PROTECTED]> writes: > Idea: As we have this type of query in more than one part of the source tree > (ie: psql, jdbc, probably odbc), should we have a section in the > documentation containing common queries, like: retrieving a list of tables, > views etc? That's a good thought. It'd be a useful practice to review such standard queries from time to time anyway. For example, now that outer joins work, a lot of psql's backslash-command queries could be simplified (don't need the UNION ALL WITH SELECT NULL hack). Anyone have time to work up a list? regards, tom lane
[HACKERS] Re: how to access backend pid from libpq ?
Hannu Krosing wrote: > > I was unable to find the way to access the backend pid from libpq > > It is probably saved somewhere as part of BackendKeyData message > but there seems to be no function to access it ? > > I'm using a temporary solution (my own 'C' function) but I'd like > to use the info already received. Ok, I found it from the libpq source: PQbackendPID I still think it could be documented ;) Hannu
Re: [HACKERS] Re: Add support for
>> This is an IRIX bug but I think that we need to work around it. > Roger, will do. I have changed configure in the CVS repository to test for netinet/tcp.h per your recommendation. At your convenience, please verify that it really does do the right thing on IRIX. regards, tom lane
[HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.c xlogutils.c)
> We seem to be missing a file "src/include/access/xlogutils.h". Ops, sorry - please create empty file, it will work (I have no its src at office comp -:(). Vadim
Re: [HACKERS] how to access backend pid from libpq ?
Hannu Krosing <[EMAIL PROTECTED]> writes: > I was unable to find the way to access the backend pid from libpq extern int PQbackendPID(const PGconn *conn); regards, tom lane
Re: [HACKERS] Re: Add support for
Tom Lane writes: > After looking at this I'm confused again. The configure test > consists of seeing whether cpp will process > > #include > > without complaint. I can well believe that the full C compilation > process will generate errors if is included without > also including , but it's a little harder to believe > that cpp alone will complain. Could you double-check this? I'm not quite sure whether it explains it, but note that preprocessor checks also "fail" when warnings are generated. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] how to access backend pid from libpq ?
I was unable to find the way to access the backend pid from libpq It is probably saved somewhere as part of BackendKeyData message but there seems to be no function to access it ? I'm using a temporary solution (my own 'C' function) but I'd like to use the info already received. --- Hannu
[HACKERS] Two-phase commit
Hello, anyone thought about implementing two-phase commit to be able to support distributed transactions ? I have no clue how complex it would be, someone knows ? devik
[HACKERS] Re: libpq needs -lsocket on UnixWare
> (other SVR4's prolly need -lsocket -lnsl) Something like AC_CHECK_LIB(socket,socket) or something like that? In fact, it complains about inet_aton and gethostbyname. -- contaminated fish and microchips huge supertankers on Arabian trips oily propaganda from the leaders' lips all about the future there's people over here, people over there everybody's looking for a little more air crossing all the borders just to take their share planning for the future Rainbow, Difficult to Cure
Re: AW: AW: BLERe: AW: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB wrote: [snip] > > Also the result would be, that the first readonly statements are allowed to > see schema changes, but selects after the first DML would not :-( > Does it mean that even read-only statements aren't allowed to release locks after other DMLs ? Regards. Hiroshi Inoue
[HACKERS] RE: JDBC now needs updates for large objects
I was going to redo those queries this coming weekend anyhow (as thats when I'll be getting some spare time next), as there are still some problems with the existing ones. Any other "minor" changes I should keep an eye out for? Idea: As we have this type of query in more than one part of the source tree (ie: psql, jdbc, probably odbc), should we have a section in the documentation containing common queries, like: retrieving a list of tables, views etc? I haven't seen a definitive one in there, but it would be useful, and have the other ones in the source be based on that one? Every time a change to the system tables is made, unless everyone who maintains the code that's dependent on it hears about it, the queries can quickly get out of sync. Peter -- Peter Mount Enterprise Support Officer, Maidstone Borough Council Email: [EMAIL PROTECTED] WWW: http://www.maidstone.gov.uk All views expressed within this email are not the views of Maidstone Borough Council -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 24, 2000 2:58 AM To: Peter Mount Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: JDBC now needs updates for large objects Peter, As of current sources, large objects no longer occupy tables named 'xinv' nor indexes named 'xinx'. Therefore, it'd be appropriate to remove the special tests that exclude tables/indices named that way from the tests in DatabaseMetaData.java. I have not done this because I'm not in a position to test changes to the JDBC driver; would you please add it to your todo list? regards, tom lane
AW: AW: [HACKERS] relation ### modified while in use
> More of that - while one xaction will wait to alter a table no new xaction > will be allowed to access this table too. Yes, I forgot, that placing an exclusive lock will make later shared lock requests wait. Andreas
AW: AW: AW: BLERe: AW: AW: [HACKERS] relation ### modified while in use
> > Also the result would be, that the first readonly statements are allowed to > > see schema changes, but selects after the first DML would not :-( > > Does it mean that even read-only statements aren't allowed > to release locks after other DMLs ? That is, what Tom is suggesting, but not after first DML but earlier after transaction start. I would like to avoid this. I want read only statements to release locks upon completion regardless of transaction state (except in serializable isolation). Andreas
Re: AW: BLERe: AW: AW: [HACKERS] relation ### modified while in use
Zeugswetter Andreas SB wrote: > > > > Are there many applications which have many SELECT statements(without > > > > FOR UPDATE) in one tx ? > > > > > > Why not ? > > > > > It seems to me that multiple SELECT statements in a tx has little > > meaning unless the tx is executed in SERIALIZABLE isolation level. > > E.g. a table is accessed multiple times to select different data > in an inner application loop. No need for serializable here. > And seems no need to execute in one tx. Hmm,we seems to be able to call a cleanup procedure internally which is equivalent to 'commit' after each consecutive read-only statement. Is it a problem ? Regards. Hiroshi Inoue
AW: BLERe: AW: AW: [HACKERS] relation ### modified while in use
> > > Are there many applications which have many SELECT statements(without > > > FOR UPDATE) in one tx ? > > > > Why not ? > > > It seems to me that multiple SELECT statements in a tx has little > meaning unless the tx is executed in SERIALIZABLE isolation level. E.g. a table is accessed multiple times to select different data in an inner application loop. No need for serializable here. Andreas
AW: AW: AW: AW: AW: [HACKERS] relation ### modified while in use
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > > Yes, and holding a row exclusive lock must imho at least > grab a shared > > table lock > > As indeed it does. Our disagreement seems to be just on the point of > whether it's safe to allow a read-only transaction to release its > AccessShareLock locks partway through. Yes, imho it must release the locks after each (read only) statement. > My opinion about that is colored by the known bugs that we have because > the parser/rewriter/planner currently do just that. You can cause the > system to become mighty confused if the report of a table schema change > arrives partway through the parse/plan process, because decisions > already made are no longer valid. I won't argue against that. I agree that the locks should be grabbed on first access and not released until statement end. But imho we can't hold them until tx end. > While we can probably patch the holes > in this area by holding a lock throughout processing of one statement, > I think that will just push the problem up to the application level. > How many apps are likely to be coded in a way that will be robust > against intra-transaction schema changes? I would not know one single of our programs, where adding a column, creating an index or changing the schema in any other intended way would have an impact on an application that is still supposed to work with this new schema. (One of the first SQL rules is e.g. to not use select *) And besides I do not think that this is a problem that we are allowed to solve on the db side, because it would flood us with locks. Remember that some other db's are always inside a transaction and it is standard to not do any commits if you work read only. The only case where I do agree that the lock needs to be held until tx end is in serializable transaction isolation. Andreas
