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
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
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
how find backend id for pg_temp_nnn with SPI_language ?
Thank
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
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
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
[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
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
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
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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
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
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
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?
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
28 matches
Mail list logo
