> > The downside would only be, that long running txn's cannot
> > [easily] rollback to savepoint.
>
> We should implement savepoints for all or none transactions, no?
We should not limit transaction size to online available disk space for WAL.
Imho that is much more important. With guaranteed
set_inherited_rel_pathlist in src/backend/path/allpaths.c says:
/*
* XXX for now, can't handle inherited expansion of FOR UPDATE; can we
* do better?
*/
Is this a terribly difficult thing to implement?
The RI triggers use FOR UPDATE which makes RI impossible with
inheritence hierarchies
pg_dump's help provides this near the bottom:
If no database name is not supplied, then the PGDATABASE environment
variable value is used.
Shouldn't that read:
If no database name is supplied, then the PGDATABASE environment
variable value is used.
or:
If the database name is not supplied, t
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> I'd check. But the postgresql ftp site appears to be broken for the past
>> few days.
>
> broken how? I just connected into it ...
Maybe you did, but no one else can. ftp.postgresql.org has said
530-The maximum number of concurrent conne
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Has this been already fixed or reported?
> test-# \dz
> Did not find any relation named "z".
> Segmentation fault (core dumped)
Yes, this is fixed in 7.1.2.
regards, tom lane
---(end of broadcast)---
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
> Just want a second opinion before I announce more publicly ...
Looks OK from here except for the problem Peter already noted:
the tarred-up doc files were created from development tip, not 7.1
branch.
Stephen Deasey <[EMAIL PROTECTED]> writes:
> set_inherited_rel_pathlist in src/backend/path/allpaths.c says:
> /*
> * XXX for now, can't handle inherited expansion of FOR UPDATE; can we
> * do better?
> */
> Is this a terribly difficult thing to implement?
It might be as easy as adding t
On Wed, May 23, 2001 at 10:55:35AM +0300, Alessio Bragadini wrote:
> Peter Eisentraut wrote:
>
> > This is a compilation of the BSD-licensed gettext tools from NetBSD plus
> > some of my own code, put into a (hopefully) portable package, intended to
> > be evaluated for possible use in PostgreSQL
On Wed, May 23, 2001 at 11:35:31AM -0400, Bruce Momjian wrote:
> > > > > We have added more const-ness to libpq++ for 7.2.
> > > >
> > > > Breaking link compatibility without bumping the major version number
> > > > on the library seems to me serious no-no.
> > > >
> > > > To const-ify member fu
On Sat, May 19, 2001 at 10:50:31AM -0400, Tom Lane wrote:
> I had a thought this morning that raising an error may be the wrong
> thing to do. We could instead choose to expand the name into
> "pg_class.*", which would take only a little more code and would
> arguably do something useful instead
I'm trying to form an rtree index on a custom datatype, and I've come
across a problem. The problem also affects the standard geometric
datatypes.
Here's a simple example:
> create table test_geom (poly polygon);
> insert into test_geom values ( '');
(...)
So far, so good, but when you try
[EMAIL PROTECTED] (Nathan Myers) writes:
> This is good news!
> Maybe this process can be formalized. That is, each official release
> migh contain a source file with various "modern" constructs which we
> suspect might break old compilers.
I have no objection to this, if the process *is* for
I forgot to mention that this is happening on 7.0.3and 7.1.1 -- and I'm
running on a RedHat 7.0 machine.
- Original Message -
From: "Brian Hirt" <[EMAIL PROTECTED]>
To: "Postgres Hackers" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, June 24, 2001 1:12 AM
Subject: Problem wit
On Wed, May 23, 2001 at 11:58:51AM -0400, Bruce Momjian wrote:
> > > I don't see the problem here. My assumption is that the comment is not
> > > part of the define, right?
> >
> > Well, that's the question. ANSI C requires comments to be replaced by
> > whitespace before preprocessor commands
> If community will not like UNDO then I'll probably try to implement
Imho UNDO would be great under the following circumstances:
1. The undo is only registered for some background work process
and not done in the client's backend (or only if it is a small txn).
2. Th
> > People also have referred to an overwriting smgr
> > easily. Please tell me how to introduce an overwriting smgr
> > without UNDO.
There is no way. Although undo for an overwriting smgr would involve a
very different approach than with non-overwriting. See Vadim's post about what
info suffic
At 14:33 22/05/01 -0700, Mikheev, Vadim wrote:
>
>If community will not like UNDO then I'll probably try to implement
>dead space collector which will read log files and so on.
I'd vote for UNDO; in terms of usability & friendliness it's a big win.
Tom's plans for FSM etc are, at least, going to
> >If community will not like UNDO then I'll probably try to implement
> >dead space collector which will read log files and so on.
>
> I'd vote for UNDO; in terms of usability & friendliness it's a big win.
Could you please try it a little more verbose ? I am very interested in
the advantage
At 11:25 23/05/01 +0200, Zeugswetter Andreas SB wrote:
>
>> >If community will not like UNDO then I'll probably try to implement
>> >dead space collector which will read log files and so on.
>>
>> I'd vote for UNDO; in terms of usability & friendliness it's a big win.
>
>Could you please try it
> - A simple typo in psql can currently cause a forced rollback of the entire
> TX. UNDO should avoid this.
Yes, I forgot to mention this very big advantage, but undo is not the only possible
way
to implement savepoints. Solutions using CommandCounter have been discussed.
Although the pg_log m
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 4. This breaking of a comment attached to a #define scares me.
>>
>> ***
>> *** 1691,1705
>>
>> #define FIXED_CHAR_SEL 0.04/* about 1/25 */
>> #define CHAR_RANGE_SEL 0.25
>> ! #define ANY_CHAR_SEL 0.9
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> I see some use of SEP_CHAR for '/' in the source. Do we want to use it
>> consistenly, or not use it at all? I can make the change.
> I vote for not at all, since there is not at all a use for it.
If it's not actually need
On Wed, 23 May 2001, Christopher Kings-Lynne wrote:
> For the add/drop constraint clauses would it be an idea to change the syntax
> to:
>
> ALTER TABLE [ ONLY ] x ADD CONSTRAINT x;
> ALTER TABLE [ ONLY ] x DROP CONSTRAINT x;
>
> So that people can specify whether the constraint should be inher
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see it used by psql and pg_dump and I will leave them alone, assuming
> / is not hardeded elsewhere in that code.
If you're gonna take it out, take it out completely.
regards, tom lane
---(end of broad
which ones should I pull in? the ones in ~/ftp/pub/doc/7.1? or is there
newer along that tree that we need to generate?
On Tue, 22 May 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
> >
> > Just want a second opinion before I ann
all mirrors use rsync to update their code, and all of those that are
listed at www.postgresql.org, both ftp and www, are no more then 2 days
old (Vince, it is two days we set it at, right?) ...
On Wed, 23 May 2001, bpalmer wrote:
> On Wed, 23 May 2001, Tom Lane wrote:
>
> > every time I've tr
On Wed, 23 May 2001, The Hermit Hacker wrote:
>
> all mirrors use rsync to update their code, and all of those that are
> listed at www.postgresql.org, both ftp and www, are no more then 2 days
> old (Vince, it is two days we set it at, right?) ...
Yup.
>
>
> On Wed, 23 May 2001, bpalmer wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 23 May 2001, Christopher Kings-Lynne wrote:
>> For the add/drop constraint clauses would it be an idea to change the syntax
>> to:
>>
>> ALTER TABLE [ ONLY ] x ADD CONSTRAINT x;
>> ALTER TABLE [ ONLY ] x DROP CONSTRAINT x;
If the patch is coded
Hannu Krosing <[EMAIL PROTECTED]> writes:
> but then no xmax should ever be visible in a regular query :
Not so. For example, if a transaction tried to delete a tuple, but is
either still open or rolled back, then other transactions would see its
XID in the tuple's xmax. Also, SELECT FOR UPDATE
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> I guess that is the question. Are we heading for an overwriting storage
>> manager?
> I've never heard that it was given up. So there seems to be
> at least a possibility to introduce it in the future.
Unless we want to abandon MVCC (which I don't),
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> which ones should I pull in? the ones in ~/ftp/pub/doc/7.1? or is there
> newer along that tree that we need to generate?
I think there are some doc fixes in the REL7_1 branch, so generating
from the end of that branch would be nicest.
Real quest
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I agree, but in a certain sense, we would have found those compilers
> already. This is not new behavour as far as I know, and clearly this
> would throw a compiler error.
[ Digs around ... ] OK, you're right, it's not new behavior; we have
instances
Peter Eisentraut - PostgreSQL <[EMAIL PROTECTED]> writes:
> Make createlang use dynamic loader enhancements (automatic path and suffix).
I observe that createlang still builds full paths for me. Evidently
this is because I have PGLIB set in my environment. I propose that
createlang ought
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I'm not sure what you mean here, Tom - I meant that the ONLY keyword could
> be optional.
The current gram.y code allows either ALTER TABLE foo ONLY or ALTER
TABLE foo* for all forms of ALTER ... with the default interpretation
being the lat
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Unless we want to abandon MVCC (which I don't), I think an overwriting
>> smgr is impractical.
> Impractical ? Oracle does it.
Oracle has MVCC?
regards, tom lane
---(end of broadcast
> > Seems like a bad idea to
> > me. But as long as the default is to propagate these changes, I'm not
> > really eager to prohibit DBAs from doing the other. Who's to say what's
> > a misuse of inheritance and what's not...
>
> At the moment we have:
>
> * ADD CONSTRAINT does not propagate
>
36 matches
Mail list logo
