Re: [HACKERS] Threads
On 6 Jan 2003 at 6:48, Greg Copeland wrote: 1) Get I/O time used fuitfully AIO may address this without the need for integrated threading. Arguably, from the long thread that last appeared on the topic of AIO, some hold that AIO doesn't even offer anything beyond the current implementation. As such, it's highly doubtful that integrated threading is going to offer anything beyond what a sound AIO implementation can achieve. Either way, a complete aio or threading implementation is not available on major platforms that postgresql runs. Linux definitely does not have one, last I checked. If postgresql is not using aio or threading, we should start using one of them, is what I feel. What do you say? 2) Use multiple CPU better. Multiple processes tend to universally support multiple CPUs better than does threading. On some platforms, the level of threading support is currently only user mode implementations which means no additional CPU use. Furthermore, some platforms where user-mode threads are defacto, they don't even allow for scheduling bias resulting is less work being accomplished within the same time interval (work slice must be divided between n-threads within the process, all of which run on a single CPU). The frame-work I have posted, threading is optional at build and should be a configuration option if it gets integrated. So for the platforms that can not spread threads across multiple CPUs, it can simply be turned off.. Speaking for my self, I probably would of been more excited if the offered framework had addressed several issues. The short list is: o Code needs to be more robust. It shouldn't be calling exit directly as, I believe, it should be allowing for PostgreSQL to clean up some. Correct me as needed. I would of also expected the code of adopted PostgreSQL's semantics and mechanisms as needed (error reporting, etc). I do understand it was an initial attempt to simply get something in front of some eyes and have something to talk about. Just the same, I was expecting something that we could actually pull the trigger with. That could be done. o Code isn't very portable. Looked fairly okay for pthread platforms, however, there is new emphasis on the Win32 platform. I think it would be a mistake to introduce something as significant as threading without addressing Win32 from the get-go. If you search for pthread in thread.c, there are not many instances. Same goes for thread.h. From what I understand windows threading, it would be less than 10 minutes job to #ifdef the pthread related part on either file. It is just that I have not played with windows threading and nor I am inclined to...;-) o I would desire a more highly abstracted/portable interface which allows for different threading and synchronization primitives to be used. Current implementation is tightly coupled to pthreads. Furthermore, on platforms such as Solaris, I would hope it would easily allow for plugging in its native threading primitives which are touted to be much more efficient than pthreads on said platform. Same as above. If there can be two cases separated with #ifdef, there can be more.. But what is important is to have a thread that can be woken up as and when required with any function desired. That is the basic idea. o Code is not commented. I would hope that adding new code for something as important as threading would be commented. Agreed. o Code is fairly trivial and does not address other primitives (semaphores, mutexs, conditions, TSS, etc) portably which would be required for anything but the most trivial of threaded work. This is especially true in such an application where data IS the application. As such, you must reasonably assume that threads need some form of portable serialization primitives, not to mention mechanisms for non-trivial communication. I don't get this. Probably I should post a working example. It is not threads responsibility to make a function thread safe which is changed on the fly. The function has to make sure that it is thread safe. That is altogether different effort.. o Does not address issues such as thread signaling or status reporting. From what I learnt from pthreads on linux, I would not mix threads and signals. One can easily add code in runner function that disables any signals for thread while the thread starts running. This would leave original signal handling mechanism in place. As far as status reporting is concerned, the thread sould be initiated while back-end starts and terminated with backend termination. What is about status reporting? o Pool interface is rather simplistic. Does not currently support concepts such as wake pool, stop pool, pool status, assigning a pool to work, etc. In fact, it's not altogether obvious what the capabilities intent is of the current pool implementation. Could you please elaborate? I am using same interface in c++ for
[HACKERS] Next platform query: Alphaservers under VMS?
Hi guys, Also received a through the Advocacy website asking if anyone has ported PostgreSQL to the AlphaServers under VMS. Anyone know if we run on VMS? Last time I touched VMS (about 10 years ago) it wasn't all that Unix-like. :-) 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] OS/400 support?
Hi guys, Have passed on the info everyone provided about ways of getting PostgreSQL working on the OS/400 on to the requestor. It would be interesting to see if they go with it. Thanks for the assistance... more stuff will keep on coming through of course. :-) Regards and best wishes, Justin Clift Tom Lane wrote: [EMAIL PROTECTED] writes: It was based on the CMU Hydra project, Really!? Small world ... I was part of the Hydra team, more years ago than I like to admit in public. Somehow, I'm not sure that PostgreSQL-on-OS/400 is likely to be more than a curiosity. Probably. But a lot of our ports are just curiosities, at least to them as aren't running that particular OS. My feeling is that Postgres on top of PASE might be reasonable to support; I doubt we'd want to mess with a native port. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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]
Re: [HACKERS] [Npgsql-general] Get function OID and function calling support
-Original Message- From: Kristis Makris [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 03:05 To: Francisco Figueiredo Jr. Cc: [EMAIL PROTECTED] Subject: Re: [Npgsql-general] Get function OID and function calling support Hi Francicso, I could, however, call a function using the command select f1() and select * from f1(), for example but as a normal query instead of funcion call. That's how I've seen function call examples for a long time now. I'm not sure what the intent was with having the FunctionCall message in the Postgres protocol v2... I wonder if Dave knows anything about this, or maybe the pgsql-odbc mailing list guys. Sorry, don't know. Can anyone on pgsql-hackers tell us the purpose of the FunctionCall message? Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thank-you to Cybertec Geschwinde Schonig
-Original Message- From: Lamar Owen [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 06:12 To: Christopher Kings-Lynne; Hackers; [EMAIL PROTECTED] Subject: Re: [HACKERS] Thank-you to Cybertec Geschwinde Schonig On Monday 06 January 2003 21:01, Christopher Kings-Lynne wrote: I just got my Christmas thank-you from Austria! It is by far the coolest letter I have ever received. Have the other contributors got them as well? Ack! I forgot to send a thankyou to them! Thanks for the reminder. Yes, I got one. It made my day (my day needed made that day.). Eeep, me too. Thanks guys. I also thought it was a very nice gesture. Regards, Dave. ---(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] Upgrading rant.
On Fri, 03 Jan 2003 15:37:56 -0500, Tom Lane [EMAIL PROTECTED] wrote:
The system tables are not the problem. [...]
Changes in the on-disk representation of user tables would be harder to
deal with, but they are also much rarer (AFAIR we've only done that
twice: WAL required additions to page and tuple headers, and then there
were Manfred's space-saving changes in 7.3).
So I'm the bad guy? ;-) AFAICS handling the page and tuple format
changes doesn't need much more than what I have hacked together
yesterday afternoon:
#include access/htup.h
typedef struct HeapTupleHeader72Data
{
Oid t_oid; /* OID of this tuple -- 4
bytes */
CommandId t_cmin; /* insert CID stamp -- 4 bytes each */
CommandId t_cmax; /* delete CommandId stamp */
TransactionId t_xmin; /* insert XID stamp -- 4 bytes each */
TransactionId t_xmax; /* delete XID stamp */
ItemPointerData t_ctid; /* current TID of this or newer tuple */
int16 t_natts;/* number of attributes */
uint16 t_infomask; /* various infos */
uint8 t_hoff; /* sizeof() tuple header */
/* ^ - 31 bytes - ^ */
bits8 t_bits[1];
/* bit map of NULLs */
} HeapTupleHeader72Data;
typedef HeapTupleHeader72Data *HeapTupleHeader72;
/*
** Convert a pre-7.3 heap tuple header to 7.3 format.
**
** On entry ht points to a heap tuple header in 7.2 format,
** which will be converted to the new format in place.
** If compact is true, the size of the heap tuple header
** (t_hoff) is reduced, otherwise enough padding bytes are
** inserted to keep the old length.
**
** The return value is the new size.
*/
Size
HeapTupleHeader_To73Format(HeapTupleHeader ht, bool compact)
{
HeapTupleHeaderData newdata;
Oid oid;
HeapTupleHeader72 ht72;
int len;
ht72 = (HeapTupleHeader72) ht;
oid = ht72-t_oid;
MemSet(newdata, 0, sizeof(HeapTupleHeaderData));
/* copy fixed fields */
ItemPointerCopy(ht72-t_ctid, newdata.t_ctid);
newdata.t_natts = ht72-t_natts;
newdata.t_infomask = ht72-t_infomask;
HeapTupleHeaderSetXmin(newdata, ht72-t_xmin);
if (newdata.t_infomask HEAP_XMAX_INVALID) {
HeapTupleHeaderSetCmin(newdata, ht72-t_cmin);
}/*if*/
else {
HeapTupleHeaderSetXmax(newdata, ht72-t_xmax);
}/*else*/
if (newdata.t_infomask HEAP_MOVED) {
HeapTupleHeaderSetXvac(newdata, ht72-t_cmin);
}/*if*/
else {
HeapTupleHeaderSetCmax(newdata, ht72-t_cmax);
}/*else*/
/* move new structure into original position */
len = offsetof(HeapTupleHeaderData, t_bits);
memcpy(ht, newdata, len);
/* copy bitmap (if there is one) */
if (ht-t_infomask HEAP_HASNULL) {
int bitmaplen = BITMAPLEN(ht-t_natts);
int off = offsetof(HeapTupleHeader72Data, t_bits);
char *p = (char *) ht;
int i;
Assert(len off);
for (i = 0; i bitmaplen; ++i) {
p[len + i] = p[off + i];
}/*for*/
len += bitmaplen;
}/*if*/
/* pad rest with 0 */
Assert(len ht-t_hoff);
memset((char *)ht + len, 0, ht-t_hoff - len);
/* change length, if requested */
if (compact) {
if (oid != 0) {
len += sizeof(Oid);
}/*if*/
ht-t_hoff = MAXALIGN(len);
}/*if*/
/* copy oid (if there is one) */
if (oid != 0) {
ht-t_infomask |= HEAP_HASOID;
HeapTupleHeaderSetOid(ht, oid);
}/*if*/
return ht-t_hoff;
}
#include storage/bufpage.h
#include access/htup.h
/*
** Convert a pre 7.3 heap page to 7.3 format,
** or leave the page alone, if it is already in 7.3 format.
**
** The page is converted in place.
**
** We should have exclusive access to the page, either per
** LockBufferForCleanup() or because we a running in a standalone
** tool.
*/
void
HeapPage_To73Format(Page page, bool compact)
{
PageHeader phdr = (PageHeader)page;
int version = PageGetPageLayoutVersion(page);
Size size = PageGetPageSize(page);
int maxoff = PageGetMaxOffsetNumber(page);
int i;
if (version == PG_PAGE_LAYOUT_VERSION) {
/* already converted */
return;
}/*if*/
Assert(version == 0);
for (i = 1; i = maxoff; ++i) {
ItemId itid = PageGetItemId(page, i);
// ??? if (ItemIdIsUsed(itid)) ...
HeapTupleHeader ht = PageGetItem(page, itid);
Size oldsz = ht-t_hoff;
Re: [HACKERS] Upgrading rant.
On Tue, 07 Jan 2003 11:18:15 +0100, I wrote: what I have hacked together yesterday afternoon: [included it twice] Sorry! Servus Manfred ---(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] PostgreSQL libraries - PThread Support, but not use...
Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] writes: We have definatly had requests for improved thread-safeness for libpq and ecpg in the past, so whatever you can do would be a help. We say libpq is thread-safe, but specifically mention the non-threadsafe calls in the libpq documentation, or at least we should. We do: http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html But Lee's point about depending on possibly-unsafe libc routines is a good one. I don't think anyone's gone through the code with an eye to that. Right, so a reasonable angle for me to take is to go through the libpq source looking for potential problem areas and use of known bad functions. I can add autoconf checks for the replacement *_r() functions, and use these in place of the traditional ones where available. If any function is found to be not thread-safe and cannot be made so using standard library calls then it needs to be documented as such both in the source and the aforementioned documentation. This approach avoids any thread library dependencies and documents the current state of play WRT thread safety (i.e it's a good, and needed, basis for any later work). ECPG is a separate issue, and best handled as such (it will need thread calls). I'll post a patch for it at a later date so the changes are available to anyone who wants to play with ECPG and threads. Ta, Lee. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Have people taken a look at pgdiff yet?
On Tue, 7 Jan 2003, Justin Clift wrote: Hi everyone, Just found out that the pgdiff utility (the one for comparing two different PostgreSQL database's) was released and uploaded to SourceForge in November: http://sourceforge.net/projects/pgdiff Have people already looked at this? I started... but had to install and configure AOLServer, which took more time than I had allotted to thie experiment. I never was able to get a diff to run. I think a good pratical and working example is needed for that utility. I'd like to see how it works. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] UTF-8 psql support
Dear all, Does psql support UTF-8 encoding? su postgres psql template1 CREATE DATABASE foo_é WITH encoding = 'Unicode'; does not work. It seems that Schema objects only accept ASCII letters. Do I miss something? Cheers, Jean-Michel POURE ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Error using cursors/fetch and execute
I have a problem...
We're using cursors to be able to fetch X tuples from the server.
If we would take 'em all our app would blow up because of memory
constraints.
What i would like to is something like this:
mag=# create table test (id serial unique primary key, txt text);
mag=# insert into test(txt) values('hoho1');
mag=# prepare berra (integer) as select * from test where id = $1;
mag=# declare berra_c cursor for execute berra(1);
ERROR: parser: parse error at or near execute at character 28
Is there any other way of fetching less than all rows at once, similar
to that of using cursors. I don't use it for any other purpose than
that.
Magnus
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Programmer/Networker [|] Magnus Naeslund
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] UTF-8 encoding question regarding PhpPgAdmin development
Dear all, We are working on PhpPgAdmin UTF-8 support. I would like to be able to view UTF-8, ASCII and Latin1 databases in PhpPgAdmin without changing HTML header encodings. I guess this can be done using: SET CLIENT_ENCODING='Unicode' for all PhpPgAdmin connections. My question are: - Are some database encodings not translatable into UTF-8 using SET CLIENT_ENCODING = 'Unicode'. It used to be the case for Latin1, but it has been fixed now. - Some letters, like the euro sign, do not belong to Latin1. Example: let's say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I input a euro sign, does it get rejected by PostgreSQL? - More generaly, is it safe to convert an Encoding (ex: Latin1 or Chinese multi-byte) into UTF-8 using SET CLIENT_ENCODING? Can all multi-byte encodings be converted into/from UTF-8 safely? Best regards, Jean-Michel ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Error using cursors/fetch and execute
On Tue, Jan 07, 2003 at 02:29:30PM +0100, Magnus Naeslund(f) wrote:
mag=# create table test (id serial unique primary key, txt text);
mag=# insert into test(txt) values('hoho1');
mag=# prepare berra (integer) as select * from test where id = $1;
mag=# declare berra_c cursor for execute berra(1);
ERROR: parser: parse error at or near execute at character 28
Is there any other way of fetching less than all rows at once, similar
to that of using cursors. I don't use it for any other purpose than
that.
Just
begin;
declare berra cursor for select * from test where id = 1;
fetch 100 from berra;
[...]
end;
Jeroen
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Next platform query: Alphaservers under VMS?
Justin Clift [EMAIL PROTECTED] writes: Anyone know if we run on VMS? I'm pretty sure we don't. But there are plenty of Linux and *BSD distros that will run on that hardware. 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] Next platform query: Alphaservers under VMS?
IIRC, they too have a POSIX layer available. Greg On Tue, 2003-01-07 at 02:44, Justin Clift wrote: Hi guys, Also received a through the Advocacy website asking if anyone has ported PostgreSQL to the AlphaServers under VMS. Anyone know if we run on VMS? Last time I touched VMS (about 10 years ago) it wasn't all that Unix-like. :-) Regards and best wishes, Justin Clift -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Fw: [HACKERS] Error using cursors/fetch and execute
I forgot to reply to the list aswell... Magnus - Original Message - From: Magnus Naeslund(f) [EMAIL PROTECTED] To: Jeroen T. Vermeulen [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 3:32 PM Subject: Re: [HACKERS] Error using cursors/fetch and execute Jeroen T. Vermeulen [EMAIL PROTECTED] wrote: begin; declare berra cursor for select * from test where id = 1; fetch 100 from berra; [...] end; Oh, i'm sorry, i'm unclear. I mean: is there a way of doing exactly the above using prepared statements?. We're doing the above currently, and that works ofcourse... Jeroen Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Threads
On Tue, 2003-01-07 at 02:00, Shridhar Daithankar wrote: On 6 Jan 2003 at 6:48, Greg Copeland wrote: 1) Get I/O time used fuitfully AIO may address this without the need for integrated threading. Arguably, from the long thread that last appeared on the topic of AIO, some hold that AIO doesn't even offer anything beyond the current implementation. As such, it's highly doubtful that integrated threading is going to offer anything beyond what a sound AIO implementation can achieve. Either way, a complete aio or threading implementation is not available on major platforms that postgresql runs. Linux definitely does not have one, last I checked. There are two or three significant AIO implementation efforts currently underway for Linux. One such implementation is available from the Red Hat Server Edition (IIRC) and has been available for some time now. I believe Oracle is using it. SGI also has an effort and I forget where the other one comes from. Nonetheless, I believe it's going to be a hard fought battle to get AIO implemented simply because I don't think anyone, yet, can truly argue a case on the gain vs effort. If postgresql is not using aio or threading, we should start using one of them, is what I feel. What do you say? I did originally say that I'd like to see an AIO implementation. Then again, I don't current have a position to stand other than simply saying it *might* perform better. ;) Not exactly a position that's going to win the masses over. was expecting something that we could actually pull the trigger with. That could be done. I'm sure it can, but that's probably the easiest item to address. o Code isn't very portable. Looked fairly okay for pthread platforms, however, there is new emphasis on the Win32 platform. I think it would be a mistake to introduce something as significant as threading without addressing Win32 from the get-go. If you search for pthread in thread.c, there are not many instances. Same goes for thread.h. From what I understand windows threading, it would be less than 10 minutes job to #ifdef the pthread related part on either file. It is just that I have not played with windows threading and nor I am inclined to...;-) Well, the method above is going to create a semi-ugly mess. I've written thread abstraction layers which cover OS/2, NT, and pthreads. Each have subtle distinction. What really needs to be done is the creation of another abstraction layer which your current code would sit on top of. That way, everything contained within is clear and easy to read. The big bonus is that as additional threading implementations need to be added, only the low-level abstraction stuff needs to modified. Done properly, each thread implementation would be it's own module requiring little #if clutter. As you can see, that's a fair amount of work and far from where the code currently is. o I would desire a more highly abstracted/portable interface which allows for different threading and synchronization primitives to be used. Current implementation is tightly coupled to pthreads. Furthermore, on platforms such as Solaris, I would hope it would easily allow for plugging in its native threading primitives which are touted to be much more efficient than pthreads on said platform. Same as above. If there can be two cases separated with #ifdef, there can be more.. But what is important is to have a thread that can be woken up as and when required with any function desired. That is the basic idea. Again, there's a lot of work in creating a well formed abstraction layer for all of the mechanics that are required. Furthermore, different thread implementations have slightly different semantics which further complicates things. Worse, some types of primitives are simply not available with some thread implementations. That means those platforms require it to be written from the primitives that are available on the platform. Yet more work. o Code is fairly trivial and does not address other primitives (semaphores, mutexs, conditions, TSS, etc) portably which would be required for anything but the most trivial of threaded work. This is especially true in such an application where data IS the application. As such, you must reasonably assume that threads need some form of portable serialization primitives, not to mention mechanisms for non-trivial communication. I don't get this. Probably I should post a working example. It is not threads responsibility to make a function thread safe which is changed on the fly. The function has to make sure that it is thread safe. That is altogether different effort.. You're right, it's not the thread's responsibility, however, it is the threading toolkit's. In this case, you're offering to be the toolkit which functions across two platforms, just for starters. Reasonably, you should expect a third to quickly follow.
[HACKERS] contrib/noupdate does not work and never has worked
Forwarded from a response on pgsql-sql: I thought that the idea behind noup was to protect single columns from update. However, when I apply the noup trigger as above, I can't update /any/ column. Is this the intended behaviour? Idly looking at the source code for contrib/noupdate/noup.c, I don't believe that it has ever worked as advertised: it seems to reject any non-null value for the target column, independently of whether the value is the same as before (which is what I'd have thought it should do). Is anyone interested in fixing it? Or should we just remove it? If it's been there since 6.4 and you're the first person to try to use it, as seems to be the case, then I'd have to say that it's a waste of space in the distribution. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [Npgsql-general] Get function OID and function calling support
Dave Page [EMAIL PROTECTED] writes: Sorry, don't know. Can anyone on pgsql-hackers tell us the purpose of the FunctionCall message? It's used to invoke the fast path function call code (src/backend/tcop/fastpath.c). libpq's large-object routines use this, but little else does AFAIK. The current protocol is sufficiently broken (see comments in fastpath.c) that I'd not really encourage people to use it until we can fix it --- hopefully that will happen in 7.4. regards, tom lane PS: what in the world is [EMAIL PROTECTED] ... is that a real mailing list, and if so why? It sounds a bit, um, duplicative. ---(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] Next platform query: Alphaservers under VMS?
Justin Clift wrote: Hi guys, Also received a through the Advocacy website asking if anyone has ported PostgreSQL to the AlphaServers under VMS. Anyone know if we run on VMS? Last time I touched VMS (about 10 years ago) it wasn't all that Unix-like. It used to work under VMS a few years ago, but we no longer have VMS testers, so I doubt it works anymore. -- 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] Threads
Greg Copeland [EMAIL PROTECTED] writes: That's the power of using the process model that is currently in use. Should it do something naughty, we bitch and complain politely, throw our hands in the air and exit. We no longer have to worry about the state and validity of that backend. You missed the point of his post. If one process in your database does something nasty you damn well should worry about the state of and validity of the entire database, not just that one backend. Are you really sure you caught the problem before it screwed up the data in shared memory? On disk? This whole topic is in need of some serious FUD-dispelling and careful analysis. Here's a more calm explanation of the situation on this particular point. Perhaps I'll follow up with something on IO concurrency later. The point in consideration here is really memory isolation. Threads by default have zero isolation between threads. They can all access each other's memory even including their stack. Most of that memory is in fact only needed by a single thread. Processes by default have complete memory isolation. However postgres actually weakens that by doing a lot of work in a shared memory pool. That memory gets exactly the same protection as it would get in a threaded model, which is to say none. So the reality is that if you have a bug most likely you've only corrupted the local data which can be easily cleaned up either way. In the thread model there's also the unlikely but scary risk that you've damaged other threads' memory. And in either case there's the possibility that you've damaged the shared pool which is unrecoverable. In theory minimising the one case of corrupting other threads' local data shouldn't make a big difference to the risk in the case of an assertion failure. I'm not sure in practice if that's true though. Processes probably reduce the temptation to do work in the shared area too. -- greg ---(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] Threads
On Tue, 2003-01-07 at 12:21, Greg Stark wrote: Greg Copeland [EMAIL PROTECTED] writes: That's the power of using the process model that is currently in use. Should it do something naughty, we bitch and complain politely, throw our hands in the air and exit. We no longer have to worry about the state and validity of that backend. You missed the point of his post. If one process in your database does something nasty you damn well should worry about the state of and validity of the entire database, not just that one backend. I can assure you I did not miss the point. No idea why you're continuing to spell it out. In this case, it appears the quotation is being taken out of context or it was originally stated in an improper context. Are you really sure you caught the problem before it screwed up the data in shared memory? On disk? This whole topic is in need of some serious FUD-dispelling and careful analysis. Here's a more calm explanation of the situation on this particular point. Perhaps I'll follow up with something on IO concurrency later. Hmmm. Not sure what needs to be dispelled since I've not seen any FUD. The point in consideration here is really memory isolation. Threads by default have zero isolation between threads. They can all access each other's memory even including their stack. Most of that memory is in fact only needed by a single thread. Again, this has been covered already. Processes by default have complete memory isolation. However postgres actually weakens that by doing a lot of work in a shared memory pool. That memory gets exactly the same protection as it would get in a threaded model, which is to say none. Again, this has all been covered, more or less. You're comments seem to imply that you did not fully read what has been said on the topic thus far or that you misunderstood something that was said. Of course, it's also possible that I may of said something out of it's proper context which may be confusing you. I think it's safe to say I don't have any further comment unless something new is being brought to the table. Should there be something new to cover, I'm happy to talk about it. At this point, however, it appears that it's been beat to death already. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(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] Threads
Greg Stark [EMAIL PROTECTED] writes: You missed the point of his post. If one process in your database does something nasty you damn well should worry about the state of and validity of the entire database, not just that one backend. Right. And in fact we do blow away all the processes when any one of them crashes or panics. Nonetheless, memory isolation between processes is a Good Thing, because it reduces the chances that a process gone wrong will cause damage via other processes before they can be shut down. Here is a simple example of a scenario where that isolation buys us something: suppose that we have a bug that tromps on memory starting at some point X until it falls off the sbrk boundary and dumps core. (There are plenty of ways to make that happen, such as miscalculating the length of a memcpy or memset operation as -1.) Such a bug causes no serious damage in isolation, because the process suffering the failure will be in a tight data-copying or data-zeroing loop until it gets the SIGSEGV exception. It won't do anything bad based on all the data structures it has clobbered during its march to the end of memory. However, put that same bug in a multithreading context, and it becomes entirely possible that some other thread will be dispatched and will try to make use of already-clobbered data structures before the ultimate SIGSEGV exception happens. Now you have the potential for unlimited trouble. In general, isolation buys you some safety anytime there is a delay between the occurrence of a failure and its detection. Processes by default have complete memory isolation. However postgres actually weakens that by doing a lot of work in a shared memory pool. That memory gets exactly the same protection as it would get in a threaded model, which is to say none. Yes. We try to minimize the risk by keeping the shared memory pool relatively small and not doing more than we have to in it. (For example, this was one of the arguments against creating a shared plan cache.) It's also very helpful that in most platforms, shared memory is not address-wise contiguous to normal memory; thus for example a process caught in a memset death march will hit a SIGSEGV before it gets to the shared memory block. It's interesting to note that this can be made into an argument for not making shared_buffers very large: the larger the fraction of your address space that the shared buffers occupy, the larger the chance that a wild store will overwrite something you'd wish it didn't. I can't recall anyone having made that point during our many discussions of appropriate shared_buffer sizing. So the reality is that if you have a bug most likely you've only corrupted the local data which can be easily cleaned up either way. In the thread model there's also the unlikely but scary risk that you've damaged other threads' memory. And in either case there's the possibility that you've damaged the shared pool which is unrecoverable. In a thread model, *most* of the accessible memory space would be shared with other threads, at least potentially. So I think you're wrong to categorize the second case as unlikely. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Bruce Momjian writes: Lee Kindness wrote: Right, so a reasonable angle for me to take is to go through the libpq source looking for potential problem areas and use of known bad functions. I can add autoconf checks for the replacement *_r() functions, and use these in place of the traditional ones where available. I am a little confused by the *_r functions. Are they for all functions? BSD/OS doesn't have them, but all our libc functions are threadsafe except for things like strtok, where they recommend strsep, and gethostbyname, where they would suggest getaddrinfo, I guess. Some functions in the C library (and other common system libraries) are defined in such a way to make their implementation non-reentrant. Normally this is due to return values being supplied in a static buffer which is overwritten by the subsequent call, or the calls relying on static data between calls. A list such functions would include: asctime crypt ctime drand48 ecvt encrypt erand48 fcvt fgetgrent fgetpwent fgetspent getaliasbyname getaliasent getdate getgrent getgrgid getgrnam gethostbyaddr gethostbyname gethostbyname2 gethostent getlogin getnetbyaddr getnetbyname getnetent getnetgrent getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid getservbyname getservbyport getservent getspent getspnam getutent getutid getutline gmtime hcreate hdestroy hsearch initstate jrand48 lcong48 localtime lrand48 mrand48 nrand48 ptsname qecvt qfcvt rand random readdir readdir64 seed48 setkey setstate sgetspent srand48 srandom strerror strtok tmpnam ttyname to one degree or another. The important ones to watch for are: ctime, localtime, asctime, gmtime, readdir, strtok and tmpnam. Now these functions are often augmented by a _r partner which fixes their API to allow their implementations to be reentrant. After a quick grep libpq could be using crypt, gethostbyname, random, strerror, encrypt, getpwuid, rand and strtok. As you rightly note, ins ome cases the correct fix is to use alternative functions and not the _r versions - this avoids lots of ifdefs! L. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [Npgsql-general] Get function OID and function
San someone point me to what exactly is planned for the protocol/networking stuff? Networking/protocols is one of my fortes and I believe that I could actually help here. Regards, Greg On Tue, 2003-01-07 at 09:01, Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: Sorry, don't know. Can anyone on pgsql-hackers tell us the purpose of the FunctionCall message? It's used to invoke the fast path function call code (src/backend/tcop/fastpath.c). libpq's large-object routines use this, but little else does AFAIK. The current protocol is sufficiently broken (see comments in fastpath.c) that I'd not really encourage people to use it until we can fix it --- hopefully that will happen in 7.4. regards, tom lane PS: what in the world is [EMAIL PROTECTED] ... is that a real mailing list, and if so why? It sounds a bit, um, duplicative. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] IPv6 patch
You mean ship with only IPv4 enabled, but not IPv6. (Of course, both are enabled in the binary.) But then what does -i do? We currently tell people to use -i. Do we need another postgresql.conf option that says, If tcpip_socket is enabled, enable IPv6 too? But that doesn't work if you want _only_ IPv6. The big problem is it doesn't mix with tcpip_socket and -i very well. I am not saying I have a better idea, I am just looking for something clearer. Perhaps we need a separate flag/postgresql.conf option for IPv6 so they can be controlled separately. Have we figured out how to listen on IPv6 only? --- Nigel Kukard wrote: IPV4 only should be shipped by default, but disabled as it is at present. On Tue, 7 Jan 2003, Bruce Momjian wrote: OK, what do we ship as a default? --- Nigel Kukard wrote: Sorry i'm not subscribed to hackers, guess i must get soon! Anyway what i think should happen is follows, if in the configuration file we specify that it must bind to both ie. tcpip_socket = true, the server should check if first its compiled to support ipv6 (or skip this if we use #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it must try to bind to both. Ok thats the first case, the second case is if we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 and if there is no ipv4 support on the box it should fail, not fallback. And finally the third case, if we specify tcpip_socket = 6, we should again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we cannot bind to the specific interface we should fail. Thats my opinion ;) -Nigel On 6 Jan 2003, Robert Treat wrote: On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: The issue is that right now, there isn't any special IPv6 enabling, except for lines in pg_hba.conf. I think it is fine to add some enabling, but we then have an additional user interface issue. One idea I had was to change tcpip_socket from true/false to true/false/4/6 so you can specify if you want none(false)/4/6/both(true). The original patch author wants this functionality too, so there clearly is a need for this. This doesn't play nice with the -i flag, however. Would there a downside to specifying both (enabling ipv6) on a machine that doesn't support it? If not I'd suggest making -i equivalent to tcp_ip_socket = true. I don't think it's too much to ask people to use the preferred method to obtain maximum functionality. Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, but when run, opening an IPV6 server fails and I fall back to IPv4 --- just throwing that out as a data point. What would be our default as shipped? If there is no downside to allowing both, probably both. If there is a downside then ipv4, since it much more likely to be the default on OS's for the next release or two. Robert Treat -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd [EMAIL PROTECTED] www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036 Hoheisen Park Bellville, Cape Town National Internet Service Provider The best language to use is the language that was designed for what you want to use it for - 1997 = Disclaimer -- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may be personal to the sender and is not that of Lando Technologies Africa or any of it's subsideries, associated companies or principals and is therefore not endorsed by any of the Lando groups of companies. Due to e-maill communication being insecure, Lando groups of companies do not guarantee confidentiality, security, accuracy or performance of the e-mail. Any liability for viruses is excluded to the fullest extent. -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd [EMAIL PROTECTED] www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036
Re: [HACKERS] IPv6 patch
Another idea is to have the -i take an optional argument. Something where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only v6. I am guessing that most people will want to bind to both when they just specify -i, which is what is usually suggested when they want to get the box up and running. If they want do something fancy, like only bind to v6, then they will read the docs and see that they can do that with something like -i6. -rocco On Tue, 7 Jan 2003, Bruce Momjian wrote: You mean ship with only IPv4 enabled, but not IPv6. (Of course, both are enabled in the binary.) But then what does -i do? We currently tell people to use -i. Do we need another postgresql.conf option that says, If tcpip_socket is enabled, enable IPv6 too? But that doesn't work if you want _only_ IPv6. The big problem is it doesn't mix with tcpip_socket and -i very well. I am not saying I have a better idea, I am just looking for something clearer. Perhaps we need a separate flag/postgresql.conf option for IPv6 so they can be controlled separately. Have we figured out how to listen on IPv6 only? --- Nigel Kukard wrote: IPV4 only should be shipped by default, but disabled as it is at present. On Tue, 7 Jan 2003, Bruce Momjian wrote: OK, what do we ship as a default? --- Nigel Kukard wrote: Sorry i'm not subscribed to hackers, guess i must get soon! Anyway what i think should happen is follows, if in the configuration file we specify that it must bind to both ie. tcpip_socket = true, the server should check if first its compiled to support ipv6 (or skip this if we use #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it must try to bind to both. Ok thats the first case, the second case is if we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 and if there is no ipv4 support on the box it should fail, not fallback. And finally the third case, if we specify tcpip_socket = 6, we should again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we cannot bind to the specific interface we should fail. Thats my opinion ;) -Nigel On 6 Jan 2003, Robert Treat wrote: On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: The issue is that right now, there isn't any special IPv6 enabling, except for lines in pg_hba.conf. I think it is fine to add some enabling, but we then have an additional user interface issue. One idea I had was to change tcpip_socket from true/false to true/false/4/6 so you can specify if you want none(false)/4/6/both(true). The original patch author wants this functionality too, so there clearly is a need for this. This doesn't play nice with the -i flag, however. Would there a downside to specifying both (enabling ipv6) on a machine that doesn't support it? If not I'd suggest making -i equivalent to tcp_ip_socket = true. I don't think it's too much to ask people to use the preferred method to obtain maximum functionality. Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, but when run, opening an IPV6 server fails and I fall back to IPv4 --- just throwing that out as a data point. What would be our default as shipped? If there is no downside to allowing both, probably both. If there is a downside then ipv4, since it much more likely to be the default on OS's for the next release or two. Robert Treat -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd [EMAIL PROTECTED] www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036 Hoheisen Park Bellville, Cape Town National Internet Service Provider The best language to use is the language that was designed for what you want to use it for - 1997 = Disclaimer -- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may
Re: [HACKERS] IPv6 patch
Rocco Altier [EMAIL PROTECTED] writes: Another idea is to have the -i take an optional argument. Something where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only v6. I don't see why we need any such thing. The current behavior of the postmaster (assuming -i or tcpip_socket is set) is: 1. By default: bind to all IPs on the machine. 2. If virtual_host is set: bind only to that one IP. It seems to me that in a machine with both v4 and v6 IP addresses, the natural extension is that the default behavior is to bind to all of them, or if virtual_host is set then bind to only that one, be it v4 or v6. (Does the existing patch work with virtual_host identifying a v6 IP? If not, that's certainly a bug.) No one has offered any scenario in which it's important to bind to only v4 or only v6 addresses when both are present. In the absence of a compelling argument why that would be useful, I do not see why we're worrying. My own thought is that if I wanted to constrain PG to bind to a subset of a machine's addresses, the extension I'd want is to allow virtual_host to contain a list of names or IP addresses --- of either version. Basing it on v4 versus v6 has no payback that I can see. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
--On Tuesday, January 07, 2003 11:51:44 -0500 Tom Lane [EMAIL PROTECTED] wrote: Rocco Altier [EMAIL PROTECTED] writes: Another idea is to have the -i take an optional argument. Something where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only v6. I don't see why we need any such thing. The current behavior of the postmaster (assuming -i or tcpip_socket is set) is: 1. By default: bind to all IPs on the machine. 2. If virtual_host is set: bind only to that one IP. It seems to me that in a machine with both v4 and v6 IP addresses, the natural extension is that the default behavior is to bind to all of them, or if virtual_host is set then bind to only that one, be it v4 or v6. (Does the existing patch work with virtual_host identifying a v6 IP? If not, that's certainly a bug.) No one has offered any scenario in which it's important to bind to only v4 or only v6 addresses when both are present. In the absence of a compelling argument why that would be useful, I do not see why we're worrying. My own thought is that if I wanted to constrain PG to bind to a subset of a machine's addresses, the extension I'd want is to allow virtual_host to contain a list of names or IP addresses --- of either version. Basing it on v4 versus v6 has no payback that I can see. Please make sure that you can handle the situation of a IPv6 API, but no IPv6 stack. (E.G. UnixWare up to at least 7.1.3). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
Larry Rosenman [EMAIL PROTECTED] writes: Please make sure that you can handle the situation of a IPv6 API, but no IPv6 stack. (E.G. UnixWare up to at least 7.1.3). Certainly. But that is just an autoconfiguration problem. If a v6 IP address is available, we should bind to it. 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] IPv6 patch
Tom Lane wrote: Rocco Altier [EMAIL PROTECTED] writes: Another idea is to have the -i take an optional argument. Something where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only v6. I don't see why we need any such thing. The current behavior of the postmaster (assuming -i or tcpip_socket is set) is: 1. By default: bind to all IPs on the machine. 2. If virtual_host is set: bind only to that one IP. It seems to me that in a machine with both v4 and v6 IP addresses, the natural extension is that the default behavior is to bind to all of them, or if virtual_host is set then bind to only that one, be it v4 or v6. (Does the existing patch work with virtual_host identifying a v6 IP? If not, that's certainly a bug.) No one has offered any scenario in which it's important to bind to only v4 or only v6 addresses when both are present. In the absence of a compelling argument why that would be useful, I do not see why we're worrying. My own thought is that if I wanted to constrain PG to bind to a subset of a machine's addresses, the extension I'd want is to allow virtual_host to contain a list of names or IP addresses --- of either version. Basing it on v4 versus v6 has no payback that I can see. The issue was that folks didn't like silent fallback to just IPv4 if the code supported IPv6 but it didn't bind to IPv6 for some reason, e.g. kernel doesn't have IPv6 enabled. Right now it puts a message in the server logs, but others wanted some specific way to enable IPv6 and fail if it didn't work. They want something that says I want IPv6 and I don't want to start if it doesn't start. Right now if we do -i, and tcpip doesn't start, be bomb out. They want that for IPv6, and the tricky part is we can't enable that by default because many systems have the API but no kernel support. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
Larry Rosenman wrote: No one has offered any scenario in which it's important to bind to only v4 or only v6 addresses when both are present. In the absence of a compelling argument why that would be useful, I do not see why we're worrying. My own thought is that if I wanted to constrain PG to bind to a subset of a machine's addresses, the extension I'd want is to allow virtual_host to contain a list of names or IP addresses --- of either version. Basing it on v4 versus v6 has no payback that I can see. Please make sure that you can handle the situation of a IPv6 API, but no IPv6 stack. (E.G. UnixWare up to at least 7.1.3). Already done. My BSD/OS is that way in the default kernel configuration too. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
--On Tuesday, January 07, 2003 12:07:05 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: Please make sure that you can handle the situation of a IPv6 API, but no IPv6 stack. (E.G. UnixWare up to at least 7.1.3). Certainly. But that is just an autoconfiguration problem. If a v6 IP address is available, we should bind to it. Agreed, but I wanted to at least make sure the issue was known. The Apache guys had to put a special check in for UnixWare since we die in a different way. I can show you the patch if y'all want. regards, tom lane -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: Please make sure that you can handle the situation of a IPv6 API, but no IPv6 stack. (E.G. UnixWare up to at least 7.1.3). Certainly. But that is just an autoconfiguration problem. If a v6 IP address is available, we should bind to it. We already do. The issue is what way should we give admins to _fail_ if IPv6 doesn't start. Maybe just a postgresql.conf setting, exit_on_ipv6_failure or something like that. It unlinks the param to the -i/tcpip_socket functionality. However, it doesn't give us a way to do IPv4 only if the server supports IPv6 too, or to do IPv6 only. -- 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] IPv6 patch
Bruce Momjian [EMAIL PROTECTED] writes: We already do. The issue is what way should we give admins to _fail_ if IPv6 doesn't start. What is IPv6 doesn't start? Either the machine has IPv6 addresses, or it doesn't. It is not our job to notify the DBA what the addresses on his machine are. 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] IPv6 patch
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The issue was that folks didn't like silent fallback to just IPv4 if the code supported IPv6 but it didn't bind to IPv6 for some reason, e.g. kernel doesn't have IPv6 enabled. Who didn't like it, and what was their rationale? This seems to me to Peter was the first to mention it. His reasoning was that if IPv6 was working, but then stopped working, the admin would never know on startup because of the IPv4 fallback. be equivalent to expecting Postgres to list out every IP address in the world *except* the ones it was able to bind to. That's silly. If the system does not support IPv6, there will be no v6 address available to bind to. It is not going to startle anyone when we do not bind to an IPv6 address on such a machine. Right now it puts a message in the server logs, but others wanted some specific way to enable IPv6 and fail if it didn't work. Pure noise, and a useless feature. Again, that info is for the admin so they have some feedback that we aren't using IPv6, even though IPv6 addresses appear in pg_hba.conf (only because we had the IPv6 API). -- 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] IPv6 patch
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: We already do. The issue is what way should we give admins to _fail_ if IPv6 doesn't start. What is IPv6 doesn't start? Either the machine has IPv6 addresses, or it doesn't. It is not our job to notify the DBA what the addresses on his machine are. You can fight it out with Peter. I have no problem silently falling back to IPv4 if people are happy with that. -- 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] SQL_SIZING view
Joe Conway writes: I found the definition in FIPS 127-2: http://www.itl.nist.gov/fipspubs/fip127-2.htm The relevant section is section 16.6. The table described there does not match the schema of the SQL_SIZING table defined in the SQL standard. I'm also suspicious because the SQL_FEATURES table described nearby does not match the SQL_FEATURES table in the standard in both schema and content. So even though the concept seems to be the same I would rather not follow the definition there. -- 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] [Npgsql-general] Get function OID and function calling support
--- Tom Lane [EMAIL PROTECTED] escreveu: Dave Page [EMAIL PROTECTED] writes: Sorry, don't know. Can anyone on pgsql-hackers tell us the purpose of the FunctionCall message? It's used to invoke the fast path function call code (src/backend/tcop/fastpath.c). libpq's large-object routines use this, but little else does AFAIK. The current protocol is sufficiently broken (see comments in fastpath.c) that I'd not really encourage people to use it until we can fix it --- hopefully that will happen in 7.4. Ok, as Kristis already said about how functions are being commonly called, I will implement it this way: transforming the function call into a select function_name statement. I already have some working code and I will clean it and commit it soon. Thanks all! = Regards, Francisco Figueiredo Jr. ___ Busca Yahoo! O melhor lugar para encontrar tudo o que você procura na Internet http://br.busca.yahoo.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] compiling postgres on windows: major headache
Hi all, How is this path created without the (.profile)? $ echo $PATH /usr/local/bin:/usr/bin:/bin:/cygdrive/c/amtagent:/cygdrive/c/informix/bin:/cygd rive/c/winnt:/cygdrive/c/winnt/system:winnt/system32:/cygdrive/c/Windows:/cygdri ve/c/Windows/command:C:jdk1.2.2/bin How can I add this path (~/cygwin/usr/bin/gcc-3.2.1) to the above path? I downloaded the following: postgresql-7.3.tar cygipc-1.09-2.tar.gz gcc-java-3.2.1.tar.gz Thanks, Al ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
On 7 Jan 2003 at 16:25, mlw wrote: I think banner ads that build on PostgreSQL's message is a good thing. A RedHat ad, maybe IBM, etc. Companies with a related purpose to the PostgreSQL mission will offset some of the cost and help build the cedibility of the site. Hotel ads and sweepstakes are a bad idea, though. I think that those who are objecting to ads on the site should follow the suggestion given by Josh Berkus at http://archives.postgresql.org/pgsql-general/2003-01/msg00191.php In other words, stop providing suggestions as to what can be done. Get off your own ass and do it. In short, put up or shut up. -- Dan Langille : http://www.langille.org/ ---(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] New Portal in Place, DNS switched ...
On Tue, 7 Jan 2003, Dan Langille wrote: On 7 Jan 2003 at 16:25, mlw wrote: I think banner ads that build on PostgreSQL's message is a good thing. A RedHat ad, maybe IBM, etc. Companies with a related purpose to the PostgreSQL mission will offset some of the cost and help build the cedibility of the site. Hotel ads and sweepstakes are a bad idea, though. I think that those who are objecting to ads on the site should follow the suggestion given by Josh Berkus at http://archives.postgresql.org/pgsql-general/2003-01/msg00191.php In other words, stop providing suggestions as to what can be done. Get off your own ass and do it. In short, put up or shut up. If I wanted to support the whole hosting operating myself with no help from hub.org, how many gigabytes of data transfer per month would I be looking at for (1) the main site and (2) a mirror? Jon ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
Larry Rosenman wrote: --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: We already do. The issue is what way should we give admins to _fail_ if IPv6 doesn't start. What is IPv6 doesn't start? Either the machine has IPv6 addresses, or it doesn't. It is not our job to notify the DBA what the addresses on his machine are. In the UnixWare case, you can't even find out if there is an IPv6 address, and the API returns a wierd error, IIRC. I don't think we care about how IPv6 fails in our code --- we just fall back to IPv4. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
--On Tuesday, January 07, 2003 12:24:41 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: We already do. The issue is what way should we give admins to _fail_ if IPv6 doesn't start. What is IPv6 doesn't start? Either the machine has IPv6 addresses, or it doesn't. It is not our job to notify the DBA what the addresses on his machine are. In the UnixWare case, you can't even find out if there is an IPv6 address, and the API returns a wierd error, IIRC. I don't think we care about how IPv6 fails in our code --- we just fall back to IPv4. Ok, just checking. IIRC, apache2 refused to start BECAUSE of the this return prior to Jeff Trawick's change of the check. If someone wants to try it, I can generate an account. (Peter E. already has one). the machine is finally running a released OS again :-). LER -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Have people taken a look at pgdiff yet?
Justin Clift writes: Just found out that the pgdiff utility (the one for comparing two different PostgreSQL database's) was released and uploaded to SourceForge in November: A diff utility with a mandatory GUI frontend through a webserver is positively the most bizarre thing I have ever heard of. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] [GENERAL] Have people taken a look at pgdiff yet?
On Tuesday 07 January 2003 12:40, Peter Eisentraut wrote: Justin Clift writes: Just found out that the pgdiff utility (the one for comparing two different PostgreSQL database's) was released and uploaded to SourceForge in November: A diff utility with a mandatory GUI frontend through a webserver is positively the most bizarre thing I have ever heard of. No, AOLserver is just that good at database connectivity :-) And it makes a great development environment for various db utilities. Although the pgdiff people might should mention the need on their summary page I've heard of more bizarre things, though. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Thank-you to Cybertec Geschwinde
*raised eyebrow* Someone want to scan and post one of these? On Tue, 7 Jan 2003, Dave Page wrote: -Original Message- From: Lamar Owen [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 06:12 To: Christopher Kings-Lynne; Hackers; [EMAIL PROTECTED] Subject: Re: [HACKERS] Thank-you to Cybertec Geschwinde Schonig On Monday 06 January 2003 21:01, Christopher Kings-Lynne wrote: I just got my Christmas thank-you from Austria! It is by far the coolest letter I have ever received. Have the other contributors got them as well? Ack! I forgot to send a thankyou to them! Thanks for the reminder. Yes, I got one. It made my day (my day needed made that day.). Eeep, me too. Thanks guys. I also thought it was a very nice gesture. Regards, Dave. ---(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
Re: [HACKERS] Read-only transactions
Tom Lane writes: Where are you planning to check this? In general, I'm trying to align it like a (self-imposed) permission check. For the query-like statements I'm looking at ExecCheckRTPerms(). (That also handles EXECUTE and EXPLAIN most easily.) Utility statements have a check in tcop/utility.c, COPY does it in DoCopy() (out of convenience). In any case you don't pay more than a 'if (XactReadOnly ...)' if it's not activated. As such it's not clear to me why vacuum and checkpoint are included in the forbidden list. They don't logically change any data. The same might be said of reindex. You're right. I'll allow that class of statements. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] PostgreSQL site, put up or shut up?
This is a serious inquiry, very serious. People are complaining about ads. What do we need in the form of equipment, bandwidth, etc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL site, put up or shut up?
On Tue, 7 Jan 2003, mlw wrote: This is a serious inquiry, very serious. People are complaining about ads. What do we need in the form of equipment, bandwidth, etc. FTP is just over 800MB, plan for growth. WEB is just over 90MB, can't tell you what to plan for there. On www/ftp.us I don't even notice the bandwidth, it's less than the normal traffic for Pop4 (an ISP) and the streaming audio uses up even more than that. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(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] PostgreSQL site, put up or shut up?
On 7 Jan 2003, Greg Copeland wrote: On Tue, 2003-01-07 at 16:46, Vince Vielhaber wrote: On Tue, 7 Jan 2003, mlw wrote: This is a serious inquiry, very serious. People are complaining about ads. What do we need in the form of equipment, bandwidth, etc. FTP is just over 800MB, plan for growth. WEB is just over 90MB, can't tell you what to plan for there. On www/ftp.us I don't even notice the bandwidth, it's less than the normal traffic for Pop4 (an ISP) and the streaming audio uses up even more than that. Vince. I guess I don't understand the problem. The ads are very small and completely innocuous. Why would anyone care? Who's complaining and why? Some folks hate to see ads, some don't. If they were popups or really obnoxious I could see it as a problem, but not them little things. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong?
On Tue, Jan 07, 2003 at 03:10:06PM -0800, Dann Corbit wrote: NOTICE: QUERY PLAN: SetOp Except (cost=202028537.97..202120623.90 rows=1227812 width=24) - Sort (cost=202028537.97..202028537.97 rows=12278124 width=24) - Append (cost=1.00..200225099.24 rows=12278124 width=24) - Subquery Scan *SELECT* 1 (cost=1.00..100112549.62 rows=6139062 width=24) - Seq Scan on CNX_DS_53_SIS_STU_OPT_FEE_TB a (cost=1.00..100112549.62 rows=6139062 width=24) - Subquery Scan *SELECT* 2 (cost=1.00..100112549.62 rows=6139062 width=24) - Seq Scan on CNX_DS2_53_SIS_STU_OPT_FEE_TB b (cost=1.00..100112549.62 rows=6139062 width=24) EXPLAIN Those big round numbers suggest that you haven't run vacuum analyze on all of your tables. Since PostgreSQL uses a cost-based optimizer, you do actually have to give it some idea of what things will cost before it can give you an appropriate plan. Reference for your version: http://www14.us.postgresql.org/users-lounge/docs/7.1/reference/sql-vacuum.html -john ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong?
-Original Message- From: johnn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 3:33 PM To: [EMAIL PROTECTED] Subject: Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong? On Tue, Jan 07, 2003 at 03:10:06PM -0800, Dann Corbit wrote: NOTICE: QUERY PLAN: SetOp Except (cost=202028537.97..202120623.90 rows=1227812 width=24) - Sort (cost=202028537.97..202028537.97 rows=12278124 width=24) - Append (cost=1.00..200225099.24 rows=12278124 width=24) - Subquery Scan *SELECT* 1 (cost=1.00..100112549.62 rows=6139062 width=24) - Seq Scan on CNX_DS_53_SIS_STU_OPT_FEE_TB a (cost=1.00..100112549.62 rows=6139062 width=24) - Subquery Scan *SELECT* 2 (cost=1.00..100112549.62 rows=6139062 width=24) - Seq Scan on CNX_DS2_53_SIS_STU_OPT_FEE_TB b (cost=1.00..100112549.62 rows=6139062 width=24) EXPLAIN Those big round numbers suggest that you haven't run vacuum analyze on all of your tables. Since PostgreSQL uses a cost-based optimizer, you do actually have to give it some idea of what things will cost before it can give you an appropriate plan. Reference for your version: http://www14.us.postgresql.org/users-lounge/docs/7.1/reference /sql-vacuum.html No analyze for 7.1.3. Just ran vacuum a few minutes before the query. No boost at all. Even with SET enable_seqscan = 0 it still does a table scan. ---(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: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong?
Dann Corbit [EMAIL PROTECTED] writes: No analyze for 7.1.3. Just ran vacuum a few minutes before the query. No boost at all. VACUUM or VACUUM ANALYZE? Standalone ANALYZE was not in 7.1 but VACUUM ANALYZE does what you need to do... -Doug ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch
Bruce Momjian writes: Peter was the first to mention it. His reasoning was that if IPv6 was working, but then stopped working, the admin would never know on startup because of the IPv4 fallback. My view was that we should treat unix, ipv4, and ipv6 as independent address families each with their own on/off switch (except that unix doesn't have an off switch). Tom's view is that we should treat ipv4 and ipv6 as effectively one address family. That makes sense, too, and it is probably more with the spirit of IPv6. -- Peter Eisentraut [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] UTF-8 encoding question regarding PhpPgAdmin development
Jean-Michel POURE writes: - Are some database encodings not translatable into UTF-8 using SET CLIENT_ENCODING = 'Unicode'. It used to be the case for Latin1, but it has been fixed now. It should be possible. If not, it's a bug. - Some letters, like the euro sign, do not belong to Latin1. Example: let's say we have a Latin1 database and use SET CLIENT_ENCODING = 'Unicode'. If I input a euro sign, does it get rejected by PostgreSQL? Currently, it gives you a warning and ignores the character. Not sure that is ideal. - More generaly, is it safe to convert an Encoding (ex: Latin1 or Chinese multi-byte) into UTF-8 using SET CLIENT_ENCODING? Can all multi-byte encodings be converted into/from UTF-8 safely? Some points to keep in mind: Some character sets contain characters that are not in Unicode, although you might choose to ignore that fact because it is of relatively minor importance. Round-trip conversion is not safely possible, so if your tool provides a read/edit/write tool then you will have problems. Finally, when you display East Asian characters you will have a font problem because the Chinese, Japanese, and Korean characters are mapped to the same range in Unicode but you are supposed to use country-specific glyphs. In short, I don't think what you are trying to do is easily achievable. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] redo error?
Hi guys, My postgres totally messed up again for some reason (there were like 3 postmasters running, other weirdness). I noticed this as it was starting up again: 2003-01-07 18:01:34 DEBUG: ReadRecord: unexpected pageaddr 16/F2794000 in log file 22, segment 249, offset 7946240 2003-01-07 18:01:34 DEBUG: redo done at 16/F9791664 It also logged that it was killed with signal 9, although I didn't kill it! Is there something weird going on here? Postgres 7.2.3 Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Read-only transactions
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Where are you planning to check this? In general, I'm trying to align it like a (self-imposed) permission check. For the query-like statements I'm looking at ExecCheckRTPerms(). (That also handles EXECUTE and EXPLAIN most easily.) If you put it there then EXPLAIN UPDATE ... will bomb out. EXPLAIN ANALYZE UPDATE *should* bomb out, but it'd be nice not to for the other case. Not sure if it's worth kluging things to make that happen, though. The executor doesn't currently know the difference between EXPLAIN and EXPLAIN ANALYZE. Utility statements have a check in tcop/utility.c, COPY does it in DoCopy() (out of convenience). In any case you don't pay more than a 'if (XactReadOnly ...)' if it's not activated. Yeah, one if-test per statement isn't much overhead. What I'm more worried about is making sure that all the places that need to check it will check it; particularly in the utility-statement area, we shall surely be adding more and more things that need to check it. If it's done in ProcessUtility for utility statements then it's probably fairly hard to miss for new statements. May I suggest that each case branch that does not need to check it include an explicit comment to that effect, eg. case T_VacuumStmt: /* No XactReadOnly check since this logically changes no data */ vacuum((VacuumStmt *) parsetree); break; Then it'll be hard to miss the need to think about this when adding a new statement. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
Peter Eisentraut wrote: Bruce Momjian writes: Peter was the first to mention it. His reasoning was that if IPv6 was working, but then stopped working, the admin would never know on startup because of the IPv4 fallback. My view was that we should treat unix, ipv4, and ipv6 as independent address families each with their own on/off switch (except that unix doesn't have an off switch). Tom's view is that we should treat ipv4 and ipv6 as effectively one address family. That makes sense, too, and it is probably more with the spirit of IPv6. OK, Peter, to keep you and everyone happy, what changes are your proposing to the existing code, if any. The only current behavior is printing an IPv6 failure for IPv6-enabled backend in the server logs. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
Tom Lane wrote: "Marc G. Fournier" [EMAIL PROTECTED] writes: Please understand something here ... a large portion of the banner ads are *not* paid ... they are recognition of the many mirror sites that are supporting the project by reducing the amount of bandwidth that is required on the central server ... While the mirror sites deserve some recognition, I'm not convinced that that should translate to banner ads on the main portal. Could we set things up so that when you actually go to a mirror site, you see some discreet notice about "this mirror sponsored by so-and-so"? And I'm definitely not happy with reading Help Support This Site Post your Ad Here Pay Only for Visitors As Low As $0.10cdn per click-thru Hub.Org on the main site. That's several shades too mercenary for my taste. I think banner ads that build on PostgreSQL's message is a good thing. A RedHat ad, maybe IBM, etc. Companies with a related purpose to the PostgreSQL mission will offset some of the cost and help build the cedibility of the site. Hotel ads and sweepstakes are a bad idea, though.
Re: [HACKERS] Next platform query: Alphaservers under VMS?
Yeah, it's called cygwin. Oh, you probably meant that miserable excuse for a posix layer MS included when they shipped it. :-) On Tue, 7 Jan 2003, Dave Page wrote: So does NT iirc ;-) -Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 15:00 To: Justin Clift Cc: PostgresSQL Hackers Mailing List Subject: Re: [HACKERS] Next platform query: Alphaservers under VMS? IIRC, they too have a POSIX layer available. Greg On Tue, 2003-01-07 at 02:44, Justin Clift wrote: Hi guys, Also received a through the Advocacy website asking if anyone has ported PostgreSQL to the AlphaServers under VMS. Anyone know if we run on VMS? Last time I touched VMS (about 10 years ago) it wasn't all that Unix-like. :-) Regards and best wishes, Justin Clift -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(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] COLUMN MODIFY
Sorry to be commenting so late. We could do that CLUSTER way of making a new heap file, but we rejected that for DROP COLUMN, so I am not sure why we would use that for ALTER COLUMN. Can anyone think of a good reason? Clearly if the new data type is binary compatible and it is just a catalog change, we can do that in place. --- Christopher Kings-Lynne wrote: Hey guys, I was just thinking about altering column type. Now, I'm not actually going to implement it any time soon, but I'm just thinking about it!!! One proposal was to introduce a new pg_attribute column called 'attlognum' so changing a column would involve adding a new column, dropping the old one and nudging the attlognum so that the columns are still select *'d in the same order. That involves catalog changes, etc. My idea is why not do what cluster does? Can we just simply write an entire new relation with the new type, update relfilenode and drop the old relation? ISTM that that would prevent catalog changes and would occupy identical disk space (2 x table size) during the ALTER, but would automatically 'free' itself back down to 1 x table size. Otherwise, the user has to do a vacuum full. Actually, if the type is binary compatible with the old type, all you need to update is the catalog. The existing DROP COLUMN implementation could even be changed to work like that, so long as we just leave the attisdropped column always false. What do you think? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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
Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong?
johnn [EMAIL PROTECTED] writes: On Tue, Jan 07, 2003 at 03:10:06PM -0800, Dann Corbit wrote: - Seq Scan on CNX_DS_53_SIS_STU_OPT_FEE_TB a (cost=1.00..100112549.62 rows=6139062 width=24) Those big round numbers suggest that you haven't run vacuum analyze on all of your tables. No; the 1.00 is a tipoff that he's set enable_seqscan off, but the system is using a seqscan anyway because it cannot find any other plan. SET enable_seqscan = off does not prevent the planner from generating seqscan plans, it just adds 1.00 to the cost estimate. That will generally cause the planner to pick another plan --- if it can find one. In this case it evidently cannot find any indexscan alternative. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Next platform query: Alphaservers under VMS?
Yeah, the MS one - sorry 'bout that :-). I was feeling quite chipper before another day of voip hell... -Original Message- From: scott.marlowe [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 21:28 To: Dave Page Cc: Greg Copeland; Justin Clift; PostgresSQL Hackers Mailing List Subject: Re: [HACKERS] Next platform query: Alphaservers under VMS? Yeah, it's called cygwin. Oh, you probably meant that miserable excuse for a posix layer MS included when they shipped it. :-) On Tue, 7 Jan 2003, Dave Page wrote: So does NT iirc ;-) -Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 15:00 To: Justin Clift Cc: PostgresSQL Hackers Mailing List Subject: Re: [HACKERS] Next platform query: Alphaservers under VMS? IIRC, they too have a POSIX layer available. Greg On Tue, 2003-01-07 at 02:44, Justin Clift wrote: Hi guys, Also received a through the Advocacy website asking if anyone has ported PostgreSQL to the AlphaServers under VMS. Anyone know if we run on VMS? Last time I touched VMS (about 10 years ago) it wasn't all that Unix-like. :-) Regards and best wishes, Justin Clift -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] redo error?
Christopher Kings-Lynne [EMAIL PROTECTED] writes: My postgres totally messed up again for some reason (there were like 3 postmasters running, other weirdness). I noticed this as it was starting up again: 2003-01-07 18:01:34 DEBUG: ReadRecord: unexpected pageaddr 16/F2794000 in log file 22, segment 249, offset 7946240 2003-01-07 18:01:34 DEBUG: redo done at 16/F9791664 This is probably OK --- I believe it just suggests that an XLOG page header is not what was expected, which is an unsurprising case after a crash. The system should recover anyway. (If you were running with fsync off, then more paranoia might be appropriate.) It also logged that it was killed with signal 9, although I didn't kill it! Is there something weird going on here? Is this Linux? The Linux kernel seems to think that killing randomly-chosen processes with SIGKILL is an appropriate response to running out of memory. I cannot offhand think of a more brain-dead behavior in any OS living or dead, but that's what it does. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] redo error?
It also logged that it was killed with signal 9, although I didn't kill it! Is there something weird going on here? Is this Linux? The Linux kernel seems to think that killing randomly-chosen processes with SIGKILL is an appropriate response to running out of memory. I cannot offhand think of a more brain-dead behavior in any OS living or dead, but that's what it does. No, FreeBSD. It does the same thing as Linux. What happened is that the postmaster got confused by lots of kill requests from the kernel I think so I ended up with 3 of them running. But then I killed them all manually, ipcclean'd and restarted postmaster cleanly. Then, a few minutes later I saw that. However, I might be getting mixed up as to the order of events, so it is probably me or the kernel doing it. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] sync()
I noticed sync() is used in PostgreSQL. CHECKPOINT - FlushBufferPool() - smgrsync() - mdsync() - sync() Can someone tell me why we need sync() here? -- Tatsuo Ishii ---(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] UTF-8 encoding question regarding PhpPgAdmin development
Dear Peter, Thank you very much for your answers. It rings a bell. Finally, when you display East Asian characters you will have a font problem because the Chinese, Japanese, and Korean characters are mapped to the same range in Unicode but you are supposed to use country-specific glyphs. Do you mean that glyph hexaX will display differently in UTF-8 and EUC_JP? If it is really the case, we cannot use UTF-8. Round-trip conversion is not safely possible, so if your tool provides a read/edit/write tool then you will have problems. Maybe we could use getdatabaseencoding() to determine the dabase encoding and generate HTML pages with the corresponding headers. Example: Latin1 database - ISOS-8859-1 headers. The problem is that PhpPgAdmin interface needs to be localized in several languages, not related to database encoding. Example: EUC_JP interface and Latin1 databases. Maybe a solution would be to use the ISO 10646 notation for PhpPgAdmin interface localization: #XH;, where H is a hexadecimal number. Cheers, Jean-MIchel POURE ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL and memory usage
Dann Corbit wrote: Message I have a machine with 4 CPU's and 2 gigabytes of physical ram. I would like to get PostgreSQL to use as much memory as possible. I can't seem to get PostgreSQL to use more than 100 megabytes or so. How can I optimize the use of PostgreSQL to get the maximum throughput in a configuration like that? Are there any memory usage/tuning documents I can read? I'm not sure if there is a document, but there are some things you can do. First, size the shared memory pool. I've been told by Tom that too much is actually slower, but making it MUCH bigger than the default does help a lot. shared_buffer=2048 (Maybe larger, experiment) Sort memory, this is useful for large queries that do sorting, it is allocated as needed on a per process basis. If you run large queries that sort, this can speed you up instead of sorting to disk. sort_mem=16384 OK, lastly, do not dispare if PostgreSQL seems not to be using as much memory as is in your system. Don't forget the OS disk cache is important too.
Re: [HACKERS] PostgreSQL site, put up or shut up?
-Original Message- From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 22:47 To: mlw Cc: [EMAIL PROTECTED]; Marc G. Fournier Subject: Re: [HACKERS] PostgreSQL site, put up or shut up? On Tue, 7 Jan 2003, mlw wrote: This is a serious inquiry, very serious. People are complaining about ads. What do we need in the form of equipment, bandwidth, etc. FTP is just over 800MB, plan for growth. WEB is just over 90MB, can't tell you what to plan for there. On www/ftp.us I don't even notice the bandwidth, it's less than the normal traffic for Pop4 (an ISP) and the streaming audio uses up even more than that. Disk is cheap, it's the bandwidth that costs. A cursory look at the new portal (which is on a new machine on it's own) is showing about 1Gb since going live on Saturday/Sunday. Of course, these are not just bits of webspace, they are BSD boxes to which we have complete access. There are all sorts of things being run on them - CVS, docbook, distribution builds, Gborg, PostgreSQL, Majordomo, Horde... Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] psql and readline
Hi, Is there any way of making the 'up' arrow retrieve all of the last multiline query, instead of just the last line? It's really annoying working with large multiline queries at the moment... Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] MOVE LAST: why?
2002-11-12 19:44 momjian * doc/src/sgml/ref/move.sgml, src/backend/commands/portalcmds.c, src/backend/executor/execMain.c, src/backend/parser/gram.y, src/backend/parser/keywords.c, src/backend/tcop/utility.c, src/include/commands/portalcmds.h, src/include/nodes/parsenodes.h: Make MOVE/FETCH 0 actually move/fetch 0. Add MOVE LAST to move to end of cursor. Refresh my memory: what is the point of inventing an additional LAST keyword, when the behavior is exactly the same as MOVE ALL ? 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: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong?
-Original Message- From: Jean-Luc Lachance [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:43 PM To: Tom Lane Cc: Dann Corbit; Nigel J. Andrews; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [GENERAL] [HACKERS] I feel the need for speed. What am I doing wrong? There is a construct that most people forget for that kind of query: select RT_REC_KEY, cnxarraycolumn, CRC from a except select RT_REC_KEY, cnxarraycolumn, CRC from b; simple. I should have mentioned that I am not using the latest version of PostgreSQL. I am using 7.1.3. Perhaps this stuff has been repaired in newer versions. Possibly, there is a reason that people forget to use it (at least on PostgreSQL 7.1.3): connxdatasync= SET enable_seqscan = 0; SET VARIABLE connxdatasync= connxdatasync= SELECT a.RT_REC_KEY, a.cnxarraycolumn, a.CRC FROM connxdatasync- CNX_DS_53_SIS_STU_OPT_FEE_TB a connxdatasync- LEFT OUTER JOIN connxdatasync- CNX_DS2_53_SIS_STU_OPT_FEE_TB b connxdatasync- ON ( a.RT_REC_KEY = b.RT_REC_KEY AND a.cnxarraycolumn = b.cnxarraycolumn) connxdatasync- WHERE b.oid IS NULL ; RT_REC_KEY | cnxarraycolumn | CRC ++- (0 rows) 1:55.12 to complete connxdatasync= connxdatasync= select RT_REC_KEY, cnxarraycolumn, CRC from CNX_DS_53_SIS_STU_OPT_FEE_TB a connxdatasync- except connxdatasync- select RT_REC_KEY, cnxarraycolumn, CRC from CNX_DS2_53_SIS_STU_OPT_FEE_TB b; RT_REC_KEY | cnxarraycolumn | CRC ++- (0 rows) 12:55.25 to complete: More than 6 times slower to complete. connxdatasync= connxdatasync= EXPLAIN connxdatasync- select RT_REC_KEY, cnxarraycolumn, CRC from CNX_DS_53_SIS_STU_OPT_FEE_TB a connxdatasync- except connxdatasync- select RT_REC_KEY, cnxarraycolumn, CRC from CNX_DS2_53_SIS_STU_OPT_FEE_TB b; NOTICE: QUERY PLAN: SetOp Except (cost=202028537.97..202120623.90 rows=1227812 width=24) - Sort (cost=202028537.97..202028537.97 rows=12278124 width=24) - Append (cost=1.00..200225099.24 rows=12278124 width=24) - Subquery Scan *SELECT* 1 (cost=1.00..100112549.62 rows=6139062 width=24) - Seq Scan on CNX_DS_53_SIS_STU_OPT_FEE_TB a (cost=1.00..100112549.62 rows=6139062 width=24) - Subquery Scan *SELECT* 2 (cost=1.00..100112549.62 rows=6139062 width=24) - Seq Scan on CNX_DS2_53_SIS_STU_OPT_FEE_TB b (cost=1.00..100112549.62 rows=6139062 width=24) EXPLAIN connxdatasync= ---(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: [GENERAL] [HACKERS] I feel the need for speed. What am I doing
--On Tuesday, January 07, 2003 15:25:06 -0800 Dann Corbit [EMAIL PROTECTED] wrote: No analyze for 7.1.3. Just ran vacuum a few minutes before the query. No boost at all. Even with SET enable_seqscan = 0 it still does a table scan. did you do VACUUM ANALYZE? If not, the stats weren't updated. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MOVE LAST: why?
Tom Lane wrote: 2002-11-12 19:44 momjian * doc/src/sgml/ref/move.sgml, src/backend/commands/portalcmds.c, src/backend/executor/execMain.c, src/backend/parser/gram.y, src/backend/parser/keywords.c, src/backend/tcop/utility.c, src/include/commands/portalcmds.h, src/include/nodes/parsenodes.h: Make MOVE/FETCH 0 actually move/fetch 0. Add MOVE LAST to move to end of cursor. Refresh my memory: what is the point of inventing an additional LAST keyword, when the behavior is exactly the same as MOVE ALL ? SQL compatibility, per Peter. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MOVE LAST: why?
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Refresh my memory: what is the point of inventing an additional LAST keyword, when the behavior is exactly the same as MOVE ALL ? SQL compatibility, per Peter. Oh, I see. But then really it should be documented as a FETCH keyword, not only a MOVE keyword. Will fix. 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] MOVE LAST: why?
Tom Lane wrote: (B (B Bruce Momjian [EMAIL PROTECTED] writes: (B Tom Lane wrote: (B Refresh my memory: what is the point of inventing an additional LAST (B keyword, when the behavior is exactly the same as MOVE ALL ? (B (B SQL compatibility, per Peter. (B (B Oh, I see. But then really it should be documented as a FETCH keyword, (B not only a MOVE keyword. Will fix. (B (BIIRC *FETCH LAST* doesn't mean *FETCH ALL*. (B (BIn addition *FETCH 0* seems to be changed to mean (B*FETCH RELATIVE 0* currently. Is it reasonable ? (B*FETCH n* never means *FETCH RELATIVE n*. (B (Bregards, (BHiroshi Inoue (Bhttp://w2422.nsk.ne.jp/~inoue/ (B (B---(end of broadcast)--- (BTIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] MOVE LAST: why?
Hiroshi Inoue [EMAIL PROTECTED] writes: IIRC *FETCH LAST* doesn't mean *FETCH ALL*. SQL92 says ii) If the fetch orientation implicitly or explicitly spec- ifies NEXT, specifies ABSOLUTE or RELATIVE with K greater than N, or specifies LAST, then CR is positioned after the ^^ last row. So as far as the ending cursor position is concerned, LAST agrees with ALL. It looks to me like the SQL definition only contemplates returning a single row, but it's less than clear *which* row they mean for LAST. In addition *FETCH 0* seems to be changed to mean *FETCH RELATIVE 0* currently. Is it reasonable ? Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n. 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] MOVE LAST: why?
Tom Lane wrote: (B (B Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n. (B (BIIRC in SQL standard FETCH retrieves rows one by one. (B (Bregards, (BHiroshi Inoue (Bhttp://w2422.nsk.ne.jp/~inoue/ (B (B---(end of broadcast)--- (BTIP 6: Have you searched our list archives? (B (Bhttp://archives.postgresql.org
Re: [HACKERS] MOVE LAST: why?
Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n. IIRC in SQL standard FETCH retrieves rows one by one. Yes, Postgres' idea of FETCH is only weakly related to the spec's idea. But I believe you get similar results if you consider only the row last returned by our FETCH. 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] MOVE LAST: why?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Refresh my memory: what is the point of inventing an additional LAST keyword, when the behavior is exactly the same as MOVE ALL ? SQL compatibility, per Peter. Oh, I see. But then really it should be documented as a FETCH keyword, not only a MOVE keyword. Will fix. Yes. SQL standard doesn't have move, but it has FETCH LAST, so we borrowed it for MOVE. -- 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
Re: [HACKERS] MOVE LAST: why?
Tom Lane wrote: (B (B Hiroshi Inoue [EMAIL PROTECTED] writes: (B Tom Lane wrote: (B Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n. (B (B IIRC in SQL standard FETCH retrieves rows one by one. (B (B Yes, Postgres' idea of FETCH is only weakly related to the spec's idea. (B But I believe you get similar results if you consider only the row last (B returned by our FETCH. (B (BFETCH n is a PostgreSQL's extention to retrieve multiple (Brows by one FETCH not related to FETCH RELATIVE at all. (B (BFETCH LAST should return the last one row. (BFETCH RELATIVE m should return a row after skipping (Bm rows if we follow the SQL standard and so the current (Bimplementation of FETCH RELATIVE is broken. (B (Bregards, (BHiroshi Inoue (Bhttp://w2422.nsk.ne.jp/~inoue/ (B (B---(end of broadcast)--- (BTIP 3: if posting/reading through Usenet, please send an appropriate (Bsubscribe-nomail command to [EMAIL PROTECTED] so that your (Bmessage can get through to the mailing list cleanly
Re: [HACKERS] MOVE LAST: why?
Hiroshi Inoue [EMAIL PROTECTED] writes: FETCH LAST should return the last one row. That's not clear to me. Generally, I would think the cursor should remain positioned on whatever row is returned, but the spec clearly says that the final cursor position after FETCH LAST is *after* the last row. Nor do I see where exactly it says that the last row is the one to return in this case; the spec seems to treat LAST the same as PRIOR, so that the *first* row encountered in the movement direction might be the one to return. Can you disentangle the spec wording for me? FETCH RELATIVE m should return a row after skipping m rows if we follow the SQL standard and so the current implementation of FETCH RELATIVE is broken. No objection to that here. Are you volunteering to make it do that? 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] sync()
Tatsuo Ishii wrote: I noticed sync() is used in PostgreSQL. CHECKPOINT - FlushBufferPool() - smgrsync() - mdsync() - sync() Can someone tell me why we need sync() here? As part of checkpoint, we discard some WAL files. To do that, we must first be sure that all the dirty buffers we have written to the kernel are actually on the disk. That is why the sync() is required. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] sync()
Bruce Momjian [EMAIL PROTECTED] writes: Tatsuo Ishii wrote: Can someone tell me why we need sync() here? As part of checkpoint, we discard some WAL files. To do that, we must first be sure that all the dirty buffers we have written to the kernel are actually on the disk. That is why the sync() is required. What we really need is something better than sync(), viz flush all dirty buffers to disk *and* wait till they're written. But sync() and sleep for awhile is the closest portable approximation. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] sync()
Tatsuo Ishii wrote: I noticed sync() is used in PostgreSQL. CHECKPOINT - FlushBufferPool() - smgrsync() - mdsync() - sync() Can someone tell me why we need sync() here? As part of checkpoint, we discard some WAL files. To do that, we must first be sure that all the dirty buffers we have written to the kernel are actually on the disk. That is why the sync() is required. ?? I thought WAL files are synced by pg_fsync() (if needed). -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sync()
As part of checkpoint, we discard some WAL files. To do that, we must first be sure that all the dirty buffers we have written to the kernel are actually on the disk. That is why the sync() is required. What we really need is something better than sync(), viz flush all dirty buffers to disk *and* wait till they're written. But sync() and sleep for awhile is the closest portable approximation. Are you saying that fsync() might not wait untill the IO completes? -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] sync()
Tatsuo Ishii [EMAIL PROTECTED] writes: Can someone tell me why we need sync() here? ?? I thought WAL files are synced by pg_fsync() (if needed). They are. But to write a checkpoint record --- which implies that the WAL records before it need no longer be replayed --- we have to ensure that all the changes-so-far in the regular database files are written down to disk. That is what we need sync() for. 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] sync()
Tatsuo Ishii [EMAIL PROTECTED] writes: What we really need is something better than sync(), viz flush all dirty buffers to disk *and* wait till they're written. But sync() and sleep for awhile is the closest portable approximation. Are you saying that fsync() might not wait untill the IO completes? No, I said that sync() might not. Read the man pages. HPUX's man page for sync(2) says sync() causes all information in memory that should be on disk to be written out. ... The writing, although scheduled, is not necessarily complete upon return from sync. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sync()
Are you saying that fsync() might not wait untill the IO completes? No, I said that sync() might not. Read the man pages. HPUX's man page for sync(2) says sync() causes all information in memory that should be on disk to be written out. ... The writing, although scheduled, is not necessarily complete upon return from sync. I'm just wondering why we do not use fsync() to flush data/index pages. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] sync()
Tatsuo Ishii [EMAIL PROTECTED] writes: I'm just wondering why we do not use fsync() to flush data/index pages. There isn't any efficient way to do that AFAICS. The process that wants to do the checkpoint hasn't got any way to know just which files need to be sync'd. Even if it did know, it's not clear to me that we can portably assume that process A issuing an fsync on a file descriptor F it's opened for file X will force to disk previous writes issued against the same physical file X by a different process B using a different file descriptor G. sync() is surely overkill, in that it writes out dirty kernel buffers that might have nothing at all to do with Postgres. But I don't see how to do better. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sync()
Tatsuo Ishii [EMAIL PROTECTED] writes: I'm just wondering why we do not use fsync() to flush data/index pages. There isn't any efficient way to do that AFAICS. The process that wants to do the checkpoint hasn't got any way to know just which files need to be sync'd. Even if it did know, it's not clear to me that we can portably assume that process A issuing an fsync on a file descriptor F it's opened for file X will force to disk previous writes issued against the same physical file X by a different process B using a different file descriptor G. sync() is surely overkill, in that it writes out dirty kernel buffers that might have nothing at all to do with Postgres. But I don't see how to do better. Thanks for a good summary. Maybe this is yet another reason to have a separate IO process like Oracle... -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [Npgsql-general] Get function OID and function calling support
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 15:01 To: Dave Page Cc: Kristis Makris; Francisco Figueiredo Jr.; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS] [Npgsql-general] Get function OID and function calling support Dave Page [EMAIL PROTECTED] writes: Sorry, don't know. Can anyone on pgsql-hackers tell us the purpose of the FunctionCall message? It's used to invoke the fast path function call code (src/backend/tcop/fastpath.c). libpq's large-object routines use this, but little else does AFAIK. The current protocol is sufficiently broken (see comments in fastpath.c) that I'd not really encourage people to use it until we can fix it --- hopefully that will happen in 7.4. OK, Thanks. PS: what in the world is [EMAIL PROTECTED] ... is that a real mailing list, and if so why? It sounds a bit, um, duplicative. [EMAIL PROTECTED] is the general discussion list for the Npgsql project on Gborg. It's a .NET data provider for PostgreSQL that works with .NET programs written in MS VC++, C# or VB.NET not to mention Mono. Not to be confused with pgsql-general :-) Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Next platform query: Alphaservers under VMS?
So does NT iirc ;-) -Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 15:00 To: Justin Clift Cc: PostgresSQL Hackers Mailing List Subject: Re: [HACKERS] Next platform query: Alphaservers under VMS? IIRC, they too have a POSIX layer available. Greg On Tue, 2003-01-07 at 02:44, Justin Clift wrote: Hi guys, Also received a through the Advocacy website asking if anyone has ported PostgreSQL to the AlphaServers under VMS. Anyone know if we run on VMS? Last time I touched VMS (about 10 years ago) it wasn't all that Unix-like. :-) Regards and best wishes, Justin Clift -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Lee Kindness wrote: Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] writes: We have definatly had requests for improved thread-safeness for libpq and ecpg in the past, so whatever you can do would be a help. We say libpq is thread-safe, but specifically mention the non-threadsafe calls in the libpq documentation, or at least we should. We do: http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html But Lee's point about depending on possibly-unsafe libc routines is a good one. I don't think anyone's gone through the code with an eye to that. Right, so a reasonable angle for me to take is to go through the libpq source looking for potential problem areas and use of known bad functions. I can add autoconf checks for the replacement *_r() functions, and use these in place of the traditional ones where available. I am a little confused by the *_r functions. Are they for all functions? BSD/OS doesn't have them, but all our libc functions are threadsafe except for things like strtok, where they recommend strsep, and gethostbyname, where they would suggest getaddrinfo, I guess. If any function is found to be not thread-safe and cannot be made so using standard library calls then it needs to be documented as such both in the source and the aforementioned documentation. Ideally we will find we can get them all fixed in some way. This approach avoids any thread library dependencies and documents the current state of play WRT thread safety (i.e it's a good, and needed, basis for any later work). Yes, good idea. ECPG is a separate issue, and best handled as such (it will need thread calls). I'll post a patch for it at a later date so the changes are available to anyone who wants to play with ECPG and threads. Yes, needs to be done too. Someone was complaining about ecpg not being thread safe several months ago. I don't remember the details. -- 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] bug in latest Makefile commit
Yep, got it. Thanks. --- Christopher Kings-Lynne wrote: gmake[2]: Entering directory `/home/chriskl/pgsql-head/src/backend' Makefile:145: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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
