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
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
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
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
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
[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
>> 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.
-
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
> 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
> 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
[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
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
>> 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
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
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
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
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
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
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
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
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
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)--
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, 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
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
> >
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.
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
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
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
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
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
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
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
"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
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
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.
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
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
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
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
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
"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
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
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
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" <[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
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]
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
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
"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
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.
58 matches
Mail list logo
