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 t
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?
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
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 rai
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'
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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 parame
Claudio Natoli said:
>
>> 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.
Claudio Natoli <[EMAIL PROTECTED]> writes:
> 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.
Good point.
> Flip you for it? :-)
"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 depend
> 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 m
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 late
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 t
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 doub
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 s
> 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
> 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,
fo
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 onl
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
th
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 mu
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)
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 potentia
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
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
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> 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 SEQUE
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 t
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. Shou
[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
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
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 SEQUE
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
S
how find backend id for pg_temp_nnn with SPI_language ?
Thank
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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.
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
"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 no
"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'
> I still don't much like having a locale-specific wart in the parser
> (and the code you give could not work anyway --- for starters, the
> first argument of setlocale is not a pointer).
Aw, I see, my code broken. I got confused by locale_.._asign()
family
if functions. Sure, first argument
35 matches
Mail list logo
