[HACKERS] btree fast-root on VACUUM FULL
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 () "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
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
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
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
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
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
