Re: [HACKERS] 7.4.1 release status - Turkish Locale
Tom Lane [EMAIL PROTECTED] wrote: Nicolai Tufar [EMAIL PROTECTED] writes: A possible compromise is to apply ASCII downcasing (same as in keywords.c) for 7-bit-ASCII characters, and apply tolower() only for character codes above 127. In other words If we go this way why not make a special case only and only for 'I' Character and not all 7-bit ASCII: It seems to me that that's too narrow a definition of the problem. I think we should state our goal as we don't want bizarre locale definitions to interfere with downcasing of the basic ASCII letters. If we put in a special case for 'I' we will fix the known problem with Turkish, but what other strange locales might be out there? And if we don't trust tolower() for 'I', why should we trust it for 'A'-'Z'? To my knowledge no other locale have similar problems. At least nobody complained so far while Turk users are rising their voices for many years now. Let try and put this very special case, together with an extensive explanation in comment and see if someone complains. And by the way, national characters in table, column, index or function names is something that never happens in production databases. As for 'A'-'Z'^, it was pointed to me that SQL99 standard states that identifier names need to be downcasted in locale-dependent manner. Would you like me to create a patch that would touch only src/backend/parser/scan.l, introduce a special case for 'I' and include an explanation in comment? What it comes down to is that by training and experience, I always expect that any bug might be just one example of a whole class of bugs. You have to look for the related cases that might happen in future, not only fix the case that's under your nose. regards, tom lane Regards, Nicolai Tufar ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Tom Lane wrote: What I've suggested before is that the bgwriter process can keep track of all files that it's written to since the last checkpoint, and fsync them during checkpoint (this would likely require giving the checkpoint task to the bgwriter instead of launching a separate process for it, but that doesn't seem unreasonable). Obviously this requires only local storage in the bgwriter process, and hence no contention. That leaves us still needing to account for files that are written directly by a backend process and not by the bgwriter. However, I claim that if the bgwriter is worth the cycles it's expending, cases in which a backend has to write out a page for itself will be infrequent enough that we don't need to optimize them. Therefore it would be enough to have backends immmediately sync any write they have to do. (They might as well use O_SYNC.) Note that backends need not sync writes to temp files or temp tables, only genuine shared tables. If it turns out that it's not quite *that* infrequent, a compromise position would be to keep a small list of files-needing-fsync in shared memory. Backends that have to evict pages from shared buffers add those files to the list; the bgwriter periodically removes entries from the list and fsyncs the files. Only if there is no room in the list does a backend have to fsync for itself. If the list is touched often enough that it becomes a source of contention, then the whole bgwriter concept is completely broken :-( Now this last plan does assume that an fsync applied by process X will write pages that were dirtied by process Y through a different file descriptor for the same file. There's been some concern raised in the past about whether we can assume that. If not, though, the simpler backends-must-sync-their-own-writes plan will still work. I am concerned that the bgwriter will not be able to keep up with the I/O generated by even a single backend restoring a database, let alone a busy system. To me, the write() performed by the bgwriter, because it is I/O, will typically be the bottleneck on any system that is I/O bound (especially as the kernel buffers fill) and will not be able to keep up with active backends now freed from writes. The idea to fallback when the bgwriter can not keep up is to have the backends sync the data, which seems like it would just slow down an I/O-bound system further. I talked to Magnus about this, and we considered various ideas, but could not come up with a clean way of having the backends communicate to the bgwriter about their own non-sync writes. We had the ideas of using shared memory or a socket, but these seemed like choke-points. Here is my new idea. (I will keep throwing out ideas until I hit on a good one.) The bgwriter it going to have to check before every write to determine if the file is already recorded as needing fsync during checkpoint. My idea is to have that checking happen during the bgwriter buffer scan, rather than at write time. if we add a shared memory boolean for each buffer, backends needing to write buffers can writer buffers already recorded as safe to write by the bgwriter scanner. I don't think the bgwriter is going to be able to keep up with I/O bound backends, but I do think it can scan and set those booleans fast enough for the backends to then perform the writes. (We might need a separate bgwriter thread to do this or a separate process.) As I remember, our new queue system has a list of buffers that are most likely to be replaced, so the bgwriter can scan those first and make sure they have their booleans set. There is an issue that these booleans are set without locking, so there might need to be a double-check of them by backends, first before the write, then after just before they replace the buffer. The bgwriter would clear the bits before the checkpoint starts. -- 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] Idea about better configuration options for sort memory
Joe Conway [EMAIL PROTECTED] writes: Tom Lane wrote: BTW, does anyone want to lobby for renaming sort_mem at the same time? Since it's used for sizing hash tables as well as sort workspace, it's rather misnamed. I hesitate to rename it because of the potential for confusion though. People are pretty used to the existing name. Hmmm ... maybe query_work_mem and maintenance_work_mem, or something similar? I'll go with these unless someone has another proposal ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] SPI find backend id (novice)
how find backend id for pg_temp_nnn with SPI_language ? Thank ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Bitmap index
Hello ... I remember that somebody was working on some sort of bitmap index some time ago (maybe 1 year or two). Does anybody know if there is some sort of half-ready code or so around? Does anybody know if there is somebody working on that? Regards, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] ALTER SEQUENCE: Missing feature?
Kind people, The fine folks in #postgresql brought this up, and it seems like, well, a bug. In order to make certain kinds of changes on a SEQUENCE, you have to issue an ALTER TABLE statement. Shouldn't alterations like RENAME TO, OWNER, etc. to a SEQUENCE all (be able to) go through ALTER SEQUENCE? What else might this impact? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 Before you try to play the history card, make sure it's in your hand. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] how can I get read of that
Hi all First, many thanks to all who helped with my crashes probs. Not fixed yet but has been analyzed as a need to upgrade the BIOS. Then as I said before, I have this problem with stats buffer I know have a phantoom query: Script started on Sun Feb 1 20:05:56 2004 ~ 20:05:56: psql Welcome to psql 7.4.1, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit ohp=# SELECT * from pg_stat_activity ; datid | datname | procpid | usesysid | usename | current_query | query_start ---+--+-+--+--+-+- 38920 | sdewitte | 27575 |60004 | sdewitte | IDLE | Sun 01 Feb 20:06:01.867356 2004 MET 38920 | sdewitte | 27577 |60004 | sdewitte | select lieu_cod from lieu_position,perso_position,lieu where ppos_perso_cod = 41980 and ppos_pos_cod = lpos_pos_cod and lpos_lieu_cod = lieu_cod and lieu_refuge = 'O' | Sun 01 Feb 20:06:01.868747 2004 MET 38920 | sdewitte |6518 |60004 | sdewitte | select count(*) from perso_identifie_objet where pio_perso_cod = 53314 and pio_obj_cod = 28204 | Sun 01 Feb 18:30:37.835876 2004 MET 38915 | ohp | 27574 | 101 | ohp | IDLE | Sun 01 Feb 20:06:00.472581 2004 MET (4 rows) ohp=# \q ~ 20:06:04: exit script done on Sun Feb 1 20:06:04 2004 Feb 1 18:31:02 server postgres[1759]: [61-1] LOG: statistics buffer is full Feb 1 18:31:06 server postgres[6658]: [23-1] LOG: recycled transaction log file 000A0014 Feb 1 18:31:40 server postgres[6868]: [23-1] LOG: duration: 5298.605 ms statement: VACUUM ANALYZE public.perso Feb 1 18:31:41 server postgres[6891]: [23-1] LOG: duration: 2350.284 ms statement: update perso set perso_der_connex = now() where perso_cod = 30245 Feb 1 18:31:42 server postgres[6868]: [24-1] LOG: duration: 2438.490 ms statement: VACUUM ANALYZE public.sessions_log Feb 1 18:31:45 server postgres[6888]: [23-1] LOG: recycled transaction log file 000A0015 Feb 1 18:31:45 server postgres[6888]: [24-1] LOG: recycled transaction log file 000A0016 As you can see, there was a stat buffer full at 18:31 and the process 6518 no longer exists but still shows up in pg_stat_activity. How can I get rid of it short of restarting postgresql? Regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ALTER SEQUENCE: Missing feature?
[EMAIL PROTECTED] (David Fetter) writes: The fine folks in #postgresql brought this up, and it seems like, well, a bug. In order to make certain kinds of changes on a SEQUENCE, you have to issue an ALTER TABLE statement. Shouldn't alterations like RENAME TO, OWNER, etc. to a SEQUENCE all (be able to) go through ALTER SEQUENCE? What else might this impact? Sequences are tables in some very real senses. I don't see the value in duplicating code just to allow people to spell TABLE as SEQUENCE in these commands... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ALTER SEQUENCE: Missing feature?
On Sun, Feb 01, 2004 at 02:53:18PM -0500, Tom Lane wrote: [EMAIL PROTECTED] (David Fetter) writes: The fine folks in #postgresql brought this up, and it seems like, well, a bug. In order to make certain kinds of changes on a SEQUENCE, you have to issue an ALTER TABLE statement. Shouldn't alterations like RENAME TO, OWNER, etc. to a SEQUENCE all (be able to) go through ALTER SEQUENCE? What else might this impact? Sequences are tables in some very real senses. I don't see the value in duplicating code just to allow people to spell TABLE as SEQUENCE in these commands... I guess it comes down to a philosophical thing. Should people need to know the PostgreSQL internals like the fact that a SEQUENCE is currently implemented as a TABLE, or should they just be able to do reasonable things like call ALTER SEQUENCE when they alter a sequence? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ALTER SEQUENCE: Missing feature?
Sequences are tables in some very real senses. I don't see the value in duplicating code just to allow people to spell TABLE as SEQUENCE in these commands... I guess it comes down to a philosophical thing. Should people need to know the PostgreSQL internals like the fact that a SEQUENCE is currently implemented as a TABLE, or should they just be able to do reasonable things like call ALTER SEQUENCE when they alter a sequence? I would have to second this. From a user, user space programmer, dba perspective a SEQUENCE is a SEQUENCE not a table... thus operations such as ALTER that effect the SEQUENCE should use ALTER SEQUENCE. Sincerely, Joshua D. Drake Cheers, D -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Idea about better configuration options for sort memory
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Tom Lane wrote: BTW, does anyone want to lobby for renaming sort_mem at the same time? Since it's used for sizing hash tables as well as sort workspace, it's rather misnamed. I hesitate to rename it because of the potential for confusion though. People are pretty used to the existing name. Hmmm ... maybe query_work_mem and maintenance_work_mem, or something similar? I'll go with these unless someone has another proposal ... The only confusion is that you can use multiple query_work_mem per query, but I can't think of a better name. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] fork/exec
Looking at postmaster.c, my head started to spin a little. I think I understood that exec case or not, by the time we get to BackendRun we have already done all the fork/exec action. Have I read this correctly? (This code is getting rather intricate. A Readme file might be nice. Just a thought) cheers andrew ---(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] Idea about better configuration options for sort memory
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Hmmm ... maybe query_work_mem and maintenance_work_mem, or something similar? I'll go with these unless someone has another proposal ... The only confusion is that you can use multiple query_work_mem per query, but I can't think of a better name. True. Maybe just work_mem and maintenance_work_mem? BTW, I am going to look at whether GUC can be persuaded to continue to allow sort_mem as an alternate name, if we rename it. That would alleviate most of the backward-compatibility issues of changing such a well-known parameter name. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] fork/exec
Andrew Dunstan [EMAIL PROTECTED] writes: (This code is getting rather intricate. It needs rewritten. The hacks inserted for ExecBackend have largely destroyed the former structure (such as it was), and the lack of any commentary added with said hacks didn't help. I am thinking of tackling that rewrite once the dust has settled. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Idea about better configuration options for sort memory
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Hmmm ... maybe query_work_mem and maintenance_work_mem, or something similar? I'll go with these unless someone has another proposal ... The only confusion is that you can use multiple query_work_mem per query, but I can't think of a better name. True. Maybe just work_mem and maintenance_work_mem? BTW, I am going to look at whether GUC can be persuaded to continue to allow sort_mem as an alternate name, if we rename it. That would alleviate most of the backward-compatibility issues of changing such a well-known parameter name. Good. It is not like we have a huge namespace limitation in there. I wonder if we could cost it as a list of string pointers, null terminated. -- 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] fork/exec
Looking at postmaster.c, my head started to spin a little. I think I understood that exec case or not, by the time we get to BackendRun we have already done all the fork/exec action. Have I read this correctly? Yes. In the normal case, fork() then BackendRun. In the EXEC_BACKEND case, fork/exec (or CreateProcess), which then invokes BackendRun via SubPostmasterMain. (This code is getting rather intricate. A Readme file might be nice. Just a thought) Which bits in particular? Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] fork/exec
It needs rewritten. The hacks inserted for ExecBackend have largely destroyed the former structure (such as it was), and the lack of any commentary added with said hacks didn't help. I am thinking of tackling that rewrite once the dust has settled. Anything in particular? With your SubPostmaster suggestion, the split of BackendRun (ne: BackendFork) and BackendInit could now be undone (and I had a TODO item to ask the list if such a reversion was desirable, and provide said patch)... but other than that I don't see where any former structure re: backend creation has been destroyed. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(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] fork/exec
Claudio Natoli [EMAIL PROTECTED] writes:
It needs rewritten. The hacks inserted for ExecBackend have largely
destroyed the former structure (such as it was), and the lack of any
commentary added with said hacks didn't help. I am thinking
of tackling that rewrite once the dust has settled.
Anything in particular?
With your SubPostmaster suggestion, the split of BackendRun (ne:
BackendFork) and BackendInit could now be undone (and I had a TODO item to
ask the list if such a reversion was desirable, and provide said patch)...
I had intended to do that, but in general it seems like there's more
jumping around now. Here's an example that annoyed me recently when
I was looking at IsUnderPostmaster uses. At about line 370 of
bootstrap.c:
/* Acquire configuration parameters */
if (IsUnderPostmaster)
{
#ifdef EXEC_BACKEND
read_nondefault_variables();
read_backend_variables(backendID,NULL);
SSDataBaseInit(xlogop);
#endif
}
else
ProcessConfigFile(PGC_POSTMASTER);
What does SSDataBaseInit have to do with acquiring configuration
parameters? (Answer: nothing.) Why is it being called here at all,
and why only in the EXEC_BACKEND case? Sure can't figure that out from
the uncommented code. Is it a good idea to do it? I rather doubt it
--- that routine does on_exit_reset, which would lose any previously
registered exit callbacks, which is something that should only happen
immediately after fork(), not as far down in BootstrapMain as this is
being done.
But Andrew's complaint already had some merit even before this work
started. We probably ought to rear back and contemplate the overall
structure of postmaster.c and postgres.c, and see what we can do to make
it more comprehensible. I don't have any immediate thoughts about what
to do, just a bee in my bonnet that it needs to be done. Any ideas?
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] fork/exec
Tom Lane wrote: What does SSDataBaseInit have to do with acquiring configuration parameters? (Answer: nothing.) Why is it being called here at all, and why only in the EXEC_BACKEND case? Sure can't figure that out from the uncommented code. Is it a good idea to do it? I rather doubt it --- that routine does on_exit_reset, which would lose any previously registered exit callbacks, which is something that should only happen immediately after fork(), not as far down in BootstrapMain as this is being done. That is a remaining wart. Having fixed a similar pattern in the backend creation, I asked whether or not fixing the Bootstrap process creation was overkill, and took no answer to be in the affirmative... But Andrew's complaint already had some merit even before this work started. We probably ought to rear back and contemplate the overall structure of postmaster.c and postgres.c, and see what we can do to make it more comprehensible. I don't have any immediate thoughts about what to do, just a bee in my bonnet that it needs to be done. Any ideas? If you like, I'll quickly provide a reversion of the BackendRun/Init split, and perhaps implement a SubBootstrapMain-ism... but this doesn't really help things overall. Is it at least a better point to start from? Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Q: How ORDER BY is being done inetrnally?
Greetings, We are trying to fix another problem we have with Turkish locale. Order in which tuples are returned by SELECT .. ORDER BY . statement differs from the one returned by UNIX sort utility or what strcoll() function will suggest. It is specific to a locale so you will not likely be able to reproduce it. I understand that with ORDER BY clause, values are compared in case-insensitive manner as well as it should be the case with the values stored in indices. And I suspect that problem is hidden somewhere there. I tried to find where this conversion and comparison is being done in source code but could not, despite all my efforts. I would very much appreciate if someone would point out what functions are being called while sorting data for return for ORDER BY clause. Thanks in advance, Nicolai Tufar ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fork/exec
Claudio Natoli [EMAIL PROTECTED] writes: If you like, I'll quickly provide a reversion of the BackendRun/Init split, and perhaps implement a SubBootstrapMain-ism... but this doesn't really help things overall. Is it at least a better point to start from? I'd say think first and code later. Do we want to reunify those routines, or is there some purpose in having a split? Can't see what offhand, but the whole problem is this code has gotten away from us complexity-wise. We should first think about what the structure ought to be. One thought I had was that there should be a common subroutine to do the stuff that a new postmaster subprocess needs to do immediately at startup. This includes setting IsUnderPostmaster, MyProcPid, on_exit_reset in the fork() case, reloading global variables in the exec() case, and maybe a couple other things I've forgotten. We've allowed that code to get duplicated across several places now. I had been thinking that this was solely an issue for the exec case (and thus that hiding it in a SubPostmasterMain layer would solve the problem), but really there are several critical things that have to happen there in the fork case as well. We could have a PostmasterChildSetup routine that is called in both cases, and behaves slightly differently in each case, but once it returns the overall state of the new subprocess is the same in both cases. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fork/exec
One thought I had was that there should be a common subroutine to do the stuff that a new postmaster subprocess needs to do immediately at startup. This includes setting IsUnderPostmaster, MyProcPid, on_exit_reset in the fork() case, reloading global variables in the exec() case, and maybe a couple other things I've forgotten. We've allowed that code to get duplicated across several places now. Nice. Could perhaps also get it to do the ugly and oft repeated setitimer(ITIMER_PROF, prof_itimer, NULL) and beos_backend_startup() bits, which currently contribute greatly in making the post-fork code unclear. Flip you for it? :-) Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Q: How ORDER BY is being done inetrnally?
Nicolai Tufar [EMAIL PROTECTED] writes: We are trying to fix another problem we have with Turkish locale. Order in which tuples are returned by SELECT .. ORDER BY . statement differs from the one returned by UNIX sort utility or what strcoll() function will suggest. Text sorting depends on strcoll() and nothing but. See varstr_cmp(). regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SPI find backend id (novice)
alban wrote: how find backend id for pg_temp_nnn with SPI_language ? Thank i have found : #include storage/backendid.h and use MyBackendId example appendStringInfo( str , %d, MyBackendId ); ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Idea about better configuration options for sort memory
Tom Lane wrote: With this approach, old GUC names would be recognized in SHOW and SET commands, as well as the other ways you can set a variable by name (postgresql.conf, ALTER USER SET, etc). But only the new names would appear in SHOW ALL or the pg_settings view. Does that seem OK? May be raise a warning if the old GUC is used, can speed the adoption of new GUCs variables. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Idea about better configuration options for sort memory
Tom Lane wrote: With this approach, old GUC names would be recognized in SHOW and SET commands, as well as the other ways you can set a variable by name (postgresql.conf, ALTER USER SET, etc). But only the new names would appear in SHOW ALL or the pg_settings view. Does that seem OK? Seems OK to me, in fact maybe preferred. But I wonder if we should emit a NOTICE when old names are used with SHOW and SET commands? Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Idea about better configuration options for sort memory
Seems OK to me, in fact maybe preferred. But I wonder if we should emit a NOTICE when old names are used with SHOW and SET commands? A WARNING should be issued. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Pre-1970 dates under Win32
Under Win32, localtime returns NULL for dates pre 1970. A number of places in the code fail to check from a NULL return from localtime, with none seemingly more problematic than those calls within DetermineLocalTimeZone, which causes SEGVs in a number of tests (which clearly pass pre 1970 dates to this function). If we want to support pre-1970 dates, which I imagine we do, then this function requires some serious rework under Win32. If we don't, then I'm guessing we can just drop in some error checking for a NULL return from localtime (as I've done on my personal source base), and modify the tests for Win32 accordingly. Comments? Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(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
