Volkan YAZICI <[EMAIL PROTECTED]> writes:
> There're lots of places in the code which uses either pg_tolower()
> or just tolower() - without aware of MB characters; or some
> on-their-own implementations of pg_tolower(). (Actually, AFAIK,
> whole MB case conversion is broken in -rHEAD.)
The upper/
Tom Lane wrote:
Leaving aside the question of max_connections, which seems to be the
most controversial, is there any objection to the proposal to increase
the settings tried for shared_buffers (up to 4000) and max_fsm_pages (up
to 20) ? If not, I'll apply a patch for those changes short
Greetings to all,
On Mon, Dec 26, 2005 at 10:04:59AM -0500, Tom Lane wrote:
> I would recommend posting some fairly detailed design discussions
> concerning what you see as the new semantics, API, and catalog
> representation for operators and operator classes. If you haven't
> got buy-in at that
Hi,
There're lots of places in the code which uses either pg_tolower()
or just tolower() - without aware of MB characters; or some
on-their-own implementations of pg_tolower(). (Actually, AFAIK,
whole MB case conversion is broken in -rHEAD.)
For instance, consider backend/utils/adt/{like.c, like_
Hi,
On Mon, 26 Dec 2005, Tom Lane wrote:
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
PostgreSQL source tree had init scripts in contrib/ years before:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist
Aren't those dead versions of what's now in contrib/start-s
There are too many versions of too many platforms to have to keep up
with, IMNSHO. Might be a good pgfoundry project, just as the binary
distros are.
In general yes BUT it seems like a good idea to have:
Linux
FreeBSD
MacOSX
Solaris
As though are the most popular platforms.
Sincerely,
Jos
Devrim GUNDUZ wrote:
Hi,
PostgreSQL source tree had init scripts in contrib/ years before:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist
I suggest to push the init scripts again into contrib/, for people who
don'u use packaged versions and need ini
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> PostgreSQL source tree had init scripts in contrib/ years before:
> http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist
Aren't those dead versions of what's now in contrib/start-scripts/ ?
regards,
Hi,
PostgreSQL source tree had init scripts in contrib/ years before:
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist
I suggest to push the init scripts again into contrib/, for people who
don'u use packaged versions and need init scripts.
We could supply
On 12/26/05, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> (1,1) <* (1,2) = true
> (1,2) <* (2,1) is NULL
> (2,3) <* (1,2) = false
>
> it's usefull for multicriterial optimalisation
This is indeed a sane and useful function which should be adopted by
the SQL standard.. in postgresql this would easily
On Mon, 26 Dec 2005, Bruce Momjian wrote:
Joshua D. Drake wrote:
I have never heard the term Continuous backup. Although I have heard
online backup. The problem is that when I hear the term online backup
I think Hot backup which is what we do with pg_dump.
Yes, that is my problem too.
I wo
Huh? The only "current behavior" with other operators is failure:
you didn't understand me. I know so operator <* isn't supported now.
I prefere SQL spec behave too. But what I wont:
a <* b ~ ai <= bi and one ai < bi => true ; if one ai > bi => NULL; else
false
but this behave is from so
Tom Lane wrote:
I was thinking of a linear factor plus clamps to minimum and maximum
values --- does that make it work any better?
Can you suggest some factor/clamp values? Obviously it would be
reasonable to set the max clamp at the max shared_buffers size we would
test in the next ste
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > I noticed that we are using the term "Online Backup" in our
> > documentation when we are talking about continuous backup and PITR.
> >
> > To me, "online backup" is doing a backup while the system is online
> > (online-backup), and that is accompl
Bruce Momjian wrote:
I noticed that we are using the term "Online Backup" in our
documentation when we are talking about continuous backup and PITR.
To me, "online backup" is doing a backup while the system is online
(online-backup), and that is accomplished by pg_dump. I know a lot of
database
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> In experimenting I needed to set this at 20 for it to bite much. If we
> wanted to fine tune it I'd be inclined to say that we wanted
> 20*connections buffers for the first, say, 50 or 100 connections and 10
> or 16 times for each connection over tha
Tom Lane wrote:
> Bruce Momjian writes:
> > I suggest the following patch to rename our capability "Continuous
> > Backup".
>
> This doesn't seem like an improvement. "Online backup" is the standard
> terminology AFAIK.
But why is it the standard terminology? It doesn't seem logical.
--
Br
Bruce Momjian writes:
> I suggest the following patch to rename our capability "Continuous
> Backup".
This doesn't seem like an improvement. "Online backup" is the standard
terminology AFAIK.
regards, tom lane
---(end of broadcast)---
On Sun, 2005-12-25 at 17:56 -0300, Euler Taveira de Oliveira wrote:
> --- Euler Taveira de Oliveira <[EMAIL PROTECTED]> escreveu:
>
> > I have a patch like this. But this was for 7.4.x. I have to take a
> > look
> > at it.
> >
> The patch is attached. It implements day and month i18n. I fixed a fe
I wrote:
Tom Lane said:
I think this probably needs to be more aggressive
though. In a
situation of limited SHMMAX it's probably more important to keep
shared_buffers as high as we can than to get a high max_connections. We
could think about increasing the 5x multiplier, adding Min and/or
I noticed that we are using the term "Online Backup" in our
documentation when we are talking about continuous backup and PITR.
To me, "online backup" is doing a backup while the system is online
(online-backup), and that is accomplished by pg_dump. I know a lot of
databases us "Online Backup" bu
I wrote:
> I'm thinking about whether we can't improve the message for "missing
> FROM-clause entry" to somehow account for situations where the table
> does exist in the query but it's referenced from an improper place,
> as in bug #2130 (filed a couple hours ago, not yet visible in mail list
> ar
I'm thinking about whether we can't improve the message for "missing
FROM-clause entry" to somehow account for situations where the table
does exist in the query but it's referenced from an improper place,
as in bug #2130 (filed a couple hours ago, not yet visible in mail list
archives):
SELECT ..
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Right now, '(a, b) < (1, 2)' is processed as 'a < 1 and b < 2', but
>> the SQL standard requires it to be processed as a column-by-column
>> comparison, so the proper comparison is '(a < 1) OR (a = 1 AND b < 2)'
> Can we save current behave (with smal
I think this brings up an interesting distinction, that having the NO
LOGGING switch per command doesn't make sense because it modifying the
table. It has to be a per-object switch, or something that operates
only on empty tables. This is the exact same distinction we talked
about for NO LOGGING
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> The existing initdb code actually does try to scale them in sync to
>> some extent ---
> Yes, I know. What I meant was that we could try using one phase
> rather than two. But that's only one possible approach.
I think that's a bad
Martijn van Oosterhout writes:
> If you want technical details I can do that too (the summary on
> pg-patches a while ago is now wildly out of date). Currently I'm trying
> to get up to speed on pathkeys and indexes before the tree drifts too
> far...
I've given this advice before to other people
On Mon, Dec 26, 2005 at 01:29:19PM +0100, Pavel Stehule wrote:
> Can we save current behave (with small modification) with other operator,
> like <*
>
> (1,1) <* (1,2) = true
> (1,2) <* (2,1) is NULL
> (2,3) <* (1,2) = false
>
> it's usefull for multicriterial optimalisation
That's strange. Tha
TODO updated:
* %Make row-wise comparisons work per SQL spec
Right now, '(a, b) < (1, 2)' is processed as 'a < 1 and b < 2', but
the SQL standard requires it to be processed as a column-by-column
comparison, so the proper comparison is '(a < 1) OR (a = 1 AN
On Mon, Dec 26, 2005 at 12:03:27PM +, Simon Riggs wrote:
> I would not be against such a table-level switch, but the exact
> behaviour would need to be specified more closely before this became a
> TODO item, IMHO.
Well, I think at a per table level is the only sensible level. If a
table isn't
On Sat, 2005-12-24 at 10:32 -0500, Tom Lane wrote:
> An ALTER TABLE SET LOGGED/UNLOGGED switch might have some merit, but
> please don't muddy the waters by confusing this with temp-table
> status.
I would not be against such a table-level switch, but the exact
behaviour would need to be specifie
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Can someone explain to me how:
> > (a, b) < (1, 2)
> > is different to
> > a < 1 and b < 2
>
> Right at the moment our code interprets it that way, but this behavior
> is wrong per spec. It should be an ordered column-by-co
Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
>
> > > src/tools/make_ctags is your friend...
> >
> > That just shows you where a symbol is defined, not where it's called
> > from. When you change the parameters of a function, you need to make
> > sure you found all the places that used it
On Sun, 2005-12-25 at 14:02 +0100, Gregor Zeitlinger wrote:
> as far as I have understood, the WAL backup that you control via
> "archive_command" is the PostgreSQL equivalent to what other databases
> let you do with an incremental backup
No it is not an incremental backup of changed data blocks,
34 matches
Mail list logo
