Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > I'd like to add:
> > - Remove "filling with zero" before we recycle WAL segments.
>
> Huh? We have never done that.
Oh, sorry. I misread the codes.
I would avoid PANIC if I have enough segements at start up
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I'd like to add:
> - Remove "filling with zero" before we recycle WAL segments.
Huh? We have never done that.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searche
On Sun, Oct 28, 2007 at 08:18:04PM -0500, Merlin Moncure wrote:
> On 10/27/07, David Fetter <[EMAIL PROTECTED]> wrote:
> > The only way I've done multisets is by creating functions that
> > return multiple refcursors, either in a row or as SETOF. Is or
> > was there some other way?
>
> ...arrays
On 10/27/07, David Fetter <[EMAIL PROTECTED]> wrote:
> The only way I've done multisets is by creating functions that return
> multiple refcursors, either in a row or as SETOF. Is or was there
> some other way?
...arrays of composite type :-)
merlin
---(end of broadcast)
Greg Smith <[EMAIL PROTECTED]> wrote:
> There's a couple of potential to-do list ideas that build on the changes
> in this area in 8.3:
>
> -Aggressively pre-allocate WAL segments
> -Space out checkpoint fsync requests in addition to disk writes
> -Consider re-inserting a smarter bgwriter all-
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I suspect domains are one of our least used features, which might
> account for the lack of complaint.
True, and it would also say that the risk of breaking any existing app
is low ...
regards, tom lane
---
Tom Lane wrote:
You have a point, but on reflection I think the odds of this change
breaking an existing application are low. The reason is that in the old
implementation, "DEFAULT NULL" is effectively not there at all, and so
an update to a newer point-release, or even a dump and reload, woul
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Is it OK to change this behavior? Should I
>> back-patch, or not?
> I would tend to be more conservative than we've been in the past with
> back patching. We keep saying people should be on the most recent
> poi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> AFAICS this is a flat-out bug too, since the per-column default should
> override the domain's default; that's certainly how it works for any
> non-null column default value. But I wasn't expecting any regression
> failures with this patch. Is it OK to ch
J.,
I'd actually be curious what incremental changes you could see making to
PostgreSQL for better in-memory operation. Ideas?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I wrote:
> ... I propose stripping out gram.y's special
> hack for this, and preserving the efficiency of the case by
> inserting a test very much later to see if the expression is just
> a NULL constant. Maybe AddRelationRawConstraints is the right place.
I did this (see attached patch) and got
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well if there's a convenient later place to add the check then sure. Will it
> mean pg_dump will have to put DEFAULT NULL everywhere though? Or can it detect
> that it's an inherited table where the default doesn't match?
The latter --- I already committ
"Tom Lane" <[EMAIL PROTECTED]> writes:
> ISTM this is a backend bug: if I tell it DEFAULT NULL, by golly I
> should get DEFAULT NULL. I propose stripping out gram.y's special
> hack for this, and preserving the efficiency of the case by
> inserting a test very much later to see if the expression
Simon Riggs <[EMAIL PROTECTED]> writes:
> Seems more like an unwanted looseness in the meaning of an ALTER
> TABLE .. INHERIT to me. I'd prefer it if we added some extra clauses to
> ALTER TABLE:
> [ { INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES } ]
I think you're confusing this wi
On Sun, 2007-10-28 at 12:44 -0400, Tom Lane wrote:
> While poking at the complaint reported here:
> http://archives.postgresql.org/pgsql-general/2007-10/msg01484.php
> I realized that there is a related issue for null defaults. Consider
>
> create table p (f1 int default 0);
> create
Have you seen contrib/pg_trgm module ?
Oleg
On Sun, 28 Oct 2007, Volkan YAZICI wrote:
Hi,
In an address search framework of a company, we need to deal with
queries including potential spelling errors. After some external
address space constraints (e.g. match first letters, word length,
etc.) w
While poking at the complaint reported here:
http://archives.postgresql.org/pgsql-general/2007-10/msg01484.php
I realized that there is a related issue for null defaults. Consider
create table p (f1 int default 0);
create table c (f1 int);
alter table c inherit p;
At this
* Volkan YAZICI:
> [1] Some approaches to best-match file searching
> http://portal.acm.org/citation.cfm?id=362003.362025
http://citeseer.ist.psu.edu/1593.html suggests that this uninteresting
(too much of the database is examined) once you go past an edit distance
of 1. I don't know if this
Hi,
In an address search framework of a company, we need to deal with
queries including potential spelling errors. After some external
address space constraints (e.g. match first letters, word length,
etc.) we're still ending up with a huge data set to filter through
Levenshtein like distance metr
On 10/28/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> Ühel kenal päeval, R, 2007-10-26 kell 16:46, kirjutas Gokulakannan
> Somasundaram:
> > What does the numbers look like if the the tables are small
> > enough to
> > fit in RAM?
> >
> > I don't know whether this is a v
On Sat, 2007-10-27 at 22:13 -0300, Alvaro Herrera wrote:
> Sorry I forgot to mention your name in the commit message :-( This
> weekend I'm moving to a new flat so I was distracted. Thanks for the
> patch, I didn't change it much.
> I'll commit a separate patch to credit you for the patch
Many
Just found this in the doc:
"WITH HOLD may not be specified when the query includes FOR UPDATE or FOR SHARE"
Here is what the Informix doc says about WITH HOLD + FOR UPDATE:
"It is possible to declare an update cursor with the WITH HOLD keywords,
but the only reason to do so is to break a long
Florian,
Do you mean WITH HOLD cursors (+ FOR UPDATE) can also be used to do
DELETE/UPDATE WHERE CURRENT OF (i.e. outside transactions) ?
From my experience this is an Informix-only feature, but if PostgreSQL
supports that it would help a lot to migrate existing applications.
I understand it's
23 matches
Mail list logo
