Re: [HACKERS] ERROR: index row size
Rodrigo Sakai wrote: Hello, I’m having a big trouble with the index size! I have looked for a solution in the internet, but the solutions that I found don’t fit for me! I would guess you have an allocation calculation error/memory leak somewhere in your implementation - maybe post a link to the actual C code (in case someone wants to have a look at it for you)! (Valgrind might help you here, otherwise you can set a few breakpoints in gdb and check what is going on). Cheers Mark ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Working with CVS documentation
I've now finished up initial content generation on the wiki page that covers using the CVS repository: http://developer.postgresql.org/index.php/Working_with_CVS That includes all the helpful comments suggested on this list in last month's threads on this topic along with a full dump of what was in my brain. The most complete section expands Heikki's workflow into a fleshed out example I think is good enough for new potential developers to use. I've also put some notes on the Discussion page of this article that lead to links on recent general trends in this area. Anyone who isn't familiar with distributed version control systems like Git or Mercurial should find those references one way to get up to speed on what's going on there. With high-profile projects like Apache recently committing to DVCS work these tools are really becoming mainstream. Some of that reading is both informative and periodically hilarious; my favorite quote is from Linus Torvalds, who says if you actually like using CVS, you shouldn't be here. You should be in some mental institution. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] syslogger line-end processing infelicity
Andrew Dunstan wrote: Magnus Hagander wrote: My second thought is that we should quite possibly abandon this translation altogether - we know that our COPY code is quite happy with either style of line ending, as long as the file is consistent, and also many Windows programs will quite happily read files with Unix style line endings (e.g. Wordpad, although not Notepad). Agreed. We shouldn't touch the data. Every editor I know on windows *except* notepad can deal just fine with Unix line endings, and if you're logging your queries your logfile will be too large to work well in notepad anyway :-) OK, so do we consider this a bug fix and backpatch it all the way to 8.0? Nobody's complained so far that I know of, and it's only damaged logs, not damaged primary data. I'm inclined just to fix it in HEAD, and release note the change in behaviour. It will matter more when we get machine-readable logs. Agreed, I don't think we need to backpatch it. And if you do, you only need to go as far as to 8.2, there are other bigger problems earlier than that - the reason we're deprecating 8.0 and 8.1 (on win32 only!) when 8.3 comes out. I guess if it applies with no changes you can backpatch all the way (if at all), but don't put any extra work into it, IMHO. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] IsTransactionState() is being used incorrectly
I just noticed that there are a number of places (mostly GUC assignment hooks) that use IsTransactionState() to decide if it's safe for them to do catalog lookups. This seems pretty bogus because IsTransactionState will return true in an aborted transaction. I'm not sure there's any actual bug because of other constraints on when GUC updates occur, but it sure looks like trouble waiting to happen. We could fix this either by changing the definition of IsTransactionState() or by introducing another test function with a different name. Any thoughts which is preferable? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] What is happening on buildfarm member baiji?
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: +sprintf(mutexName,postgresql.interlock.%i, portNumber); That won't do; it should be legal for two postmasters to listen on different IP addresses using the same port number. So you need to include some representation of the IP address being bound to. +if (GetLastError() == ERROR_ALREADY_EXISTS) +ereport(FATAL, +(errcode(ERRCODE_LOCK_FILE_EXISTS), + errmsg(interlock mutex \%s\ already exists, mutexName), + errhint(Is another postgres listening on port %i, portNumber))); ereport(FATAL) is quite inappropriate here. Do the same thing that bind() failure would do, ie, ereport(LOG) and continue the loop. Also, you probably need to think about cleaning up the mutex in case one of the later steps of socket-acquisition fails. We should only be holding locks on addresses we've successfully bound. I've done some further research on this on Win32, and I've come up with the following: If I set the flag SO_EXCLUSIVEADDRUSE, I get the same behavior as on Unix: Can only create one postmaster at a time on the same addr/port, and if I close the backend with a psql session running I can't create a new one until there is a timeout passed. However, if I just *skip* setting SO_REUSEADDR completely, things seem to work the way we want it. I cannot start more than one postmaster on the same addr/port. If I start a psql, then terminate postmaster, I can restart a new postmaster right away. Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32. Anybody see a problem with this? (A fairly good reference to read up on the options is at http://msdn2.microsoft.com/en-us/library/ms740621.aspx - which specifically talks about the issue seen on Unix as appearing with the SO_EXCLUSIVEADDRUSE parameter, which agrees with my testresults) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] What is happening on buildfarm member baiji?
Magnus Hagander wrote: However, if I just *skip* setting SO_REUSEADDR completely, things seem to work the way we want it. I cannot start more than one postmaster on the same addr/port. If I start a psql, then terminate postmaster, I can restart a new postmaster right away. Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32. Anybody see a problem with this? Is that true even if the backend crashes? cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] What is happening on buildfarm member baiji?
Andrew Dunstan [EMAIL PROTECTED] writes: Magnus Hagander wrote: Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32. Anybody see a problem with this? Is that true even if the backend crashes? It would take a postmaster crash to make this an issue, and those are pretty doggone rare. Not that the question shouldn't be checked, but we might decide to tolerate the problem if there is one ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] ERROR: index row size
Hello,
Ok, I give up! Tried a lot of things in my code! But still get error on
index row size. So, I'm part of my code, if someone could help me! A valid
value for this type is: '(03-jan-2007 , 15-may-2010)'
typedef struct t_periodo
{
DateADT tvi;
DateADT tvf;
} Periodo;
Datum
periodo_in(PG_FUNCTION_ARGS)
{
char*str = PG_GETARG_CSTRING(0);
chartvi_char[MAXDATEFIELDS];
chartvf_char[MAXDATEFIELDS];
tvi_char = (char *) palloc(strlen(MAXDATEFIELDS));
tvf_char = (char *) palloc(strlen(MAXDATEFIELDS));
Periodo *result;
if (sscanf(str, ( %s , %s ), tvi_char, tvf_char) != 2)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(invalid input syntax for periodo: \%s\, str)));
result-tvi = StringToDateADT(tvi_char);
result-tvi = StringToDateADT(tvf_char);
result = (Periodo *) palloc(sizeof(Periodo));
if (result-tvi result-tvf)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(Initial date (TVi) must be smaller than final date
(TVf;
PG_RETURN_POINTER(result);
}
Please help me!
Thanks in advance!
Re: [HACKERS] ERROR: index row size
Just glancing at this, a couple things stand out to me:
On Mon, 4 Jun 2007, Rodrigo Sakai wrote:
Datum
periodo_in(PG_FUNCTION_ARGS)
{
char*str = PG_GETARG_CSTRING(0);
chartvi_char[MAXDATEFIELDS];
chartvf_char[MAXDATEFIELDS];
tvi_char = (char *) palloc(strlen(MAXDATEFIELDS));
What are you doing here? This is completely broken. I think you meant to
say:
char *tvi_char;
tvi_char = palloc(MAXDATEFIELDS);
Or:
char tvi_char[MAXDATEFIELDS];
and no palloc.
tvf_char = (char *) palloc(strlen(MAXDATEFIELDS));
Same as above.
Periodo *result;
if (sscanf(str, ( %s , %s ), tvi_char, tvf_char) != 2)
This is asking for trouble if arbitrary input can be fed to this.
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(invalid input syntax for periodo: \%s\, str)));
result-tvi = StringToDateADT(tvi_char);
result-tvi = StringToDateADT(tvf_char);
result = (Periodo *) palloc(sizeof(Periodo));
if (result-tvi result-tvf)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(Initial date (TVi) must be smaller than final date
(TVf;
PG_RETURN_POINTER(result);
}
Please help me!
Thanks in advance!
Hope this helps.
--
My love, he's mad, and my love, he's fleet,
And a wild young wood-thing bore him!
The ways are fair to his roaming feet,
And the skies are sunlit for him.
As sharply sweet to my heart he seems
As the fragrance of acacia.
My own dear love, he is all my dreams --
And I wish he were in Asia.
-- Dorothy Parker
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] What is happening on buildfarm member baiji?
Magnus Hagander [EMAIL PROTECTED] writes: Given this, I propose we simply #ifdef out the SO_REUSEADDR on win32. Anybody see a problem with this? (A fairly good reference to read up on the options is at http://msdn2.microsoft.com/en-us/library/ms740621.aspx Hmm ... if accurate, that page says in words barely longer than one syllable that Microsoft entirely misunderstands the intended meaning of SO_REUSEADDR. It looks like SO_EXCLUSIVEADDRUSE might be a bit closer to the standard semantics; should we use that instead on Windoze? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ERROR: index row size
Jeremy Drake [EMAIL PROTECTED] writes: chartvi_char[MAXDATEFIELDS]; tvi_char = (char *) palloc(strlen(MAXDATEFIELDS)); What are you doing here? This is completely broken. Indeed ... *please* tell us your compiler issued a warning about that. If not an error --- none of the compilers I use will take it at all. Maybe you need to get a real C compiler. result-tvi = StringToDateADT(tvi_char); result-tvi = StringToDateADT(tvf_char); result = (Periodo *) palloc(sizeof(Periodo)); Well, you oughta allocate result before you store into it, not after, and I bet you meant to assign to the tvi and tvf fields, not tvi twice. Bad as these mistakes are, they don't directly explain why a later index entry creation would fail. What I'm betting is that your CREATE TYPE command does not correctly describe the datatype size. Based on this code it should be pass-by-reference, fixed-size-8-bytes, but I'll bet a nickel your CREATE TYPE says something else --- probably varlena. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ERROR: index row size
Hello Jeremy,
You are right about:
char tvi_char[MAXDATEFIELDS];
I have already tried this and didn't work too, it keeps giving the index
error!
About:
if (sscanf(str, ( %s , %s ), tvi_char, tvf_char) != 2)
I test tvi_char and tvf_char with StringToDateADT(tvi_char). Just date
types are allowed!
Any other suggestions??
Thanks!
-Original Message-
From: Jeremy Drake [mailto:[EMAIL PROTECTED]
Sent: segunda-feira, 4 de junho de 2007 00:23
To: Rodrigo Sakai
Cc: PostgreSQL Hackers
Subject: Re: [HACKERS] ERROR: index row size
Just glancing at this, a couple things stand out to me:
On Mon, 4 Jun 2007, Rodrigo Sakai wrote:
Datum
periodo_in(PG_FUNCTION_ARGS)
{
char*str = PG_GETARG_CSTRING(0);
chartvi_char[MAXDATEFIELDS];
chartvf_char[MAXDATEFIELDS];
tvi_char = (char *) palloc(strlen(MAXDATEFIELDS));
What are you doing here? This is completely broken. I think you meant to
say:
char *tvi_char;
tvi_char = palloc(MAXDATEFIELDS);
Or:
char tvi_char[MAXDATEFIELDS];
and no palloc.
tvf_char = (char *) palloc(strlen(MAXDATEFIELDS));
Same as above.
Periodo *result;
if (sscanf(str, ( %s , %s ), tvi_char, tvf_char) != 2)
This is asking for trouble if arbitrary input can be fed to this.
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(invalid input syntax for periodo: \%s\, str)));
result-tvi = StringToDateADT(tvi_char);
result-tvi = StringToDateADT(tvf_char);
result = (Periodo *) palloc(sizeof(Periodo));
if (result-tvi result-tvf)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(Initial date (TVi) must be smaller than final date
(TVf;
PG_RETURN_POINTER(result);
}
Please help me!
Thanks in advance!
Hope this helps.
--
My love, he's mad, and my love, he's fleet,
And a wild young wood-thing bore him!
The ways are fair to his roaming feet,
And the skies are sunlit for him.
As sharply sweet to my heart he seems
As the fragrance of acacia.
My own dear love, he is all my dreams --
And I wish he were in Asia.
-- Dorothy Parker
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] ERROR: index row size
Indeed ... *please* tell us your compiler issued a warning about that. I did shell scripts that suppress the warnings, so it was a big mistake, I agree! But I think my problem is not here! Well, you oughta allocate result before you store into it, not after, and I bet you meant to assign to the tvi and tvf fields, not tvi twice. You are right again. But this happened because I copy and paste the example with a different order. But in my code all this is ok! Bad as these mistakes are, they don't directly explain why a later index entry creation would fail. What I'm betting is that your CREATE TYPE command does not correctly describe the datatype size. Based on this code it should be pass-by-reference, fixed-size-8-bytes, but I'll bet a nickel your CREATE TYPE says something else --- probably varlena. Humm, this can help! I will investigate! Thanks a lot! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
