[HACKERS] table-level and row-level locks.

2003-07-11 Thread Jenny -


Iam trying to acquire rowlevel locks in postgresql. I try doing this: 
'select * from students where name='Larry' for update;
But by looking at the holding array of proclock , I've noticed that by doing this only 
AccessShareLock gets acquired which is a table level lock. 
How do I acquire rowlevelock and what fields of Lock or Proclock datastructures indicate it.
Thanks
JennyHelp STOP SPAM with the new MSN 8  and get 2 months FREE*


[HACKERS] btree fast-root on VACUUM FULL

2003-07-11 Thread Alvaro Herrera
Hackers (especially Tom),

Would it be right to set the fast-root as true root during a VACUUM
FULL?  This would free all pages between true root and fast root.

(I'm not advocating to do it, nor volunteering; I'm merely wondering).

-- 
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
Ninguna manada de bestias tiene una voz tan horrible como la humana (Orual)

---(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


Re: [HACKERS] btree fast-root on VACUUM FULL

2003-07-11 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes:
 Would it be right to set the fast-root as true root during a VACUUM
 FULL?  This would free all pages between true root and fast root.

Possibly okay, but why bother?  It's hardly likely to free a meaningful
number of pages.  And I think you'd need to invent another category of
WAL record to log the action, so the code overhead to make it happen
isn't trivial.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] Transaction handling in extended query mode and Sync

2003-07-11 Thread Francisco Figueiredo Jr.
Carlos Guzman Alvarez wrote:
Hello:

Hello Carlos.

I continue to work in the implementation of the 3.0 protocol in C#, i'm 
making a test that consist on:

- Create a database.
- Create a table in the new database.
- Start transaction.
- Insert 100 rows of data in the new table.
- Commit transaction.
For start a transaction i send a Query message with this as statement text:

START TRANSACTION ISOLATION LEVEL READ COMMITTED

For commit a transaction i send a Query message with this as statement 
text:

COMMIT TRANSACTION

For execute the inserts i use parametrized commands with Extended query 
mode, sending this sequence of messages:

- Parse  Flush ( Only for the first command )
- Describe  Flush ( Only for the first command )
- Close Portal ( begining at second command )
- Bind  Flush
- Execute  Sync
But the Sync message seems to be commiting the transaction, if i send a 
Flush message all works as expected with inserts, but create database  
table will not work.

Sorry for late response...
I could finally get Npgsql to talk protocol 3.0 version :) It is not 
100% but it is near...
I give it a try in a test similar to yours... I didn't send the create 
database commands just the row insertion.

in both sequences, I could get the desired behaviour.
I could send the begin transaction in simple query mode, send the insert 
in extended mode and send a commit or rollback in simple mode sending 
the sync message in the end of extended mode.

Are you still having problems with it?

I hope it helps.

--
Regards,
Francisco Figueiredo Jr.

--
My grandfather once told me that there are two
kinds of people: those
who work and those who take the credit. He told me
to try to be in the
first group; there was less competition there.
- Indira Gandhi
---(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


[HACKERS] corrupt data

2003-07-11 Thread Zeno R.R. Davatz
Hi List

Out of some reason our data of our postgresql database has been corrupted. When we try 
to connect to the database we get:

psql: ERROR:  _mdfd_getrelnfd: cannot open relation pg_type_oid_index:
No such file or directory

REINDEX does not work. We get the same error. 

pgfsck gives us: wrong blockseize.

We are using postgresql 7.3.3-1 (debian).

Thanks for any hints and feedback.

Zeno

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] again: Bug #943: Server-Encoding from

2003-07-11 Thread Enke, Michael
Tatsuo Ishii wrote:
 
  I have looked into my Linux box and found this in /usr/share/i18n/charmaps/BIG5.gz:
  % Chinese charmap for BIG5 (CP950)
  % version: 0.92
  % Contact: Tung-Han Hsieh   [EMAIL PROTECTED]
  %  Yuan-Chung Cheng [EMAIL PROTECTED]
  % Distribution and use is free, even for comercial purpose.
  %
  % This charmap is converted from:
  % ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP950.TXT
  % ...
 
  There my characters are in.
 
 That's a M$'s definition, not a standard. I think there should be a
 reason why the Unicode org. does not use it.

Ok, I do not know the reason. But since also the glibc uses it, couldn't you use it 
too?
I believe the glibc delveloper have thought about this a lot. And they came to the
conclusion to use this definition. Why not postgresql?

  Don't you agree that it is strange that I can (for EUC_TW) copy to file without 
  error
  but I can not copy from file without error?
 
 I'm not quite sure what you are saying. Are you complaining that (for
 example) 0xe7a281 in UTF-8 does not convert to EUC_TW?

Yes exactly, since this value comes from a copy to with PGCLIENTENCODING=EUC_TW

 
 BTW, what do you think about below?
 
 FYI, CNS 11643-1993 is the standard character set and EUC_TW is the
 one of the encodings. That means your problem below will disappear.

Ok.

Regards,
Michael

 WARNING:  copy: line 2, LocalToUtf: could not convert (0x8ea3cfd0) EUC_TW to 
 UTF-8. Ignored
 WARNING:  copy: line 3, LocalToUtf: could not convert (0x8ea3c4ce) EUC_TW to 
 UTF-8. Ignored
 WARNING:  copy: line 4, LocalToUtf: could not convert (0x8ea3bdfe) EUC_TW to 
 UTF-8. Ignored
 
 Hum. These seem to be CNS 11643-1993, plane 3. Currently PostgreSQL
 supports only:

 CNS 11643-1993, plane 0
 CNS 11643-1993, plane 1
 CNS 11643-1993, plane 2
 CNS 11643-1993, plane 15

 Would you like to have support for rest of CNS 11643-1993 planes:

 CNS 11643-1993, plane 3
 CNS 11643-1993, plane 4
 CNS 11643-1993, plane 5
 CNS 11643-1993, plane 6
 CNS 11643-1993, plane 7

 support for upcoming 7.4?
 --
 Tatsuo Ishii

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] [GENERAL] PG crash on simple query, story continues

2003-07-11 Thread Maksim Likharev
So following modification seems to fixed all PG (7.3/7.3.3)crashes on
Solaris ( NON C LOCALE )

selfuncs.c line 2356:

I changed:
xfrmsize = strlen(val) + 32;/*arbitrary pad value here...*/
to
xfrmsize = strxfrm(NULL, val, 0) + 32;

so basically instead of wild guess of transformed string size I asking
strxfrm for that.

+32 out my desperation, strxfrm(NULL, val, 0) + 1 should be fine ( have
not tested that )...

Out of curiosity:
Really interesting, following condition seems to be impossible anymore,
of cause if something went terribly wrong,

die here, return original string, return empty string?

if (xfrmlen = xfrmsize) {
pfree(xfrmstr);
xfrmstr = (char *) palloc(xfrmlen + 1);
xfrmlen = strxfrm(xfrmstr, val, xfrmlen + 1);
}


Again fixed all crashes on Sun 5.8 ( PG 7.3.3, en_US locale, LATIN1
encoding )  Generic Patch...

P.S
NO SUPPORT, NO WARRANTY, NO NOTHING, just for you information.

Regards.

-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 3:58 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues 


Maksim Likharev [EMAIL PROTECTED] writes:
  On failure, strxfrm() returns (size_t)-1.

Not according to the Single Unix Specification, Linux, or HP-UX;
I don't have any others to check.  But anyway, that is not causing
your problem, since palloc(0) would complain not dump core.

 I am on SunOS 5.8, 

Solaris, eh?  IIRC, it was Solaris that we last heard about broken
strxfrm on.  Better check to see if Sun has a fix for this.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings