Heikki Linnakangas wrote:
Since we're discussing upgrades, let me summarize the discussions we had
over dinner in Ottawa for the benefit of all:
Thanks for summary.
As before, someone just needs to step up and do it.
I'm now working on proposal. I hope that it will ready soon.
"Joe Conway" <[EMAIL PROTECTED]>
> Tom Lane wrote:
>> Joe Conway <[EMAIL PROTECTED]> writes:
>>> My first thought on fixing this issue was to simply replace all
>>> instances of '\r' in pg_proc.prosrc with '\n' prior to sending it to the
>>> R parser. As far as I know, any instances of '\r' embe
On Thu, 2007-06-21 at 18:15 -0400, Tom Lane wrote:
> I've been reflecting a bit about whether the notion of deferred fsync
> for transaction commits is really safe. The proposed patch tries to
> ensure that no consequences of a committed transaction can reach disk
> before the commit WAL record is
On Thu, 2007-06-21 at 18:15 -0400, Tom Lane wrote:
> BTW: I really dislike the name "transaction guarantee" for the
> feature; it sounds like marketing-speak, not to mention overpromising
> what we can deliver.
There is no marketing speak there, nor any overpromising of what is
delivered. I real
3) ALTER FULLTEXT CONFIGURATION cfgname ADD/ALTER/DROP MAPPING
done
Why not rename ALTER FULLTEXT CONFIGURATION --> ALTER TEXT SEARCH
CONFIGURATION here too ?
It's renamed too.
most languages can be written using UNICODE charset and UTF-8 encoding,
so neither charset not encoding can be used
The recommendation I was making was to use the language name, not the
encoding name, in the user-visible configuration.
How does it determine language of db automatically?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
"Tom Lane" <[EMAIL PROTECTED]> writes:
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I've been reflecting a bit about whether the notion of deferred fsync
> for transaction commits is really safe. The proposed patch tries to
> ensure that no consequences of a committed transaction can reach disk
> be
William ZHANG wrote:
It's safe, because you'll be dealing with prosrc inside the backend,
therefore using a backend-legal encoding, and those don't have any ASCII
aliasing problems (all bytes of an MB character must have high bit set).
The lower byte of some characters in BIG5, GBK, G
Tom Lane wrote:
I've been reflecting a bit about whether the notion of deferred fsync
for transaction commits is really safe. The proposed patch tries to
ensure that no consequences of a committed transaction can reach disk
before the commit WAL record is fsync'd, but ISTM there are potential
ho
Michael Paesold wrote:
> > Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway
> > signage, "5m" means "five miles". Even the Americans do that better. So,
> > no, you can't have "m" for "minutes". ;)
>
> Even with the ;) here and the context, the last sentence sounds to me
> q
Michael Paesold wrote:
> Marko Kreen wrote:
> > Considering Postgres will never user either "meter" or "mile"
> > in settings, I don't consider your argument valid.
> >
> > I don't see the value of having units globally unique (literally).
> > It's enough if they unique in the context of postgresq
Peter Eisentraut wrote:
> Am Donnerstag, 21. Juni 2007 15:12 schrieb Andrew Dunstan:
> > You don't seem to have any understanding that the units should be
> > interpreted in context.
>
> You are right. I definitely have an understanding that units must be
> interpretable without context. And th
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> untrustworthy disk hardware, for instance. I'd much rather use names
>> derived from "deferred commit" or "delayed commit" or some such.
>
> Honestly, I prefer these names as well as it seems directly related versus
> transactio
Teodor Sigaev wrote:
> > The recommendation I was making was to use the language name, not the
> > encoding name, in the user-visible configuration.
> How does it determine language of db automatically?
I don't think we are going to do language selection automatically ---
the user is going to hav
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >
> >> untrustworthy disk hardware, for instance. I'd much rather use names
> >> derived from "deferred commit" or "delayed commit" or some such.
> >
> > Honestly, I pre
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
derived from "deferred commit" or "delayed commit" or some such.
Honestly, I prefer
I don't think we are going to do language selection automatically ---
the user is going to have to set tsearch_conf_name.
Are you suggest to remove long-lived feature of tsearch? In that case we don't
need cfglocale (or cfglanguage as Tom suggested) and cfgdefault columns in
pg_ts_cfg at all.
So now we're poking a hole in that but we certainly have to ensure that
any
transactions that do see the results of our deferred commit themselves
don't
record any visible effects until both their commit and ours hit WAL. The
essential point in Simon's approach that guarantees that is that w
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I very much doubt that the different spanishes are any different in the
> stemming rules, so there's no need for es_ES, es_PE, es_AR, es_CL etc;
> but in the case of portuguese I'm not so sure. Maybe there are other
> examples (like chinese, but I'm not
Jaime Casanova wrote:
> On 6/22/07, Euler Taveira de Oliveira <[EMAIL PROTECTED]> wrote:
> > Jaime Casanova wrote:
> >
> > > note the month abreviation (mons?) is this intentional?
> > >
> > This notation has been used since the code was written (~7 years ago) [1].
> >
> > [1]
> > http://developer.
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Simon Riggs wrote:
> >> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> >>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >>>
> Tom Lane wrote:
>
> > untrustworthy disk hardware, for instance. I'd much rather use names
> >
Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
derived from "deferred commit" or "delayed commit" or some such
Joshua D. Drake wrote:
I like "synchronous_commit = off", it even has a little girlfriend
getting spin while being accurate :)
In my experience, *_commit = off rarely gets you a girlfriend ...
cheers
andrew
---(end of broadcast)---
TIP 7:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I don't think we are going to do language selection automatically ---
>> the user is going to have to set tsearch_conf_name.
> Are you suggest to remove long-lived feature of tsearch? In that case we
> don't
> need cfglocale (or cfglanguage as Tom sug
Teodor Sigaev wrote:
> >> --- how do many languages use ISO8859-1 locale?.
> > ISO8859-1 is encoding, not locale.
>
> I meant, if we'll use encoding name (for example PG_LATIN1) we couldn't
> distinguish languages which use that encoding (for example italian and
> finnish and some more), but u
Joshua D. Drake wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
derived from "deferred commit" or "delayed commit" or some su
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Hm, another possibility: "synchronous_commit = off"
> Ooo, I like that. Any other takers?
OK with me
regards, tom lane
Andrew Sullivan wrote:
On Thu, Jun 21, 2007 at 03:24:51PM +0200, Michael Paesold wrote:
There are valid reasons against 5m as mega-bytes, because here m does
not refer to a unit, it refers to a quantifier (if that is a reasonable
English word) of a unit. So it should really be 5mb.
log_rotati
Simon Riggs wrote:
> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >
> > > Tom Lane wrote:
> > >
> > >> untrustworthy disk hardware, for instance. I'd much rather use names
> > >> derived from "deferred commit" or "delayed commit" or s
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I very much doubt that the different spanishes are any different in the
> > stemming rules, so there's no need for es_ES, es_PE, es_AR, es_CL etc;
> > but in the case of portuguese I'm not so sure. Maybe there are other
> > examples
On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >
> >> untrustworthy disk hardware, for instance. I'd much rather use
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
Hm, another possibility: "synchronous_commit = off"
Ooo, I like that. Any other takers?
>>> Yea, I like that too but I am now realizing that we are not really
>>> deferring or delaying the "COMMIT" command but rather the
On Fri, 2007-06-22 at 10:52 -0400, Bruce Momjian wrote:
> commit_stability? reliable_commit?
commit_durability?
That then relates it directly to the D in ACID.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)--
On Fri, 22 Jun 2007, Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
I very much doubt that the different spanishes are any different in the
stemming rules, so there's no need for es_ES, es_PE, es_AR, es_CL etc;
but in the case of portuguese I'm not so sure. Ma
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> I very much doubt that the different spanishes are any different in the
>> stemming rules, so there's no need for es_ES, es_PE, es_AR, es_CL etc;
>> but in the case of portuguese I'm not so sure. Maybe there are other
>> examples (lik
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Joshua D. Drake wrote:
> Hm, another possibility: "synchronous_commit = off"
>
> Ooo, I like that. Any other takers?
>
> >>> Yea, I like that too but I am now realizing that we are not really
> >>> deferring or delaying the
PFC wrote:
On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> untrustworthy disk hardware, for instance. I'd much rather
On Jun 22, 2007, at 9:23 , Richard Huxton wrote:
Or perhaps "sync_on_commit = off"?
Or switch it around...
sink_on_commit = on
(sorry for the noise)
Michael Glaesemann
grzm seespotcode net
---(end of broadcast)---
TIP 5: don't forget to in
Magnus Hagander wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> I very much doubt that the different spanishes are any different in the
> >> stemming rules, so there's no need for es_ES, es_PE, es_AR, es_CL etc;
> >> but in the case of portuguese I'm not so sure. Maybe
Bruce Momjian wrote:
Tom Lane wrote:
What's wrong with synchronous_commit? It's accurate and simple.
That is fine too.
My concern would be that it can be read two ways:
1. When you commit, sync (something or other - unspecified)
2. Synchronise commits (to each other? to something else?)*
I
>> That may have been true until we started supporting Windows...
>> Swedish_Sweden.1252 is what I get on my machine, for example. Principle
>> is the same, but values certainly aren't.
>
> Well, at least the name is not itself translated, so a mapping table is
> not right out of the question. If
Michael Glaesemann wrote:
>
> On Jun 22, 2007, at 9:28 , Tom Lane wrote:
>
> > Is the point here for initdb to be able to establish a sane default
> > initially? Seems to me it can guess the language from the first
> > component of the locale (ru_RU -> russian).
>
> How would this work for init
[EMAIL PROTECTED] wrote:
> So, final propose:
> rename cfglocale to cfglanguages and store in it array of laguage names
> which is produced from first part of locale names:
> russian '{ru_RU, Russian_Russia}'
> spanish '{es_ES, es_CL, Spanish_Spain, Spanish_Chile}'
>
> Comments?
Why not do i
> On Jun 22, 2007, at 9:28 , Tom Lane wrote:
>
> > Is the point here for initdb to be able to establish a sane default
> > initially? Seems to me it can guess the language from the first
> > component of the locale (ru_RU -> russian).
>
> How would this work for initdb with locale C?
I'm worryi
On Jun 22, 2007, at 9:28 , Tom Lane wrote:
Is the point here for initdb to be able to establish a sane default
initially? Seems to me it can guess the language from the first
component of the locale (ru_RU -> russian).
How would this work for initdb with locale C?
Michael Glaesemann
grzm se
> Why not do it the other way around?
> es_ES spanish
> Spanish_Spain spanish
> ru_RU russian
> pt_BR portuguese_brazil
>
> That way you don't need any funny index. Or do you need the list of
> locales for each language? (but even if you do, you can easily obtain it
> by in
> >> How would this work for initdb with locale C?
> >
> > I'm worrying about that too.
>
> english '{en_GB, en_US, C}'
>
> I suppose, that locale name always has a dot separator exept C locale ---
> which is well known exception
So we would have to?:
japanese '{ja_JP, C}'
How would we know C
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> On Jun 22, 2007, at 9:28 , Tom Lane wrote:
>>> Is the point here for initdb to be able to establish a sane default
>>> initially? Seems to me it can guess the language from the first
>>> component of the locale (ru_RU -> russian).
>>
>> How would this w
Richard Huxton <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> What's wrong with synchronous_commit? It's accurate and simple.
> My concern would be that it can be read two ways:
> 1. When you commit, sync (something or other - unspecified)
> 2. Synchronise commits (to each other? to something
>> How would this work for initdb with locale C?
>
> I'm worrying about that too.
english '{en_GB, en_US, C}'
I suppose, that locale name always has a dot separator exept C locale ---
which is well known exception
---(end of broadcast)---
TIP 1
Richard Huxton wrote:
Bruce Momjian wrote:
Tom Lane wrote:
What's wrong with synchronous_commit? It's accurate and simple.
That is fine too.
My concern would be that it can be read two ways:
1. When you commit, sync (something or other - unspecified)
2. Synchronise commits (to each other?
Am Freitag, 22. Juni 2007 15:34 schrieb Bruce Momjian:
> Consider even if we are clear that "min" is "minutes", it could be
> chronological minutes or radial degree minutes, so yea, the context has
> to be considered.
The correct symbol for an arc minute is ยด, so there is no context dependency.
-
[EMAIL PROTECTED] wrote:
> > Why not do it the other way around?
> > es_ES spanish
> > Spanish_Spain spanish
> > ru_RU russian
> > pt_BR portuguese_brazil
> >
> > That way you don't need any funny index. Or do you need the list of
> > locales for eac
I apologize for not grabbing more information before the evidence was gone,
but I think there may be a vulnerability to database corruption on PITR
recovery if a stop is done with the "fast" option right after a database logs
"archive recovery complete". We normally have about 17 seconds between t
In connection with bug #3403
http://archives.postgresql.org/pgsql-bugs/2007-06/msg00114.php
I've come to the conclusion that we really shouldn't do *any* processing
of utility commands at parse analysis time; they should be left as
raw-grammar output trees until execution.
The key reason for this
On Jun 19, 2007, at 1:27 PM, Josh Berkus wrote:
I know there's issues with using ident sameuser via TCP, but what
about for filesystem socket connections?
Not all OSes support ident ... Solaris and OpenBSD for two, don't,
because
they see ident as insecure.
What about the unix domain socke
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Jun 19, 2007, at 1:27 PM, Josh Berkus wrote:
>> Not all OSes support ident ... Solaris and OpenBSD for two, don't,
>> because they see ident as insecure.
> What about the unix domain socket, though? AFAIK that doesn't rely on
> ident but some other me
FYI, I am visiting California until Wednesday, June 27, to attend a
funeral. I will be reading email, but not as frequently.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard dri
58 matches
Mail list logo
