Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, I am opening this can of worms again. I personally would like to
> see this code activated, even if it does take 2x the disk space to alter
> a column. Hiroshi had other ideas. Where did we leave this? We have
> one month to decide on a plan.
I
* Bruce Momjian <[EMAIL PROTECTED]> [000929 19:30] wrote:
> Can someone remind me of where we left this?
I really haven't figured a correct way to deal with the output buffer.
I'll try to consider ways to deal with this.
-Alfred
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The "rule" regression test gets stuck in an infinite loop in
> optimizer/prep/prepunion.c:find_inheritable_rt_entry. It seems to be a
> coding mistake; from what I can tell the loop can't ever exit if there are
> no inherited tables.
> I also get fai
Where are we on this?
>
> I start detail study of PG's memory management (because, I want remove
> prepared query-cache to shmem (more is in my old discussion with Jan)).
>
> I see current code in the aset.c and I found small non-effective memory
> usage.
>
>
> Description:
>
> The po
Do other people have a comment on this. I am inclined to leave it
along. This is the first complaint I have heard, and elog(PGDEBUG) just
looks funny. We don't prefix NOTICE or ERROR.
> In the file
>
>include/utils/elog.h
>
> there is a macro named
>
>DEBUG
>
> that conflicts with
This brings up some good issues for the 7.2 release. Will large objects
become just an API on top of toast, or should they remain as a separate
physical storage format?
> At 08:30 PM 3/15/00 -0500, Bruce Momjian wrote:
>
> >Yes, we should keep it. I see now it is for purely binary data, while
OK, I am opening this can of worms again. I personally would like to
see this code activated, even if it does take 2x the disk space to alter
a column. Hiroshi had other ideas. Where did we leave this? We have
one month to decide on a plan.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > You
Can someone remind me of where we left this?
> >> Um, I didn't have any trouble at all reproducing Patrick's complaint.
> >> pg_dump any moderately large table (I used tenk1 from the regress
> >> database) and try to load the script with psql. Kaboom.
>
> > This is after or before my latest pa
The core group has decided to delay 7.1 beta until November 1. We have
done this to enable the write-ahead log code (WAL) to be shipped with
7.1.
Of course, it also gives me time to catch up on my e-mail, which I am
doing now. :-)
--
Bruce Momjian| http://candle.pha
Jeroen, not sure if you were involved in this, but standard deviation is
in the current development tree, and will be released in 7.1 in a few
months.
> I'd like to implement stddev and variance aggregates in Postgres. This is a
> long standing TODO item.
>
> There already has been some discuss
This seems to be a bug:
Create Table tab1 (f1 integer);
Create Function tot_of_tab1() returns integer
as 'select cast(sum(f1) as int4) from tab1' language 'sql';
Alter Table tab1 add check(tot_of_tab1() > 0);
zzz=# insert into tab1 values(1);
INSERT 142380 1
zzz=# insert into tab1
The "rule" regression test gets stuck in an infinite loop in
optimizer/prep/prepunion.c:find_inheritable_rt_entry. It seems to be a
coding mistake; from what I can tell the loop can't ever exit if there are
no inherited tables.
I also get failures in sanity_check and misc, which might be due to
Scrappy's late victory ... The documentation needs to know about the
correct version number as well, but that doesn't work currently, without
creating a dependency on some file generated by config.status. So I'm
inclined to make it a separate file that only contains the number.
--
Peter Eisentr
* Erich <[EMAIL PROTECTED]> [000929 12:13] wrote:
>
> I have a very serious need for replication for my Postgres
> application. Rather than deciding to spend $40k on a commercial DBMS
> with replication (minimum cost) I decided I would invest my money in
> hiring a contractor to add support for
Tatsuo Ishii wrote:
> > On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
> > > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
> > > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
> > > ...
> > > pg_mbcliplen cannot be used in the frontend. Remove them, please.
>
I have a very serious need for replication for my Postgres
application. Rather than deciding to spend $40k on a commercial DBMS
with replication (minimum cost) I decided I would invest my money in
hiring a contractor to add support for the feature I need into
Postgres. The patch that gets writt
Jean-Christophe Pazzaglia <[EMAIL PROTECTED]> writes:
> we tried to switch the log on by lauching the postmaster
> with -d 5 redirected to a file but this file is deseperatly empty,
If you're using -S, stop doing so ...
regards, tom lane
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> What I'm thinking about doing is eliminating the "skipAcl" RTE field
>> and instead adding an Oid field named something like "checkAclAs".
>>
>> Comments? Is this a general enough mechanism, and does it fit well
>> with the various setUID tri
Peter Eisentraut wrote:
> I've committed the announced unified regression test driver. (See Sep.20
> message for list of features.) You can invoke it via `make check', either
> in the top level directory, or directly in src/test/regress. To test
> against a running installation, use `make insta
I've committed the announced unified regression test driver. (See Sep.20
message for list of features.) You can invoke it via `make check', either
in the top level directory, or directly in src/test/regress. To test
against a running installation, use `make installcheck'.
The existing drivers
> What I'm thinking about doing is eliminating the "skipAcl" RTE field
> and instead adding an Oid field named something like "checkAclAs".
> The semantics of this field would be "if zero, check access
> permissions
> for this table using the current effective userID; but if not zero,
> check ac
Jean-Christophe Pazzaglia writes:
> we tried to switch the log on by lauching the postmaster
> with -d 5 redirected to a file but this file is deseperatly empty,
> what it's wrong ? is the process writing to an other file or
> do we made a mistake with the arguments ?
Don't use the -S option.
-
Hi,
we tried to switch the log on by lauching the postmaster
with -d 5 redirected to a file but this file is deseperatly empty,
what it's wrong ? is the process writing to an other file or
do we made a mistake with the arguments ?
thanks in advance
regards,
jc
begin:vcard
n:Pazzaglia;Jean-
Tom Lane writes:
> > In the Debian package, I have put the administrator programs in
> > /usr/lib/postgresql/bin. The postgres user has that directory in its path
> > so that all works properly. Since root cannot run these, I don't think it
> > appropriate to put them in /usr/sbin.
That's okay
Adriaan Joubert <[EMAIL PROTECTED]> writes:
> we've suddenly started getting this error message out of postgres
> (7.0.2). Does anybody know where it comes from?
> ERROR: UNLockBuffer: buffer 0 is not locked
Evidently something is passing an invalid buffer number to LockBuffer
in src/backen
Tom Lane wrote:
[useful an complete discussion of sbin-style programs and their place
snipped]
> (Not sure about pg_dump/pg_dumpall/pg_restore; are these of any
> significant use to non-superusers?) This would keep createuser/dropuser
> out of the shared bin directory, which certainly seem like
Hi,
we've suddenly started getting this error message out of postgres
(7.0.2). Does anybody know where it comes from?
ERROR: UNLockBuffer: buffer 0 is not locked
Any help appreciated,
Adriaan
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I think it would be a real bad idea to put the postmaster and postgres
>>> executables right in /usr/local/bin. Perhaps it is time to think about
>>> a separate 'sbin' directory for programs that aren't supposed to be
>>> invoked
Tom Lane writes:
> I think there should be just one default ACL and it should be
> WORLD: no access
> OWNER: all access
> If you do any explicit granting then that should be the starting
> point.
Definitely so.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Lamar Owen wrote:
>Tom Lane wrote:
>> To do that without creating problems, we'd have to go back to making
>> sure that all the programs we install have 'pg'-prefixed names. The
>> scripts (createdb and so forth) don't at the moment, and names like
>> 'createuser' clearly have potential
30 matches
Mail list logo
