Re: [HACKERS] Postgresql and multithreading
On 16 Oct 2002 at 1:25, Bruce Momjian wrote: Anuradha Ratnaweera wrote: Thanks, Bruce. But what I want to know is whether multithreading is likely to get into in postgresql, say somewhere in 8.x, or even in 9.x? (as they did with Apache). Are there any plans to do so, or is postgres going to remain rather a multi-process application? It may be optional some day, most likely for Win32 at first, but we see little value to it on most other platforms; of course, we may be wrong. I am also not sure if it is a big win on Apache either; I think the Well, I have done some stress testing on 1.3.26 and 2.0.39. Under same hardware and network setup and same test case, 1.3.26 maxed at 475-500 requests/sec and 2.0.39 gave flat 800 requests/sec. Yes, under light load, there is hardly any difference. But Apache2 series is definitely an improvement. jury is still out on that one, hence the slow adoption of 2.X, and we don't want to add threads and make a mess of the code or slow it down, which does often happen. Well, slow adoption rate is attributed to 'apache 1.3.x is good enough for us' syndrome, as far as I can see from news. Once linux distros start shipping with apache 2.x series *only*, the upgrade cycle will start rolling, I guess. Bye Shridhar -- Programming Department: Mistakes made while you wait. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Postgresql and multithreading
On 16 Oct 2002 at 15:40, Gavin Sherry wrote: In that case, I wonder if it is worth folking a new project to add threading support to the backend? Of course, keeping in sync with the original would be lot of work. http://sourceforge.net/projects/mtpgsql Last discussion that happened for multithreading was not to add threads per connection like mysql, but to split tasks between threads so that IO blocking and efficiently using SMP abilities would be taken care off IIRC.. One thread per connection isn't going to change much, at least for mainstream postgresql. For embedded, it might be a necessity.. Bye Shridhar -- QOTD: You're so dumb you don't even have wisdom teeth. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
On 15 Oct 2002 at 18:19, Bruce Momjian wrote: We are showing up in places I never expected: .org registry, tons of books, conventions, everywhere. It is just a wave that keeps getting bigger and bigger. I am starting to imagine what Linus felt seeing Linux take off; you just sit around and wonder how it is all happening, and of course, it is happening because you offer a unique value to users, and their sharing with others just makes it continue to grow. Sigh.. I wish enough people could understand difference between cost and value and more importantly apply the understanding while making a judgement.. Bye Shridhar -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, Errand of Mercy, stardate 3198.9 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Vacuum improvement
On 16 Oct 2002, Hannu Krosing wrote: On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote: Hi all, I'm thinking that there is an improvement to vacuum which could be made for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's very little an application can do to minimise dead-tuples, particularly if the table is randomly updated. Wouldn't it be beneficial if VACUUM could have a parameter which specified how much of the table is vacuumed. That is, you could specify: VACUUM FULL test 20 precent; What about VACUUM FULL test WORK 5 SLEEP 50; meaning to VACUUM FULL the whole table, but to work in small chunks and relaese all locks and let others access the tables between these ? Great idea. I think this could work as a complement to the idea I had. To answer Tom's question, how would we know what we've vacuumed, we could store the range of tids we've vacuumed in pg_class. Or, we could store the block offset of where we left off vacuuming before and using stats, run for another X% of the heap. Is this possible? Gavin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DROP USER weirdness in 7.2.1
Peter Eisentraut said: Daniel Kalchev writes: One would normally expect, that when DROP USER someuser is issued, all associated data structures will be readjusted, especially ownership and ac cess rights. Perhaps, but the documentation states otherwise. [...] Any resolution for this? Recreate the user with the given ID and drop the objects manually. I was able to modify ownership of all tables using ALTER TABLE. However, the associated pg_toast tables still remain with the wrong ownership. In my case, I had to recreate the user, because it had to have rights in a different database within the same postgres installation... Nevertheless, it would be much more convenient, if ALL rights associated with the particular users are dropped when the user is dropped and eventually all orphaned objects have their owner set to the DBA (postgres). It is not too difficult to imagine, that in real-world database installation users would need to be created and dropped. Daniel ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgresql and multithreading
Bruce Momjian wrote: Anuradha Ratnaweera wrote: snip Nope. To keep the `original' code licence as it is and to release the changes GPL? Is the question sane at first place? That would be a pretty big mess, I think. People would add your patch to our BSD code and it would be GPL. It could be done, of course. Don't think so. The patches would be derived code that only exist because of the BSD licensed PostgreSQL base. Being derived code they'd have to be released as BSD and GPL wouldn't enter the picture, regardless if they're released separately as add-on patches or not. :-) Regards and best wishes, Justin Clift -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [JDBC] Out of memory error on huge resultset
To work around this you can use explicit cursors (see the DECLARE CURSOR, FETCH, and MOVE sql commands for postgres). I'm unable to get this to work using the default distribution JDBC driver. (7.2). Here's a code snippet conn.setAutoCommit(false) ; stmt.execute(BEGIN) ; stmt.execute(DECLARE mysursor CURSOR FOR SELECT icol FROM mtable) ; ResultSet rs = null ; if (stmt.execute(FETCH 1 IN mycursor)) rs = stmt.getResultSet() ; The FETCH statement returns an update count of 1, but no ResultSet. If I try executeQuery, a no rows found exception is thrown. Equivalent code in the C library interface works just fine. I need a workaround, because default ResultSet processing in the JDBC driver (and also the jxDBCon driver) pretty much blow out the memory of the JVM. ---(end of broadcast)--- TIP 3: 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] [JDBC] Out of memory error on huge resultset
This code work for me :
Connection db = DriverManager.getConnection(url,user,passwd);
PreparedStatement st = db.prepareStatement(begin;declare c1 cursor for
select * from a);
st.execute();
st = db.prepareStatement(fetch 100 in c1);
ResultSet rs = st.executeQuery();
//rs.setFetchSize(100);
while (rs.next() ) {
s = rs.getString(1);
System.out.println(s);
}
st = db.prepareStatement(commit);
st.execute();
st.close();
db.close();
regards
Haris Peco
On Wednesday 16 October 2002 01:55 pm, Dave Tenny wrote:
To work
around this you can use explicit cursors (see the DECLARE CURSOR,
FETCH, and MOVE sql commands for postgres).
I'm unable to get this to work using the default distribution JDBC driver.
(7.2). Here's a code snippet
conn.setAutoCommit(false) ;
stmt.execute(BEGIN) ;
stmt.execute(DECLARE mysursor CURSOR FOR SELECT icol FROM mtable) ;
ResultSet rs = null ;
if (stmt.execute(FETCH 1 IN mycursor))
rs = stmt.getResultSet() ;
The FETCH statement returns an update count of 1, but no ResultSet.
If I try executeQuery, a no rows found exception is thrown.
Equivalent code in the C library interface works just fine.
I need a workaround, because default ResultSet processing in the JDBC
driver (and also the jxDBCon driver) pretty much blow out the memory
of the JVM.
---(end of broadcast)---
TIP 3: 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
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] index theory
Hi, I have SQL query: SELECT * FROM ii WHERE i1='a' AND i2='b'; There're indexes on i1 and i2. I know best solution is use one index on both (i1, i2). The EXPLAIN command show that optimalizer wants to use one index: test=# explain SELECT * FROM ii WHERE i1='a' AND i1='b'; QUERY PLAN - Index Scan using i1 on ii (cost=0.00..4.83 rows=1 width=24) Index Cond: ((i1 = 'a'::character varying) AND (i1 = 'b'::character varying)) It's right and I undererstand why not use both indexes. But I talked about it with one Oracle user and he said me Oracle knows use both indexes and results from both index scans are mergeted to final result -- this is maybe used if full access to table (too big rows?) is more expensive than 2x index scan and final merge. Is in PG possible something like this? And within query/table? I know about it in JOIN (and subselect maybe) only, but in the standard WHERE? test=# explain SELECT * FROM ii a JOIN ii b ON a.i1=b.i2; QUERY PLAN -- Merge Join (cost=0.00..171.50 rows=5000 width=48) Merge Cond: (outer.i1 = inner.i2) - Index Scan using i1 on ii a (cost=0.00..52.00 rows=1000 width=24) - Index Scan using i2 on ii b (cost=0.00..52.00 rows=1000 width=24) Thanks, Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Postgresql and multithreading
On Wed, 2002-10-16 at 01:27, Shridhar Daithankar wrote: Well, slow adoption rate is attributed to 'apache 1.3.x is good enough for us' syndrome, as far as I can see from news. Once linux distros start shipping with apache 2.x series *only*, the upgrade cycle will start rolling, I guess. I think that's part of it. I think the other part is that by the time you're getting to huge r/s numbers, typical web site bandwidth is already used up. So, what's the point in adding more breathing room when you don't have the bandwidth to use it anyways. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] index theory
On Wed, 2002-10-16 at 09:19, Karel Zak wrote: Hi, I have SQL query: SELECT * FROM ii WHERE i1='a' AND i2='b'; There're indexes on i1 and i2. I know best solution is use one index on both (i1, i2). The EXPLAIN command show that optimalizer wants to use one index: test=# explain SELECT * FROM ii WHERE i1='a' AND i1='b'; QUERY PLAN - Index Scan using i1 on ii (cost=0.00..4.83 rows=1 width=24) Index Cond: ((i1 = 'a'::character varying) AND (i1 = 'b'::character varying)) I think you typo'd. i1='a' AND i1='b' turns into 'a' = 'b' which certainly isn't true in any alphabets I know of. -- Rod Taylor ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] index theory
On Wed, Oct 16, 2002 at 09:25:37AM -0400, Rod Taylor wrote: On Wed, 2002-10-16 at 09:19, Karel Zak wrote: Hi, I have SQL query: SELECT * FROM ii WHERE i1='a' AND i2='b'; There're indexes on i1 and i2. I know best solution is use one index on both (i1, i2). The EXPLAIN command show that optimalizer wants to use one index: test=# explain SELECT * FROM ii WHERE i1='a' AND i1='b'; QUERY PLAN - Index Scan using i1 on ii (cost=0.00..4.83 rows=1 width=24) Index Cond: ((i1 = 'a'::character varying) AND (i1 = 'b'::character varying)) I think you typo'd. i1='a' AND i1='b' turns into 'a' = 'b' which certainly isn't true in any alphabets I know of. Oh... sorry, right is: test=# explain SELECT * FROM ii WHERE i1='a' AND i2='b'; QUERY PLAN --- Index Scan using i2 on ii (cost=0.00..17.08 rows=1 width=24) Index Cond: (i2 = 'b'::character varying) Filter: (i1 = 'a'::character varying) The query is not important ... it's dummy example only. I think about two indexes on one table for access to table. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 3: 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Bruce Momjian [EMAIL PROTECTED] writes: Yes, the new code has _three_ time() calls, rather than the old code that I think only had two. I was going to mention it but I figured time() was a pretty light system call, sort of like getpid(). I needed the additional time() calls so the computation of remaining time was more accurate, i.e. we are not resetting the timer on a select() EINTR anymore. As long as the time() calls aren't invoked in the default no-timeout case, I doubt that the small additional slowdown matters too much. Still, one could ask why we are expending extra cycles to make the timeout more accurate. Who the heck needs an accurate timeout on connect? Can you really give a use-case where the user won't have picked a number out of the air anyway? regards, tom lane ---(end of broadcast)--- TIP 3: 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] Vacuum improvement
Hannu Krosing [EMAIL PROTECTED] writes: meaning to VACUUM FULL the whole table, but to work in small chunks and relaese all locks and let others access the tables between these ? AFAICS this is impossible for VACUUM FULL. You can't let other accesses in and then resume processing, because that invalidates all the state you have about where to put moved tuples. But the whole point of developing non-FULL vacuuming was to make something that could be run concurrently with other stuff. I fail to see the point of insisting that frequent vacuums be FULL. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Vacuum improvement
On Wed, 2002-10-16 at 02:29, Gavin Sherry wrote: On 16 Oct 2002, Hannu Krosing wrote: On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote: Hi all, I'm thinking that there is an improvement to vacuum which could be made for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's very little an application can do to minimise dead-tuples, particularly if the table is randomly updated. Wouldn't it be beneficial if VACUUM could have a parameter which specified how much of the table is vacuumed. That is, you could specify: VACUUM FULL test 20 precent; What about VACUUM FULL test WORK 5 SLEEP 50; meaning to VACUUM FULL the whole table, but to work in small chunks and relaese all locks and let others access the tables between these ? Great idea. I think this could work as a complement to the idea I had. To answer Tom's question, how would we know what we've vacuumed, we could store the range of tids we've vacuumed in pg_class. Or, we could store the block offset of where we left off vacuuming before and using stats, run for another X% of the heap. Is this possible? Why couldn't you start your % from the first rotten/dead tuple? Just reading through trying to find the first tuple to start counting from wouldn't hold locks would it? That keeps you from having to track stats and ensures that X% of the tuples will be vacuumed. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Postgresql and multithreading
On Wed, 2002-10-16 at 04:34, Justin Clift wrote: Bruce Momjian wrote: Anuradha Ratnaweera wrote: snip Nope. To keep the `original' code licence as it is and to release the changes GPL? Is the question sane at first place? That would be a pretty big mess, I think. People would add your patch to our BSD code and it would be GPL. It could be done, of course. Don't think so. The patches would be derived code that only exist because of the BSD licensed PostgreSQL base. Being derived code they'd have to be released as BSD and GPL wouldn't enter the picture, regardless if they're released separately as add-on patches or not. I'm pretty sure BSD allows you to relicense derived code as you see fit. However, any derived project that was released GPL would have a hell of a time ever getting put back into the main source (short of relicensing). Robert Treat ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] index theory
Karel Zak kirjutas K, 16.10.2002 kell 15:19: Hi, I have SQL query: SELECT * FROM ii WHERE i1='a' AND i2='b'; There're indexes on i1 and i2. I know best solution is use one index on both (i1, i2). The EXPLAIN command show that optimalizer wants to use one index: test=# explain SELECT * FROM ii WHERE i1='a' AND i1='b'; QUERY PLAN - Index Scan using i1 on ii (cost=0.00..4.83 rows=1 width=24) Index Cond: ((i1 = 'a'::character varying) AND (i1 = 'b'::character varying)) It's right and I undererstand why not use both indexes. But I talked about it with one Oracle user and he said me Oracle knows use both indexes and results from both index scans are mergeted to final result -- this is maybe used if full access to table (too big rows?) is more expensive than 2x index scan and final merge. Is in PG possible something like this? There has been some talk about using bitmaps generated from indexes as an intermediate step. -- Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Postgresql and multithreading
On Wed, 2002-10-16 at 16:37, Robert Treat wrote: I'm pretty sure BSD allows you to relicense derived code as you see fit. However, any derived project that was released GPL would have a hell of a time ever getting put back into the main source (short of relicensing). Exactly. This is one of the reasons why BSD license is very much liked by proprietary software vendors (think MSFT), unlike the GPL which doesn't allow someone to change and redistribute their work with restrictive licenses. Cheers, Tycho (BTW: I'm not asking to change the license of Postgresql, I know the - dogmatic - answer to that one. So please don't misunderstand my mail) -- Tycho Fruru [EMAIL PROTECTED] Prediction is extremely difficult. Especially about the future. - Niels Bohr ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Yes, the new code has _three_ time() calls, rather than the old code that I think only had two. I was going to mention it but I figured time() was a pretty light system call, sort of like getpid(). I needed the additional time() calls so the computation of remaining time was more accurate, i.e. we are not resetting the timer on a select() EINTR anymore. As long as the time() calls aren't invoked in the default no-timeout case, I doubt that the small additional slowdown matters too much. Still, one could ask why we are expending extra cycles to make the timeout more accurate. Who the heck needs an accurate timeout on connect? Can you really give a use-case where the user won't have picked a number out of the air anyway? I think we do need to properly compute the timeout on an EINTR of select() because if we don't, a 30 second timeout could become 90 seconds if select() is interrupted. The other time() calls are needed, one above the loop, and one inside the loop. The only thing I can do is to pass in the end time _and_ the duration to pqWaitTimeout and do the time() recomputation only on EINTR. This would compute duration in the loop where I call time() and therefore elminate a time() call in the normal, non-EINTR case. Of course, it makes the code more complicated, and that is why I avoided it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Vacuum improvement
Vacuum full locks the whole table currently. I was thinking if you used a similar to a hard drive defragment that only 2 rows would need to be locked at a time. When you're done vacuum/defragmenting you shorten the file to discard the dead tuples that are located after your useful data. There might be a need to lock the table for a little while at the end but it seems like you could reduce that time greatly. I had one table that is heavily updated and it grew to 760 MB even with regular vacuuming. A vacuum full reduced it to 1.1 MB. I am running 7.2.0 (all my vacuuming is done by superuser). On Wednesday 16 October 2002 09:30 am, (Via wrote: On Wed, 2002-10-16 at 02:29, Gavin Sherry wrote: On 16 Oct 2002, Hannu Krosing wrote: On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote: Hi all, I'm thinking that there is an improvement to vacuum which could be made for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's very little an application can do to minimise dead-tuples, particularly if the table is randomly updated. Wouldn't it be beneficial if VACUUM could have a parameter which specified how much of the table is vacuumed. That is, you could specify: VACUUM FULL test 20 precent; What about VACUUM FULL test WORK 5 SLEEP 50; meaning to VACUUM FULL the whole table, but to work in small chunks and relaese all locks and let others access the tables between these ? Great idea. I think this could work as a complement to the idea I had. To answer Tom's question, how would we know what we've vacuumed, we could store the range of tids we've vacuumed in pg_class. Or, we could store the block offset of where we left off vacuuming before and using stats, run for another X% of the heap. Is this possible? Why couldn't you start your % from the first rotten/dead tuple? Just reading through trying to find the first tuple to start counting from wouldn't hold locks would it? That keeps you from having to track stats and ensures that X% of the tuples will be vacuumed. Greg ---(end of broadcast)--- TIP 3: 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
[HACKERS] COPY FROM recognize \xDD sequence - addition to copy.c idea 4 developers
1. Why i do
this:
I try to migrate a database with
a 200 tables from Sybase SQL Anywhere to PostgreSQL,
but SQL Anywhere escapes special
characters like a HEX values ( like \x0D \x2C . ).
PostgreSQL COPY FROM recognize
only OCT values ( lie \001 ... )
2. How-to it' easy :)))
2.1 - Open
$UrSourceDir/src/backend/commands/copy.c
2.2 - Add #include
ctype.h in te begining
2.3 find
function
static char
*
CopyReadAttribute(FILE *fp, bool *isnull, char *delim, int *newline, char
*null_print)
/**/
/* Add this code before it */
static int
HEXVALUE( int
c )
{
if (isdigit(c))
{
c -= '0';
}
else
{
if (islower(c))
c=
c-'a'+10;
else
c=
c-'A'+10;
}
return(c);
}
2.4 in body of CopyReadAttribute
find this
code and modify it like this
if (c == '\\')
{
c =
CopyGetChar(fp);
if (c ==
EOF)
goto
endOfFile;
switch
(c)
{
/*-- Here is my additional code --*/
case 'x':
case 'X':
{
int val;
CopyDonePeek(fp, c, true /*pick up*/); /* Get x always
*/
c = CopyPeekChar(fp); /* Get next */
if (isxdigit(c))
{
val = HEXVALUE(c);
c = CopyPeekChar(fp);
if (isxdigit(c))
{
val = (val 4)
+ HEXVALUE(c);
CopyDonePeek(fp, c,
true /*pick up*/);
}
else
{
if (c == EOF)
goto
endOfFile;
CopyDonePeek(fp, c,
false /*put back*/);
}
}
else
{
if (c == EOF)
goto
endOfFile;
CopyDonePeek(fp, c, false /*put
back*/);
}
c = val;
}
break;
/*--End of myadditional code --*/
case
'0':
case
'1':
case
'2':
case
'3':
case
'4':
case
'5':
case
'6':
case
'7':
{
int val;
val = OCTVALUE(c);
2.4 he he now make , make install
3. An idea to developers : maybe u include this
addition to COPY in future releases
10x
P.S. Excuse me for my English ( i'm better in C
:)
Re: [HACKERS] Vacuum improvement
But doesn't the solution I offer present a possible work around? The table wouldn't need to be locked (I think) until the first dead tuple were located. After that, you would only keep the locks until you've scanned X% of the table and shrunk as needed. The result, I think, results in incremental vacuuming with shorter duration locks being held. It's not ideal (locks) but may shorten the duration behind help by locks. I'm trying to figure out if the two approaches can't be combined somehow. That is, a percent with maybe even a max lock duration? Greg On Wed, 2002-10-16 at 11:33, David Walker wrote: Vacuum full locks the whole table currently. I was thinking if you used a similar to a hard drive defragment that only 2 rows would need to be locked at a time. When you're done vacuum/defragmenting you shorten the file to discard the dead tuples that are located after your useful data. There might be a need to lock the table for a little while at the end but it seems like you could reduce that time greatly. I had one table that is heavily updated and it grew to 760 MB even with regular vacuuming. A vacuum full reduced it to 1.1 MB. I am running 7.2.0 (all my vacuuming is done by superuser). On Wednesday 16 October 2002 09:30 am, (Via wrote: On Wed, 2002-10-16 at 02:29, Gavin Sherry wrote: On 16 Oct 2002, Hannu Krosing wrote: On Wed, 2002-10-16 at 05:22, Gavin Sherry wrote: Hi all, I'm thinking that there is an improvement to vacuum which could be made for 7.4. VACUUM FULLing large, heavily updated tables is a pain. There's very little an application can do to minimise dead-tuples, particularly if the table is randomly updated. Wouldn't it be beneficial if VACUUM could have a parameter which specified how much of the table is vacuumed. That is, you could specify: VACUUM FULL test 20 precent; What about VACUUM FULL test WORK 5 SLEEP 50; meaning to VACUUM FULL the whole table, but to work in small chunks and relaese all locks and let others access the tables between these ? Great idea. I think this could work as a complement to the idea I had. To answer Tom's question, how would we know what we've vacuumed, we could store the range of tids we've vacuumed in pg_class. Or, we could store the block offset of where we left off vacuuming before and using stats, run for another X% of the heap. Is this possible? Why couldn't you start your % from the first rotten/dead tuple? Just reading through trying to find the first tuple to start counting from wouldn't hold locks would it? That keeps you from having to track stats and ensures that X% of the tuples will be vacuumed. Greg ---(end of broadcast)--- TIP 3: 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 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Vacuum improvement
On Wed, 2002-10-16 at 12:33, David Walker wrote: Vacuum full locks the whole table currently. I was thinking if you used a similar to a hard drive defragment that only 2 rows would need to be locked at a time. When you're done vacuum/defragmenting you shorten the file to discard the dead tuples that are located after your useful data. There might be a need to lock the table for a little while at the end but it seems like you could reduce that time greatly. I had one table that is heavily updated and it grew to 760 MB even with regular vacuuming. A vacuum full reduced it to 1.1 MB. I am running 7.2.0 (all my vacuuming is done by superuser). Not that I'm against the idea, but isn't this just a sign that your just not vacuuming frequently enough? Robert Treat ---(end of broadcast)--- TIP 3: 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] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Still, one could ask why we are expending extra cycles to make the timeout more accurate. Who the heck needs an accurate timeout on connect? Can you really give a use-case where the user won't have picked a number out of the air anyway? I think we do need to properly compute the timeout on an EINTR of select() because if we don't, a 30 second timeout could become 90 seconds if select() is interrupted. The other time() calls are needed, one above the loop, and one inside the loop. AFAICS we need one time() call at the start, and then one inside the select loop. I haven't looked at your recent patches, but you said something about putting two calls in the loop; that seems like overkill. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
I will keep this in case we need it later. I think we worked around
this problem by having timeout == 1 set equal to 2 so we get at least
one second for the connection.
---
Denis A Ustimenko wrote:
On Mon, Oct 14, 2002 at 01:00:07AM -0400, Bruce Momjian wrote:
Denis A Ustimenko wrote:
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
Denis A Ustimenko wrote:
Bruce, why have all precise time calculations been droped out in 1.206?
If there is no
gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I could find) and
hence broke the win32 build of the clients.
GetSystemTimeAsFileTime should help.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getsystemtimeasfiletime.asp
It's not clear to me how we could get this into something we can deal
with like gettimeofday.
I looked at the Apache APR project, and they have a routine that returns
the microseconds since 1970 for Unix:
Here is my version of gettimeofday for win32. It was tested with Watcom C 11.0c. I
think it can be used. I still belive that fine time calculation is the right way.
#includestdio.h
#ifdef _WIN32
#includewinsock.h
#else
#includesys/time.h
#endif
main()
{
struct timeval t;
if (gettimeofday(t,NULL)) {
printf(error\n\r);
} else {
printf(the time is %ld.%ld\n\r, t.tv_sec, t.tv_usec);
}
fflush(stdout);
}
#ifdef _WIN32
int gettimeofday(struct timeval *tp, void *tzp)
{
FILETIME time;
__int64 tmp;
if ( NULL == tp) return -1;
GetSystemTimeAsFileTime(time);
tmp = time.dwHighDateTime;
tmp = 32;
tmp |= time.dwLowDateTime;
tmp /= 10; // it was in 100 nanosecond periods
tp-tv_sec = tmp / 100 - 11644473600L; // Windows Epoch begins at 12:00 AM
01.01.1601
tp-tv_usec = tmp % 100;
return 0;
}
#endif
--
Regards
Denis
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] v7.3 Branched ...
Perhaps one could just create a PostgreSQL Powertools section on techdocs, naming the packages and where to get them. This would eliminate the need to maintain a package that just duplicates other packages... Robert Treat On Wed, 2002-10-16 at 16:00, Justin Clift wrote: Thomas Swan wrote: Justin Clift wrote: snip Ok. Wonder if it's worth someone creating a PostgreSQL Powertools type of package, that includes in one download all of these nifty tools (pg_autotune, oid2name, etc) that would be beneficial to have compiled and already available. Kind of like contrib is (oid2name is already there I know), but so people don't have to go hunting all over GBorg to find the bits that they'd want. That would be wonderful if it included some of the more stable tools / add-ons that have been removed from the main distribution or have existed independent of the main PostgreSQL development. Hi Thomas, Want to get it together? :-) Regards and best wishes, Justin Clift -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] v7.3 Branched ...
On Wed, 2002-10-16 at 16:56, Robert Treat wrote: Perhaps one could just create a PostgreSQL Powertools section on techdocs, naming the packages and where to get them. This would eliminate the need to maintain a package that just duplicates other packages... Let ye-old package managers make a shell package which simply points to the others as dependencies. I'd be willing to do this for FreeBSD (think Sean? would help as well) if someone comes up with the list. On Wed, 2002-10-16 at 16:00, Justin Clift wrote: Thomas Swan wrote: Justin Clift wrote: snip Ok. Wonder if it's worth someone creating a PostgreSQL Powertools type of package, that includes in one download all of these nifty tools (pg_autotune, oid2name, etc) that would be beneficial to have compiled and already available. Kind of like contrib is (oid2name is already there I know), but so people don't have to go hunting all over GBorg to find the bits that they'd want. That would be wonderful if it included some of the more stable tools / add-ons that have been removed from the main distribution or have existed independent of the main PostgreSQL development. Hi Thomas, Want to get it together? :-) Regards and best wishes, Justin Clift -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Rod Taylor ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] v7.3 Branched ...
On Wednesday 16 October 2002 05:05 pm, Rod Taylor wrote: On Wed, 2002-10-16 at 16:56, Robert Treat wrote: Perhaps one could just create a PostgreSQL Powertools section on techdocs, naming the packages and where to get them. This would eliminate the need to maintain a package that just duplicates other packages... Let ye-old package managers make a shell package which simply points to the others as dependencies. I'm going to attempt to do up RPMs of all those :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] droped out precise time calculations in src/interfaces/libpq/fe-connect.c
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Still, one could ask why we are expending extra cycles to make the timeout more accurate. Who the heck needs an accurate timeout on connect? Can you really give a use-case where the user won't have picked a number out of the air anyway? I think we do need to properly compute the timeout on an EINTR of select() because if we don't, a 30 second timeout could become 90 seconds if select() is interrupted. The other time() calls are needed, one above the loop, and one inside the loop. AFAICS we need one time() call at the start, and then one inside the select loop. I haven't looked at your recent patches, but you said something about putting two calls in the loop; that seems like overkill. Yes, one call at the start, and one in the loop. We need another in pqWaitTimeout, but only if we hit EINTR. As the code stands now we do time() unconditionally in pqWaitTimeout too because we only have to pass in the funish time. If we want to pass in both finish and duration (for use as select() timeout param), then we can eliminate the time() call in there for the non-EINTR case. Is it worth the added code complexity? That is what I am not sure about. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] COPY FROM recognize \xDD sequence - addition to copy.c
Right now we assume \XXX is octal. We could support \x as hex because
\x isn't any special backslash character. However, no one has ever
asked for this. Does anyone else think this would be benficial?
---
Igor Georgiev wrote:
1. Why i do this:
I try to migrate a database with a 200 tables from Sybase SQL Anywhere to
PostgreSQL,
but SQL Anywhere escapes special characters like a HEX values ( like \x0D \x2C
. ).
PostgreSQL COPY FROM recognize only OCT values ( lie \001 ... )
2. How-to it' easy :)))
2.1 - Open $UrSourceDir/src/backend/commands/copy.c
2.2 - Add #include ctype.h in te begining
2.3 find function
static char *
CopyReadAttribute(FILE *fp, bool *isnull, char *delim, int *newline, char
*null_print)
/**/
/* Add this code before it */
static int
HEXVALUE( int c )
{
if (isdigit(c))
{
c -= '0';
}
else
{
if (islower(c))
c= c-'a'+10;
else
c= c-'A'+10;
}
return(c);
}
2.4 in body of CopyReadAttribute
find this code and modify it like this
if (c == '\\')
{
c = CopyGetChar(fp);
if (c == EOF)
goto endOfFile;
switch (c)
{
/*-- Here is my additional code --*/
case 'x':
case 'X':
{
int val;
CopyDonePeek(fp, c, true /*pick up*/); /* Get x always */
c = CopyPeekChar(fp); /* Get next */
if (isxdigit(c))
{
val = HEXVALUE(c);
c = CopyPeekChar(fp);
if (isxdigit(c))
{
val = (val 4) + HEXVALUE(c);
CopyDonePeek(fp, c, true /*pick up*/);
}
else
{
if (c == EOF)
goto endOfFile;
CopyDonePeek(fp, c, false /*put back*/);
}
}
else
{
if (c == EOF)
goto endOfFile;
CopyDonePeek(fp, c, false /*put back*/);
}
c = val;
}
break;
/*-- End of my additional code --*/
case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
{
int val;
val = OCTVALUE(c);
2.4 he he now make , make install
3. An idea to developers : maybe u include this addition to COPY in future releases
10x
P.S. Excuse me for my English ( i'm better in C :)
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Postgresql and multithreading
Bruce Momjian wrote: Let me add one more thing on this thread. This is one email in a long list of Oh, gee, you aren't using that wizz-bang new sync/thread/aio/raid/raw feature discussion where someone shows up and wants to know why. Does anyone know how to address these, efficiently? You've brought up good points here. I'm sure that you consider me guilty of this with regard to my aio discussions. So I might offer a few specific suggestions. 1) Someone's taking the time to generate a summary of the current thinking with regard to a particular whiz-bang feature. - I can do this as a first pass for aio, if you think it's a good idea. 2) Including the pros and cons of the feature/implementation and how close the group is to deciding whether something would be worth doing. - I can also do this. 3) A set of criteria that would need to be met or demonstrated before a feature would be considered good enough for inclusion into the main code. If there was a separate section of the document Developer's FAQ that handled this, this would help. 4) A development/feature philosophy section. Maybe three or four paragraphs with one specific example: perhaps multi-threading. 5) I'd also suggest changing some specfics in the FAQ Section 1.2 where there is currently: * The usual process for source additions is: * * Review the TODO list. * Discuss hackers the desirability of the fix/feature. * How should it behave in complex circumstances? Add here that a check should be made to the new section in the FAQ described above. Also, section 1.1 has: * Discussion on the patch typically happens here. If the patch adds a * major feature, it would be a good idea to talk about it first on * the HACKERS list, in order to increase the chances of it being * accepted, as well as toavoid duplication of effort. We should perhaps add here a section describing the phenomenon you describe regarding whiz-bang features. I tried to prepare as best I could before bringing anything forward to HACKERS. In particular, I read the last two years of archives with anything to do with the WAL log and looked at the current code, read the TODOs, read a fair amount of discussions about aio. etc. So I was attempting to comply with my interpretation of the process. Yet, despite these efforts, you no doubt consider me guilty of creating unnecessary work, an outcome neither of us desired. I'm undeterred in my desire to come up with something meaningful and am working on some interesting tests. I do, however, now know that the level of scepticism and the standards of architectural purity are high. I consider this good all around. - Curtis ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
On Mon, 2002-10-14 at 16:14, scott.marlowe wrote: It's on Slashdot, but there's only one post there that mentions the use of Postgresql. On 14 Oct 2002, Robert Treat wrote: Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Anybody have a link where I can find the /. or the Oracle statement? -- Karl ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
Karl DeBisschop wrote: On Mon, 2002-10-14 at 16:14, scott.marlowe wrote: It's on Slashdot, but there's only one post there that mentions the use of Postgresql. On 14 Oct 2002, Robert Treat wrote: Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Anybody have a link where I can find the /. or the Oracle statement? Here's the Oracle statement: http://forum.icann.org/org-eval/gartner-report/msg0.html Hope that helps, Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] Postgres-based system to run .org registry?
The slashdot article: http://slashdot.org/article.pl?sid=02/10/14/1720241mode=nestedtid=95 The isoc page: http://www.isoc.org/dotorg/ the isoc proposal: http://www.isoc.org/dotorg/10-1.shtml the Oracle post: http://forum.icann.org/org-eval/gartner-report/msg0.html Good day. On 16 Oct 2002, Karl DeBisschop wrote: On Mon, 2002-10-14 at 16:14, scott.marlowe wrote: It's on Slashdot, but there's only one post there that mentions the use of Postgresql. On 14 Oct 2002, Robert Treat wrote: Yep, that's them. This is a big win from a PostgreSQL advocacy position, especially since oracle pr made an official statement against the use of PostgreSQL. Has this info hit any of the linux oriented news sites (linux-today, slashdot, etc...) If not someone from the PostgreSQL marketing dept. (wink wink) should come up with a press release. Anybody have a link where I can find the /. or the Oracle statement? -- Karl ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3 Branched ...
On Wed, 2002-10-16 at 16:05, Rod Taylor wrote: On Wed, 2002-10-16 at 16:56, Robert Treat wrote: Perhaps one could just create a PostgreSQL Powertools section on techdocs, naming the packages and where to get them. This would eliminate the need to maintain a package that just duplicates other packages... Let ye-old package managers make a shell package which simply points to the others as dependencies. Sort of like a meta-port? I'd be willing to do this for FreeBSD (think Sean? would help as well) if someone comes up with the list. That would be useful, and port(s) for the rest of contrib as well (like contrib/tsearch). :-) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Postgresql and multithreading
On Wed, 2002-10-16 at 23:08, Curtis Faith wrote: Bruce Momjian wrote: I tried to prepare as best I could before bringing anything forward to HACKERS. In particular, I read the last two years of archives with anything to do with the WAL log and looked at the current code, read the TODOs, read a fair amount of discussions about aio. etc. So I was attempting to comply with my interpretation of the process. Yet, despite these efforts, you no doubt consider me guilty of creating unnecessary work, an outcome neither of us desired. But that unneccessary work resulted in Tom finding and fixing an unintended behaviour (aka a performance bug) that prevented postgres from ever doing more than 1 commit per disk revolution on non-lieing SCSI disks ;) I'm undeterred in my desire to come up with something meaningful and am working on some interesting tests. I do, however, now know that the level of scepticism and the standards of architectural purity are high. I consider this good all around. I still have big expectations for use of aio, especially considering that at least for free OSes one is not forced to stop at the DB/OS boundary, but are free to go and improve the os side implementation as well if it is needed. But still some empirical tests are probably needed - if we can keep IO occupied for 99% in a meaningful way withou aio, then the time is probably better spent on something else ;) Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] orderRules() now a bad idea?
Tom Lane writes: But alphabetical? According to whose definition of the alphabet? It looks like NAME comparison uses strcmp (actually strncmp). So it'll be numeric byte-code order. There's no particular reason we couldn't make that be strcoll instead, I suppose, except perhaps speed. But how will this work when we have per-column/datum collation order? And what about languages that don't have any useful collation order for their alphabets (far east)? ISTM that a globally viable feature of this sort would have to sort by something numeric. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] COPY syntax
Bruce Momjian writes: According to the syntax diagram in the documenation, I can write COPY table TO STDOUT WITH BINARY OIDS; Shouldn't the binary, being an adjective, be attached to something? Uh, it is attached to WITH? Attached to a noun phrase, like mode or output. Note that all the other things the typically follow WITH in any command are nouns. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] COPY syntax
Peter Eisentraut wrote: Bruce Momjian writes: According to the syntax diagram in the documenation, I can write COPY table TO STDOUT WITH BINARY OIDS; Shouldn't the binary, being an adjective, be attached to something? Uh, it is attached to WITH? Attached to a noun phrase, like mode or output. Note that all the other things the typically follow WITH in any command are nouns. Should we add an optional MODE after BINARY? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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
[HACKERS] PL/Perl and Perl 5.8
As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8. I get the following compile error: gcc -O2 -g -fpic -I. -I/usr/lib/perl/5.8.0/CORE -I../../../src/include -c -o plperl.o plperl.c -MMD In file included from /usr/lib/perl/5.8.0/CORE/op.h:480, from /usr/lib/perl/5.8.0/CORE/perl.h:2209, from plperl.c:61: /usr/lib/perl/5.8.0/CORE/reentr.h:602: field `_crypt_struct' has incomplete type /usr/lib/perl/5.8.0/CORE/reentr.h:747: confused by earlier errors, bailing out make[3]: *** [plperl.o] Error 1 This is running GCC 3.2 and Perl 5.8.0 on Debian unstable. There's a thread about a similar topic on p5p: http:[EMAIL PROTECTED]/msg75480.html The thread suggests a trivial fix: adding -D_GNU_SOURCE to the CFLAGS for the affected files. I checked, and this gets PL/Perl to compile correctly. That doesn't seem like the right fix, though. Does anyone have any comments on how to fix this properly? Regardless of the solution we choose, I think this needs to be fixed before 7.3 is released. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: 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] COPY FROM recognize \xDD sequence - addition to copy.c
Bruce Momjian [EMAIL PROTECTED] writes: Right now we assume \XXX is octal. We could support \x as hex because \x isn't any special backslash character. However, no one has ever asked for this. Does anyone else think this would be benficial? Well, it seems pretty localized and harmless. If it lets us import Sybase dumps, doesn't that boost our plans for world domination? ;-) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway [EMAIL PROTECTED] writes: As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8. Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3. There's a thread about a similar topic on p5p: http:[EMAIL PROTECTED]/msg75480.html This thread makes it sound like it's Perl's problem not ours ... The thread suggests a trivial fix: adding -D_GNU_SOURCE to the CFLAGS for the affected files. I checked, and this gets PL/Perl to compile correctly. That doesn't seem like the right fix, though. In view of opposing comments like http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-03/msg01452.html I think we should stay out of this. It is not our business to get random Perl code to compile on random OS installations, and certainly not our business to interject random symbol definitions that might well break whatever solution the Perl guys themselves decide on. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] orderRules() now a bad idea?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: It looks like NAME comparison uses strcmp (actually strncmp). So it'll be numeric byte-code order. There's no particular reason we couldn't make that be strcoll instead, I suppose, except perhaps speed. But how will this work when we have per-column/datum collation order? And what about languages that don't have any useful collation order for their alphabets (far east)? ISTM that a globally viable feature of this sort would have to sort by something numeric. I'm confused; are you saying that NAME's sort behavior is good as-is? If not, what would you have it do differently? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PL/Perl and Perl 5.8
Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8. Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3. It may also depend on the way Perl is configured. I've attached the output of 'perl -V' on my system (using Debian's default Perl packages). The thread suggests a trivial fix: adding -D_GNU_SOURCE to the CFLAGS for the affected files. I checked, and this gets PL/Perl to compile correctly. That doesn't seem like the right fix, though. In view of opposing comments like http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-03/msg01452.html I think we should stay out of this. Well, I'd read that thread as saying that Apache breaks when compiled with -D_GNU_SOURCE, not claiming that there is something inherently wrong with defining _GNU_SOURCE as a fix for the Perl problem. It is not our business to get random Perl code to compile on random OS installations, and certainly not our business to interject random symbol definitions that might well break whatever solution the Perl guys themselves decide on. Well, I'm not happy with defining _GNU_SOURCE, but I don't agree that just saying it's a Perl problem is a good answer. That may well be the case, but it doesn't change the fact that a lot of people are running 5.8.0, and will probably continue to do so during the 7.3 lifecycle[1]. We work around braindamage on other systems -- strictely speaking, we could say the snprintf() bug with 64-bit Solaris is a Sun libc problem, for example. Perhaps we can include a test for this in configure? (i.e. if --with-perl is specified, try compiling a simple XS file that exhibits the problem; if it fails, try it with -D_GNU_SOURCE). Cheers, Neil [1] Note that I'm assuming that PL/Perl is broken with 5.8.0 on systems other than mine, and another person's on IRC who reported the problem to begin with. Can other people confirm the problem? -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.19, archname=i386-linux-thread-multi uname='linux cyberhq 2.4.19 #1 smp sun aug 4 11:30:45 pdt 2002 i686 unknown unknown gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-f PIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.0 -Darchli b=/usr/lib/perl/5.8.0 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendora rch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.0 -Dsitearch=/usr/local/lib/perl/5.8.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/u sr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -U afs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.0 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=de fine useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -I/usr/lo
