Re: [HACKERS] 7.4.1 release status - Turkish Locale

2004-02-01 Thread Nicolai Tufar
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

2004-02-01 Thread Bruce Momjian
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

2004-02-01 Thread Tom Lane
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)

2004-02-01 Thread alban
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

2004-02-01 Thread Hans-Jürgen Schönig
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?

2004-02-01 Thread David Fetter
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

2004-02-01 Thread ohp
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?

2004-02-01 Thread Tom Lane
[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?

2004-02-01 Thread David Fetter
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?

2004-02-01 Thread Joshua D. Drake






  
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

2004-02-01 Thread Bruce Momjian
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

2004-02-01 Thread Andrew Dunstan
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

2004-02-01 Thread Tom Lane
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

2004-02-01 Thread Tom Lane
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

2004-02-01 Thread Bruce Momjian
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

2004-02-01 Thread Claudio Natoli
 
 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

2004-02-01 Thread Claudio Natoli


 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

2004-02-01 Thread Tom Lane
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

2004-02-01 Thread Claudio Natoli

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?

2004-02-01 Thread Nicolai Tufar
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

2004-02-01 Thread Tom Lane
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

2004-02-01 Thread Claudio Natoli


 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?

2004-02-01 Thread Tom Lane
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)

2004-02-01 Thread alban
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

2004-02-01 Thread Gaetano Mendola
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

2004-02-01 Thread Joe Conway
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

2004-02-01 Thread Christopher Kings-Lynne
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

2004-02-01 Thread Claudio Natoli

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