Neil Conway <[EMAIL PROTECTED]> writes:
> I whipped up a quick patch to use names as well as OIDs for the
> identifiers in the message, but on reflection the simple approach to
> doing this is problematic: when we do syscache lookups to lookup the
> identifier names, we might need to acquire an Acc
The error message we currently produce when a deadlock occurs is pretty
unfriendly:
ERROR: deadlock detected
DETAIL: Process 32068 waits for AccessExclusiveLock on relation
16413 of database 16384; blocked by process 32064.
Process 32064 waits for AccessExclusiveLock on relation
Sorry I was very late to find this.
With DBT-2 benchmark, I've already compared the amount of WAL. The
result was as follows:
Amount of WAL after 60min. run of DBT-2 benchmark
wal_add_optimization_info = off (default) 3.13GB
wal_add_optimization_info = on (new case) 3.17GB -> can be optimize
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I found one unsupported form plpgsql's fetch statement which is
supported
> by postgresql.
> PostgreSQL knows
> FETCH 3 FROM
> but plpgsql needs everytime direction's keyword.
No, I think that's OK, because that form specifies fetching 3 ro
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I found one unsupported form plpgsql's fetch statement which is supported
> by postgresql.
> PostgreSQL knows
> FETCH 3 FROM
> but plpgsql needs everytime direction's keyword.
No, I think that's OK, because that form specifies fetching 3 rows,
Gustavo Tonini wrote:
I'm thinking in project and implement "data fragmentation" based on
catalogs inside
pgcluster as my university final project. I would like suggestions and
would be happy if anyone help me to define it. Sorry if this is the
incorrect list...I had no answer on "pgcluster-gener
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> What ideas?
Basically I think what we should do is extend SQL to support things like
UPDATE (subquery) SET ...
DELETE FROM (subquery) WHERE ...
Ie, do the update-able view magic in the planner and executor rather than in
the rewriter. Then the rew
On Thursday 05 April 2007 16:28, Larry Rosenman wrote:
> I might use that as the base then, since the hardware finishes getting here
> tomorrow.
>
> My question still stands on what OS's we need coverage for.
One I see as missing right now is Solaris 10 X86 with gcc building 64bit
binaries (we ha
Gregory Stark wrote:
>
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > The threads to updatable views have concluded rejecting the patches, and
> > with ideas that require rather extensive rewriting of the rule manager,
>
> I have some ideas on a different approach to this if anyone's think
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> The threads to updatable views have concluded rejecting the patches, and
> with ideas that require rather extensive rewriting of the rule manager,
I have some ideas on a different approach to this if anyone's thinking of
starting fresh but I had the
Stephen Frost wrote:
> While I agree that raising a warning makes sense I don't believe it
> should be forced. There may be cases where, even in security definer
> functions, the current search_path should be used (though, of course,
> care must be taken in writing such functions).
I really wonde
Hello people,
I'm thinking in project and implement "data fragmentation" based on
catalogs inside
pgcluster as my university final project. I would like suggestions and
would be happy if anyone help me to define it. Sorry if this is the
incorrect list...I had no answer on "pgcluster-general"...
T
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
> >The problem comes from cases like
> >
> > colname coltype DEFAULT 5! GENERATED ...
> >
> >Since b_expr allows postfix operators, it takes one more token of
> >lookahead than we have to tell if the default expression is "5!"
Hi
I believe I have discovered the following problem in pgsql 8.2 and HEAD,
concerning warm-standbys using WAL log shipping.
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since it won't wal-log those changes,
the slave won't know about thi
Hello,
I found one unsupported form plpgsql's fetch statement which is supported
by postgresql.
PostgreSQL knows
FETCH 3 FROM
but plpgsql needs everytime direction's keyword. It's need small fix. I am
sorry.
Regards
Pavel Stehule
_
Hello,
in doc there are for returned value:
SPI_processed and SPI_tuptable are set as in SPI_execute if successful.
But for move statement is SPI_tuptable undefined. Move statement only move
cursor. Doesn't return anything.
Regards
Pavel Stehule
_
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > I am seeing the following compiler warnings in CVS HEAD:
> > >
> > > analyze.c:471: warning: `diff' might be used uninitialized in this
> > > function
> > > vacuumlazy.c:220: warning: `diff' might be used uninitialize
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I am seeing the following compiler warnings in CVS HEAD:
> >
> > analyze.c:471: warning: `diff' might be used uninitialized in this
> > function
> > vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
> > function
>
> Ar
Bruce Momjian wrote:
> I am seeing the following compiler warnings in CVS HEAD:
>
> analyze.c:471: warning: `diff' might be used uninitialized in this
> function
> vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
> function
Are you using too old a compiler? Min
I am seeing the following compiler warnings in CVS HEAD:
analyze.c:471: warning: `diff' might be used uninitialized in this
function
vacuumlazy.c:220: warning: `diff' might be used uninitialized in this
function
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
Karl O. Pinc wrote:
>
> On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
>
> >
> >I'm not sure the plan is OK as stated. You wouldn't want to force to
> >parse the query again for each row. Rather, create a prepared
> >statement
> >(already parsed, because you obtain it from the parsetree store
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
There are also
some interesting questions about SQL spec compliance and whether a
database that silently hides some rows from you will give semantically
consistent results.
>>> Yeah -- that's a potentially serious issue;
Gregory Stark wrote:
> "Karl O. Pinc" <[EMAIL PROTECTED]> writes:
>
> > Rather than spend a whole lot of time figuring
> > out all the calls to use and all the detail,
> > I'm going to go ahead and post now. That way
> > if this is simply not going to fly I don't have
> > to spend any more time o
Jim C. Nasby wrote:
> Not bad... took you 40 lines to answer my question. Let's see if I can
> beat that...
Sure - it'll be 1 line when it's wrapped in a shell script. And then
we'll be even.
> I understand the argument about metadata and all, and largely agree with
> it. But on the other hand I
Jim C. Nasby wrote:
> Then how do you tell what version a file is if it's outside of a
> checkout?
It's trivial for git to answer that - the file will either be pristine,
and then we can just scan for the matching SHA1, or modified, and we can
scan (taking a weee bit more time) which are the "clos
On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
I'm not sure the plan is OK as stated. You wouldn't want to force to
parse the query again for each row. Rather, create a prepared
statement
(already parsed, because you obtain it from the parsetree stored in
the
INSERT rule) to pass to the ex
On 04/19/2007 09:33:44 AM, Andrew Dunstan wrote:
Karl O. Pinc wrote:
(Maybe if this works I'll see about copying
out of a view.)
You know we already have
COPY (SELECT ...) TO ...
don't you?
Sure. It'd just be syntatic suger for the
COPY (SELECT ...) form, so end-users
don't have to t
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> Rather than spend a whole lot of time figuring
> out all the calls to use and all the detail,
> I'm going to go ahead and post now. That way
> if this is simply not going to fly I don't have
> to spend any more time on it. Otherwise,
> I'll post more
Karl O. Pinc wrote:
>
> On 04/19/2007 08:41:55 AM, Karl O. Pinc wrote:
>
> >I would like to submit a patch so that the
> >COPY statement can import data into a view.
>
> >2) Allocate memory for char* and construct an
> >'INSERT ...' statement corresponding
> >to the COPY command that inserts int
Karl O. Pinc wrote:
(Maybe if this works I'll see about copying
out of a view.)
You know we already have
COPY (SELECT ...) TO ...
don't you?
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On 04/19/2007 08:41:55 AM, Karl O. Pinc wrote:
I would like to submit a patch so that the
COPY statement can import data into a view.
2) Allocate memory for char* and construct an
'INSERT ...' statement corresponding
to the COPY command that inserts into the view.
(Just how much memory shoul
Hello,
I would like to submit a patch so that the
COPY statement can import data into a view.
(Maybe if this works I'll see about copying
out of a view.)
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if t
Hi
Jim C. Nasby wrote:
I understand the argument about metadata and all, and largely agree with
it. But on the other hand I think a version identifier is a critical
piece of information; it's just as critical as the file name when it
comes to identifying the information contained in the file.
Hi,
Alvaro Herrera wrote:
Which is not always what happens in reality. Consider for example that
we borrowed some files from NetBSD, OpenBSD, Tcl, zic and others. It
would be nice to know exactly at what point we borrowed the file, so we
can go to the upstream repo and check if there's any bug
Tom Lane írta:
...
If anyone seriously wants to propose removing postfix ops from b_expr,
we'd better take it up on someplace more widely read than -patches.
regards, tom lane
OK, I take the bullet and send it to -hackers.
For everyone who don't read -patches, let m
35 matches
Mail list logo
