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 undo
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
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,
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 connections
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
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.
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. Give
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 of
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 ( 'LOTS OF POINTS');
(...)
So far, so good, but
[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*
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 with plpgsql
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 are
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.
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 suffices
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 advantages you
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 little more
- 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
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 /* not 1, since
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 needed for
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 inherited
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
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 announce
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 tried
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:
On
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 in the same
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), I think
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 question
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 of
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 latter.
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
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
* If you
34 matches
Mail list logo
