Peter Eisentraut [EMAIL PROTECTED] wrote:
Reentrancy is (usually) a property of the interface (hence *_r functions
with differing interfaces), thread-safety is a feature of the
implementation;
May I not agree with this definition ?
Reentrancy is a property of the implemention that
assure
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another problem is that the CREATE FUNCTION syntax doesn't insist on any
particular ordering of the attributes;
This is so at the moment, while all samples use AS LANGUAGE. This
could stay free format if quoted as usual, and
On Mon, 1 Sep 2003, Peter Eisentraut wrote:
Greg Stark writes:
Um. I don't think that's true. I mean, in theory it's true, but in practice
why would an OS have some *_r but have only non-thread-safe versions of
others?
The question is whether configure can reliably identify whether
Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes:
For remote connections I added:
host all all :::192.168.41.0/120trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3? It is no nice
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
I didn't consider *removing* flexibility, but *adding*
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
That was me, and I'm glad to see you can do it. I guess I
Tom Lane wrote:
psql may indeed work with no changes, because it's too stupid to know
when you're defining a function, and so it would not be surprised to get
a Start Copy In back from a CREATE FUNCTION command. This would not be
true of nearly any other client that one might use to define a
Tom Lane wrote:
Tommi =?iso-8859-15?q?M=E4kitalo?= [EMAIL PROTECTED] writes:
For remote connections I added:
host all all :::192.168.41.0/120trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3?
Quick fix is probably to turn IPv6 off in the kernel unless it's needed
- on my RH box that is as simple as removing a line from
/etc/sysconfig/network and rebooting
Kurt Roeckx knows more about this than I do, but I know when I turned
IPv6 on I had to do something similar to what is below - I
Maybe to free up Bruce for major patches (eg. PITR, etc.), we should promote
someone else to 'minor patch' committer?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's
Andreas Pflug [EMAIL PROTECTED] writes:
But we're not talking about psql only (and \beginlit and \endlit are
quite ugly sql keywords), and this should be a backend thing only
I disagree with both of those assertions. psql is the issue because
other clients used for administrative work
Andreas Pflug [EMAIL PROTECTED] writes:
How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.
Hmm. I could go for that, if it weren't
Andrew Dunstan [EMAIL PROTECTED] writes:
Frontends would not be forced to use something that triggered this -
after all we have to stay backwards compatible and support the existing
inline string, no?
Certainly. I didn't see anyone proposing to break backwards
compatibility.
Marc G. Fournier wrote:
On Mon, 1 Sep 2003, Peter Eisentraut wrote:
Greg Stark writes:
Um. I don't think that's true. I mean, in theory it's true, but in practice
why would an OS have some *_r but have only non-thread-safe versions of
others?
The question is whether
Mendola Gaetano wrote:
I seen on this list a lot of energy ( also little flames involving SCO
Co. ) spent on thread safety;
was really necessary spent so much energy in this direction?
I was at Fosdem in Bruxelles ( I spoke there about the use
of postgres in my project ) and I seen al
committing a major patch isn't to difficult ... its getting the major
patch created that is ... PITR and Win32 don't exist in v7.4 because no
patch was submit'd, not because Bruce didn't have time to commit them ...
On Tue, 2 Sep 2003, Christopher Kings-Lynne wrote:
Maybe to free up Bruce for
Johan Henselmans wrote:
Hi, I have just subscribed to the hackers mailinglist to telll what my
adventures are with 7.4.b2 and OS X so far.
I have encountered some problems, and have some solutions, off which I
do not know if they break the port, or do something wrong.
gcc3.3
=
Hi all
Can anyone tell me the approximate pg 7.5 release date?
Thanks
Josh
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Tue, 2 Sep 2003, postgresql wrote:
Hi all
Can anyone tell me the approximate pg 7.5 release date?
Summer of '04 ... approximate :)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Tue, 2 Sep 2003 03:06 am, Mendola Gaetano wrote:
May be I'm wrong but I'd like know why thread safety was so
necessary.
It bugged Lee enough that he went and wrote a patch for it. It bugged me
enough that I couldn't use it on our choice of platform (older Linux) that I
did some little
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.
I think that may be reasonable. What bothers me is that the default
pg_hba.conf will fail
Bruce Momjian [EMAIL PROTECTED] writes:
Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?
I don't see a good way yet. The fly in the ointment is that HAVE_IPV6
is set by configure based on the capabilities of userland
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I thought it was a case of Bruce not having time to work on them, because he
was too busy doing patch application and stuff.
Bruce would probably be the right person to opine on this, but my
impression is that patch application is just a tiny
--On Tuesday, September 02, 2003 00:04:35 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
Oh, interesting. So you are saying that if the OS supports threads,
then we use the *_r if they have them, and assume the non *_r
functions are already thread-safe if they don't.
On Mon, 1 Sep 2003, jconway wrote:
You haven't shown us your function or how you're trying to call it. In
any case, works here:
regression=# CREATE FUNCTION foo(INTEGER[], INTEGER) RETURNS INTEGER AS
'select ss.f[1] from (select $1 || $2 as f) as ss' language sql;
CREATE FUNCTION
Am Dienstag, 2. September 2003 02:30 schrieb Andrew Dunstan:
Quick fix is probably to turn IPv6 off in the kernel unless it's needed
- on my RH box that is as simple as removing a line from
/etc/sysconfig/network and rebooting
Quick fix is to put the right IPv6-adresses into pg_hba.conf,
Tom Lane writes:
Greg Stark [EMAIL PROTECTED] writes:
On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't exist then the platform simply
When trying to build the CVS source on a HP-UX 11.00 box:
HP-UX hpux B.11.00 A 9000/800
We got the configure error:
error
checking types of arguments for accept()... configure: error: could not
determine argument types
/error
Check the config.log, it said that the configure script can't find the
Hi!
After holding my breath for quite a while, it bursts out... I'd really like to
get a status update on said port.
The reason is, it's seemingly put on hold for me. After this port was talked
over on the list, there seemed to be an explosion of effort, with initial
success stories. I did
Lee Kindness writes:
Tom Lane writes:
Greg Stark [EMAIL PROTECTED] writes:
On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.
Hmm. I could go for
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?
I don't see a good way yet. The fly in the ointment is that HAVE_IPV6
is set by configure based on the
Hi,
the patch did not help.
Maybe it would help dumping all pg_hba.conf-etries after generation of
IPv6-adresses.
But there is another problem, which is related. I get a logentry:
LOG: could not bind IPv4 socket: Die Adresse wird bereits verwendet
Sorry - I have errormessages in german - I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i've tried to write a stored function in C++, using the libpq library, but
the g++(3.3.1) was unable to pass through the headers. there are a lot's
of reserved words used in structs as member names, such as delete,using,
namespace, and so on.
On 2 Sep 2003 at 15:50, Czuczy Gergely wrote:
-BEGIN PGP SIGNED MESSAGE-
i'm using pgsql 7.3.4.
how can I fix it? i think so, i should modify the header files, i've tried
to put it into an ``extern C {...}'' block, but i didn't solve anything.
Try putting extern C, around include
hello
as i said, i've tried to put into into an extern C statement, but it
didn't solve anything
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
PGP pubkey: http://phoemix.harmless.hu/phoemix.pgp
iRCNet: #demoscene ICQ: 8067175
The point is, that geeks are not necessarily the outcasts
society
Tommi Maekitalo wrote:
Hi,
the patch did not help.
Strange. Do you get a client side message hba.conf entry for
::.127.0.0.1 missing?
On my system the usual 127.0.0.1 255.255.255.255 is correctly converted to
:::127.0.0.1 ::::::255.255.255.255 and works
fine.
Czuczy Gergely wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i've tried to write a stored function in C++, using the libpq library, but
the g++(3.3.1) was unable to pass through the headers. there are a lot's
of reserved words used in structs as member names, such as delete,using,
On Tue, 2 Sep 2003, Shridhar Daithankar wrote:
On 2 Sep 2003 at 15:50, Czuczy Gergely wrote:
-BEGIN PGP SIGNED MESSAGE-
i'm using pgsql 7.3.4.
how can I fix it? i think so, i should modify the header files, i've tried
to put it into an ``extern C {...}'' block, but i didn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
thanks to Andreas Pflug's hint, it's now working, thank you.
libpq++ is not gone, i just don't like it. I've written an other C++ API
for databse systems, name SDBI, but i cannot use it for a stored procedure
:)
thanks
Bye,
Gergely Czuczy
Hi,
I doublechecked, that the patch applied. And there is a change. It workes for
connections from remote or to the ethernet-address, but not to localhost:
[EMAIL PROTECTED]:~ export PGHOST=localhost
[EMAIL PROTECTED]:~ psql -l
psql: FATAL: no pg_hba.conf entry for host ::1, user postgres,
Weiping He [EMAIL PROTECTED] writes:
Check the config.log, it said that the configure script can't find the
argument types
fo 'accept()'.
Could you show us the relevant section of config.log, instead of giving
a summary with no details? I'd like to see the compiler error messages
and failed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
once again :)
the code is this:
text *src;
void *tmp;
src = (text*)tmp;
and the error message:
error: parse error before `)' token
(at (text*_)_)
originally i've tried to use the macro PG_GETARG_TEXT_P(0), but when i've
got this
Tommi Maekitalo wrote:
Hi,
I doublechecked, that the patch applied. And there is a change. It workes for
connections from remote or to the ethernet-address, but not to localhost:
[EMAIL PROTECTED]:~ export PGHOST=localhost
[EMAIL PROTECTED]:~ psql -l
psql: FATAL: no pg_hba.conf entry for
I've found a number of infelicities in the hash index code that can't be
fixed without an on-disk format change. The biggest one is that the
hashm_ntuples field in hash meta pages is only uint32, meaning that
hash index space management will become confused if the number of
entries exceeds 4G.
Hi,
I think this would be interesting for many postgresql users.
The opensource database market is moving where quick at the moment, see
the sh*t with sapdb and mysql. So it would be very interesting if there
is a free alternative for windows and linux in the near future, because
some customers
I found following mail in my mail archive and tried the same test with
7.4 current. Contrary to my expectation 7.4 showed some performance
degration with continuous pgbench runs:
$ pgbench -c 5 -t 1000 -n test
tps = 57.444037 (including connections establishing)
tps = 57.455300 (excluding
On Tue, Sep 02, 2003 at 04:09:26PM +0200, Czuczy Gergely wrote:
libpq++ is not gone, i just don't like it. I've written an other C++ API
for databse systems, name SDBI, but i cannot use it for a stored procedure
:)
I've never looked at writing native stored procedures, but do you think
this
Forgot to mention an important thing: I set enable_seqscan = off in
postgresql.conf.
I found following mail in my mail archive and tried the same test with
7.4 current. Contrary to my expectation 7.4 showed some performance
degration with continuous pgbench runs:
$ pgbench -c 5 -t 1000 -n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i only have to fetch the procedure's arguments and return the proper
value. this is the only part where i basically use the pgsql's functions,
the function's task is only some calculations, and to speed up things. in
C its _much_ faster than in
Lee Kindness wrote:
Tom Lane writes:
Greg Stark [EMAIL PROTECTED] writes:
On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
APIs. They can never be made thread-safe. The *_r versions of these functions
are standardized and required. If they don't exist then
Peter Eisentraut wrote:
Lee Kindness writes:
You don't... and you simply shouldn't care. If there is a_r version
available then we should use it - even if the plain version is safe.
The problem with this is that the automatic determination (in configure)
whether there is a xxx_r()
*nod* but it would be nicer if all loopback interfaces worked by default
- hence my localhost suggestion, which would match any of
127.0.0.1/32
:::127.0.0.1/128 and
::1/128
cheers
andrew
Andreas Pflug wrote:
Tommi Maekitalo wrote:
Hi,
I doublechecked, that the patch applied. And
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
Lee Kindness writes:
You don't... and you simply shouldn't care. If there is a_r version
available then we should use it - even if the plain version is safe.
The problem with this
Larry Rosenman wrote:
Where does it say that you have to use getpwuid_r() to be thread safe?
I don't see any mention in the docs. It does say about getpwuid:
For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
fgetpwent, all information is contained in a static area, so
--On Tuesday, September 02, 2003 11:32:08 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
Where does it say that you have to use getpwuid_r() to be thread safe?
I don't see any mention in the docs. It does say about getpwuid:
For getpwent, getpwuid, getpwnam,
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
Lee Kindness writes:
You don't... and you simply shouldn't care. If there is a_r version
available then we should use it - even if the plain
--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
Lee Kindness writes:
You don't... and you simply shouldn't care. If
I am still getting the duplicate case value problem trying to compile the
CVS head on AIX 4.2.1.
gmake[4]: Entering directory
`/usr/local/postgres/pgsql/src/backend/utils/error'
gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../sr
c/include -I/usr/local/ssl/include -c
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
I recon i'll get blue in the face before long, and one of you guys
will fly over to Scotland to give me a good kicking!... But'll say it
again anyway...
That's not our
Bruce Momjian writes:
Lee Kindness wrote:
No, it's not. Using the _r functions on such systems is BETTER because
the API is clean and the function can be implmented in a reentrant and
thread-safe fashion wuithout the need for thread local storage or
mutex locking.
I don't care
Samuel A Horwitz [EMAIL PROTECTED] writes:
c/include -I/usr/local/ssl/include -c -o elog.o elog.c
elog.c: In function `errcode_for_file_access':
elog.c:546: duplicate case value
elog.c:539: previously used here
gmake[4]: *** [elog.o] Error 1
[ scratches head ... ] EEXIST and ENOTEMPTY are
Lee Kindness writes:
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
That's not our concern - if the OS isn't thread safe we can't do
anything about it, and to worry about it is an enormous waste of
development
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Lee Kindness writes:
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
That's not our concern - if the OS isn't thread safe we
Lee Kindness wrote:
Bruce Momjian writes:
Lee Kindness wrote:
No, it's not. Using the _r functions on such systems is BETTER because
the API is clean and the function can be implmented in a reentrant and
thread-safe fashion wuithout the need for thread local storage or
mutex
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Lee Kindness writes:
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
That's not our
'k ... quick and dirty summary .. Bruce will probably add to it, but I
know he's busy ... he's so busy that some of the stuff that we put in
place for the Win32 hasn't even been announced yet :)
First, there was a branch created a couple of weeks ago: WIN32_DEV that
you can access via anon cvs
Peter Eisentraut [EMAIL PROTECTED] writes:
In fact, I like the criterion that a warning should be raised rather than
a notice if the effect of the command deviates from what the command
actually says.
Um. If I construe that literally, then the notices about identifier
truncation need to be
--On Tuesday, September 02, 2003 18:12:48 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Lee Kindness writes:
Bruce Momjian writes:
Right. We can't assume because a *_r
Marc G. Fournier wrote:
'k ... quick and dirty summary .. Bruce will probably add to it, but I
know he's busy ... he's so busy that some of the stuff that we put in
place for the Win32 hasn't even been announced yet :)
First, there was a branch created a couple of weeks ago: WIN32_DEV
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
D:\POSTGRESQL-7.4BETA2\SRC\INTERFACES\LIBPQ\RELEASE\BLIBPQ.LIB|getaddrinfo
Error: Unresolved external '_pqStrerror' referenced from
Larry Rosenman wrote:
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
That's not our concern - if the OS isn't thread safe we can't do
anything about it, and to worry about it is an enormous waste of
--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
Bruce Momjian writes:
Right. We can't assume because a *_r function is missing that
the normal function is thread-safe.
That's not our concern - if the OS isn't thread
Darko Prenosil wrote:
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
D:\POSTGRESQL-7.4BETA2\SRC\INTERFACES\LIBPQ\RELEASE\BLIBPQ.LIB|getaddrinfo
Error: Unresolved external '_pqStrerror'
Tatsuo Ishii [EMAIL PROTECTED] writes:
I found following mail in my mail archive and tried the same test with
7.4 current. Contrary to my expectation 7.4 showed some performance
degration with continuous pgbench runs:
I did some profiling and found that with repeated runs, an increasing
So far as I'm aware Joerg, we didn't have enough time to get all the Win32
stuff done for 7.4, and it was felt (rightly so) that it wasn't worth
holding off on 7.4 to get it in.
At the moment, the main developers are doing nothing but fixing bugs in 7.4
as we are now in feature freeze.
Once 7.4
In fact, I like the criterion that a warning should be raised rather than
a notice if the effect of the command deviates from what the command
actually says. That puts the messages for serials, primary keys, drop
cascades clearly into notices, messages about missing, implicitly added,
or
This is the Pg backend line from top after about 90 minutes runtime :
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
16083 postgres 17 0 9172 9172 8524 R 94.7 2.4 84:59.68 postmaster
No sign of the shared growth stopping at this stage...
Pg built with --disable-debug
I am seeing a slow but steady growth of the backend process on a Linux
box (RHL 8.0) --- top shows it growing a few K every few seconds.
But I see *zero* growth with the same test on HPUX 10.20.
A possible wild card is that the Postgres build I'm using on the Linux
box is compiled for profiling
I can hardly imagine that the backend started working with 9mb of
memory. what did you do that PostgreSQL needed so much memory from the
beginning??? are you using the default settings? usually the postmaster
does not need more than 3mb at startup (in this scenario).
On FreeBSD, every one of
Tom Lane wrote:
Weiping He [EMAIL PROTECTED] writes:
Check the config.log, it said that the configure script can't find the
argument types
fo 'accept()'.
Could you show us the relevant section of config.log, instead of giving
a summary with no details? I'd like to see the compiler
Weiping He [EMAIL PROTECTED] writes:
I've put the config.log on:
http://www.pgsqldb.org/config.log
configure:10847: cc -Ae -c +O2 -D_XOPEN_SOURCE_EXTENDED conftest.c 5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product;
ignored.
Get a real compiler :-(
The
Hi Guys,
This page:
http://developer.postgresql.org/docs/postgres/functions-misc.html
Says that pg_get_triggerdef has no pretty print option. Is this actually
true?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Says that pg_get_triggerdef has no pretty print option. Is this actually
true?
\df agrees. Right offhand I don't see much scope for prettyprinting in
CREATE TRIGGER ...
regards, tom lane
Hi guys,
Where can I find a list of all the 'special' characters in the ~* operator?
Thanks,
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
take a look at the HTML docs(found in postgres.tar.gz, in the source
tarball), and see functions-matching.html
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
PGP pubkey: http://phoemix.harmless.hu/phoemix.pgp
iRCNet: #demoscene ICQ: 8067175
Tom Lane wrote:
Weiping He [EMAIL PROTECTED] writes:
I've put the config.log on:
http://www.pgsqldb.org/config.log
configure:10847: cc -Ae -c +O2 -D_XOPEN_SOURCE_EXTENDED conftest.c 5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product;
ignored.
Get a
I understand that ObjID of LOCKtag recognizes each individual row locked by
a row level lock. BUt i have noticed that if i lock 2 different rows of the
same table they have the same blkno. is this deduction ok?
thanks
jenny
_
Get
Jenny - [EMAIL PROTECTED] writes:
I understand that ObjID of LOCKtag recognizes each individual row locked by
a row level lock. BUt i have noticed that if i lock 2 different rows of the
same table they have the same blkno. is this deduction ok?
If they happen to be stored in the same block,
I understand that ObjID of LOCKtag recognizes each individual row locked
by
a row level lock. BUt i have noticed that if i lock 2 different rows of
the
same table they have the same blkno. is this deduction ok?
If they happen to be stored in the same block, they'd have the same blkno
...
90 matches
Mail list logo
