On 5/14/2007 3:35 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The only problem with that is that there are code paths that set
ActiveSnapshot to palloc()'d memory that is released due to a
MemoryContextDelete() without resetting ActiveSnapshot to NULL.
Only at the ve
On 5/14/2007 1:29 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The comment for the call of pg_plan_queries in util/cache/plancache.c
line 469 for example is fatally wrong. Not only should the snapshot be
set by all callers at this point, but if the call actually does repla
On 5/12/2007 4:53 PM, Jan Wieck wrote:
Either calling pg_plan_queries() with needSnapshot=false or saving and
restoring ActiveSnapshot will prevent the backend from dumping core in
the mentioned example, but I am not entirely sure as to which one is the
right solution.
Attached is a self
The use of ActiveSnapshot throughout the code appears rather dangerous
to me. It is a global pointer, assumed not to be set yet in some places,
assumed to be saved and restored by the caller in others. The actual
(context) memory it points to is sometimes explicitly freed, sometimes
just left i
ne with me, I just wasn't able to come up with any
sensible naming scheme other than replication related. Can you?
Jan
-----------
Jan Wieck wrote:
For discussion:
Attached is the completed patch that changes pg_trigger a
On 3/21/2007 2:05 PM, Tom Lane wrote:
Chris Browne <[EMAIL PROTECTED]> writes:
#define TOAST_DENOMINATOR 17
/* Use this as the divisor; current default behaviour falls from TOAST_DENOMINATOR = 4 */
#define TOAST_TUPLE_THRESHOLD^I\
^IMAXALIGN_DOWN((BLCKSZ - \
^I^I^I^I MAXALIGN(sizeof(Pag
On 3/21/2007 1:46 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 3/20/2007 1:11 PM, Tom Lane wrote:
search_path
add_missing_from
transform_null_equals
sql_inheritance
Don't we actually store the parsetree in the query cache, and doesn't
that actually make a
On 3/20/2007 1:11 PM, Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked t
On 3/19/2007 8:51 PM, Tom Lane wrote:
[EMAIL PROTECTED] (Jan Wieck) writes:
Changes pg_trigger and extend pg_rewrite in order to allow triggers and
rules to be defined with different, per session controllable, behaviors
for replication purposes.
Surely this patch should've inclu
On 2/9/2007 3:25 PM, Andrew Dunstan wrote:
Richard Troy wrote:
On Fri, 9 Feb 2007, Andrew Dunstan wrote:
Richard Troy wrote:
In more specific terms, and I'm just brainstorming in public here, perhaps
we can use the power of Schemas within a database to manage such
divisions; commands w
On 2/9/2007 2:19 PM, Andrew Hammond wrote:
On Feb 7, 8:12 pm, [EMAIL PROTECTED] (Bruce Momjian) wrote:
Jan Wieck wrote:
> On 2/7/2007 10:35 PM, Bruce Momjian wrote:
> > I find the term "logical proof of it's correctness" too restrictive. It
> > sounds like som
On 2/9/2007 2:27 PM, Richard Troy wrote:
In general terms, "blending of replication [techniques]" means to me that
one can have a single database instance serve as a master and as a slave
(to use only one set of terminology), and as a multi-master, too, all
simultaneously, letting the DBA / Archi
On 2/8/2007 2:46 PM, Marc Munro wrote:
On Thu, 2007-08-02 at 14:33 -0500, Tom Lane wrote:
Marc Munro <[EMAIL PROTECTED]> writes:
> Yes in this case, T1 must abort because the record it was going to
> update has disappeared from underneath it. I don't see how this is
> significantly different fr
On 2/7/2007 7:13 AM, José Orlando Pereira wrote:
On Saturday 03 February 2007, Bruce Momjian wrote:
Jan Wieck wrote:
> I don't have any such paper and the proof of concept will be the
> implementation of the system. I do however see enough resistance against
> this proposal t
On 2/8/2007 11:41 PM, Richard Troy wrote:
On Thu, 8 Feb 2007, Joshua D. Drake wrote:
Well how deep are we talking here? My understanding of what Jan wants to
do is simple.
Be able to declare which triggers are fired depending on the state of
the cluster.
In Jan's terms, the Origin or Subscrib
On 2/8/2007 3:32 PM, Bruce Momjian wrote:
Alvaro Herrera wrote:
> > Is this a new policy that after discussion, all patches must be
> > resubmitted with a summary and conclusions of the discussion? I can
> > certainly do that for you, but just tell me if you are going to ask the
> > same from
On 2/7/2007 11:12 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 2/7/2007 10:35 PM, Bruce Momjian wrote:
> I find the term "logical proof of it's correctness" too restrictive. It
> sounds like some formal academic process that really doesn't work well
> for us.
On 2/7/2007 10:35 PM, Bruce Momjian wrote:
I find the term "logical proof of it's correctness" too restrictive. It
sounds like some formal academic process that really doesn't work well
for us.
Thank you.
Also, I saw the trigger patch with no explaination of why it was
important or who would
On 2/7/2007 9:27 PM, Markus Schiltknecht wrote:
Hi,
Jan Wieck wrote:
Then let me give you a little puzzle just for the fun of it.
A database containing customer contact information (among other things)
is a two node multimaster system. One is serving the customer web
portal, the other is
On 2/7/2007 2:15 PM, Richard Troy wrote:
Jan Wieck wrote:
> Are we still discussing if the Postgres backend may provide support for
> a commit timestamp, that follows the rules for Lamport timestamps in a
> multi-node cluster?
...I thought you said in this thread that you haven'
On 2/7/2007 12:54 PM, Markus Schiltknecht wrote:
Hi,
Jan Wieck wrote:
Are we still discussing if the Postgres backend may provide support for
a commit timestamp, that follows the rules for Lamport timestamps in a
multi-node cluster?
No. And I think you know my opinion about that by now
On 2/7/2007 2:37 AM, Markus Schiltknecht wrote:
Hi,
Jan Wieck wrote:
Whatever strategy one will use, in an async multimaster there are always
cases that can be resolved by rules (last update being one of them), and
some that I can't even imagine solving so far. I guess some of the cases
On 2/6/2007 11:44 AM, Markus Schiltknecht wrote:
Hi,
Zeugswetter Andreas ADI SD wrote:
And "time based"
is surely one of the important conflict resolution methods for async MM
replication.
That's what I'm questioning. Wouldn't any other deterministic, but
seemingly random abort decision be a
On 2/5/2007 11:52 AM, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
Sounds like a good time to suggest making these values configurable,
within certain reasonable bounds to avoid bad behaviour.
Actually, given what we've just learned --- namely that choosing these
values at random
On 2/4/2007 10:53 AM, Theo Schlossnagle wrote:
As the clock must be incremented clusterwide, the need for it to be
insync with the system clock (on any or all of the systems) is
obviated. In fact, as you can't guarantee the synchronicity means
that it can be confusing -- one expects a time-
On 2/4/2007 3:16 AM, Peter Eisentraut wrote:
Jan Wieck wrote:
This is all that is needed for last update wins resolution. And as
said before, the only reason the clock is involved in this is so that
nodes can continue autonomously when they lose connection without
conflict resolution going
On 2/2/2007 4:51 AM, Simon Riggs wrote:
It sounds like if we don't put a SHARE lock on the referenced table then
we can end the transaction in an inconsistent state if the referenced
table has concurrent UPDATEs or DELETEs. BUT those operations do impose
locking rules back onto the referencing ta
On 2/3/2007 5:20 PM, Bruce Momjian wrote:
Jan Wieck wrote:
I don't have any such paper and the proof of concept will be the
implementation of the system. I do however see enough resistance against
this proposal to withdraw the commit timestamp at this time. The new
replication system
On 2/3/2007 5:25 PM, Joshua D. Drake wrote:
Jan Wieck wrote:
Attached is the implementation of the proposed changes as a patch for
discussion.
The chosen syntax is backward compatible and uses
ALTER TABLE ENABLE TRIGGER (fires on origin - default)
ALTER TABLE DISABLE TRIGGER (disabled
On 2/3/2007 4:58 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 4:38 PM, Jan Wieck wrote:
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database
Attached is the implementation of the proposed changes as a patch for
discussion.
The chosen syntax is backward compatible and uses
ALTER TABLE ENABLE TRIGGER (fires on origin - default)
ALTER TABLE DISABLE TRIGGER (disabled)
ALTER TABLE ENABLE REPLICA TRIGGER (fires on replica only)
ALTE
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timestamp will be truncated to milliseconds and the
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given, the
timestamp will be truncated to milliseconds and the increment logic
is done on milliseconds. The priority is added to the timestamp.
This
On 1/31/2007 12:41 PM, Tom Lane wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
On 1/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
The toast code takes pains to ensure that the tuples it creates won't be
subject to re-toasting. Else it'd be an infinite recursion.
I think I found it. The to
On 1/27/2007 7:26 AM, Gregory Stark wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I think the system I described is a slightly modified Lamport generator. The
maximum timestamp of any row updated in this transaction, you can consider that
the "counters received from other nodes&qu
On 1/26/2007 5:09 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/26/2007 4:40 PM, Jim Nasby wrote:
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.
So you think about another flag in pg_shadow? Wou
On 1/26/2007 4:47 PM, Jan Wieck wrote:
On 1/26/2007 4:39 PM, Jim Nasby wrote:
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking t
On 1/26/2007 4:40 PM, Jim Nasby wrote:
On Jan 25, 2007, at 5:33 PM, Jan Wieck wrote:
A new per session GUC variable, restricted to superusers, will
define if the session is in origin or replica mode.
It would be nice if we had a separate role for replication services
so that we weren&#
On 1/26/2007 4:39 PM, Jim Nasby wrote:
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing data out to the slave...
I think it'd mak
On 1/26/2007 3:41 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Checked it against HEAD and 8.2:
postgres=# select 1, 1, 1 union select * from (select 2, null, 2) two;
ERROR: failed to find conversion function from "unknown" to integer
It's always done that.
Checked it against HEAD and 8.2:
postgres=# select 1, 1, 1 union select * from (select 2, null, 2) two;
ERROR: failed to find conversion function from "unknown" to integer
Jan
--
#==#
# It's easier to get forgiveness for bein
On 1/26/2007 11:58 AM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/26/2007 8:06 AM, Gregory Stark wrote:
It seems simpler to have a current_snapshot() function that returns an bytea
or a new snapshot data type which set_current_snapshot(bytea) took to change
your snapshot
On 1/26/2007 12:22 PM, Simon Riggs wrote:
On Fri, 2007-01-26 at 11:36 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> No, that would break MVCC. But we may have done lots of updates/deletes
> that are *not* visible to any Snapshot, yet are not yet removable
> because they are
On 1/26/2007 9:38 AM, Stephen Frost wrote:
* Jan Wieck ([EMAIL PROTECTED]) wrote:
On 1/26/2007 2:37 AM, Naz Gassiep wrote:
>I would be *very* concerned that system time is not a guaranteed
>monotonic entity. Surely a counter or other internally managed mechanism
>would be a better
On 1/26/2007 8:26 AM, Simon Riggs wrote:
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
To provide this data, I would like to add another "log" directory,
pg_tslog. The files in this directory will be similar to the clog, but
contain arrays of timestamptz values. On commit, t
On 1/26/2007 8:06 AM, Gregory Stark wrote:
"Jan Wieck" <[EMAIL PROTECTED]> writes:
backend1: select publish_snapshot(); -- will block
backend2: start transaction;
backend2: set transaction isolation level serializable;
backend2: select clone_snapshot();
On 1/26/2007 2:37 AM, Naz Gassiep wrote:
I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed mechanism
would be a better solution.
Such a counter has only "local" relevance. How do you plan to compare
the two separate
On 1/25/2007 11:41 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 1/25/2007 6:49 PM, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>> To provide this data, I would like to add another "log" directory,
>> pg_tslog. The files in this directory will be simil
Granted this one has a few open ends so far and I'd like to receive some
constructive input on how to actually implement it.
The idea is to clone an existing serializable transactions snapshot
visibility information from one backend to another. The semantics would
be like this:
backend1:
On 1/25/2007 8:42 PM, Richard Troy wrote:
On Thu, 25 Jan 2007, Jan Wieck wrote:
For a future multimaster replication system, I will need a couple of
features in the PostgreSQL server itself. I will submit separate
proposals per feature so that discussions can be kept focused on one
feature per
On 1/25/2007 7:33 PM, Tom Lane wrote:
1 fires always
0 fires never
N fires in "Normal" mode
R fires in "Replica" mode
other letters available for other future mode values?
If you consistently think of "origin" and "replica" modes th
On 1/25/2007 7:41 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/25/2007 6:47 PM, Neil Conway wrote:
Would this feature have any use beyond the specific project/algorithm
you have in mind?
The tablelog project on pgfoundry currently uses the transactions start
time but
On 1/25/2007 6:49 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
To provide this data, I would like to add another "log" directory,
pg_tslog. The files in this directory will be similar to the clog, but
contain arrays of timestamptz values.
Why should everybody be
On 1/25/2007 6:47 PM, Neil Conway wrote:
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
For conflict resolution purposes in an asynchronous multimaster system,
the "last update" definition often comes into play. For this to work,
the system must provide a monotonically
On 1/25/2007 6:55 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The value definitions of tg_enabled would be
A fires always
N fires never
O fires on transaction origin only
R fires on replica only
A new per session GUC variable, restric
The experience with Slony-I has shown that
a) different behavior of triggers and rules on a transactions origin
and a replica is essential;
b) mucking around with the system catalog to achieve this is futile.
This would be even more catastrophic in a multimaster environment, where
reg
For a future multimaster replication system, I will need a couple of
features in the PostgreSQL server itself. I will submit separate
proposals per feature so that discussions can be kept focused on one
feature per thread.
For conflict resolution purposes in an asynchronous multimaster system,
On 1/18/2007 10:35 AM, Tom Lane wrote:
<[EMAIL PROTECTED]> writes:
Many of the keywords listed in keywords.c are defined with symbolic
names that end in '_P' (underscore P).
What differentiates those keywords from the other keywords? What does
the 'P' stand for?
P = Parser. The reason for th
On 10/27/2006 3:47 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
since rev. 1.105 of include/port.h all files that inlcude postgres_fe.h
are forced to use pg_qsort() instead of qsort. Was that intended?
Is it a problem? If you really want the platform qsort you can #undef
since rev. 1.105 of include/port.h all files that inlcude postgres_fe.h
are forced to use pg_qsort() instead of qsort. Was that intended?
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# L
On 10/5/2006 5:04 PM, Tom Lane wrote:
I came across the following obviously corrupt macro in pg_lzcompress.h:
#define PGLZ_IS_COMPRESSED(_lzdata) ((_lzdata)->varsize !=
\
e
On 7/14/2006 12:01 PM, Tom Lane wrote:
tsearch2 is functionality that definitely should be in core eventually,
but even Oleg still says it's not done. Aside from the documentation
issue, it's not clear that we've got a stable API for it.
Would moving it in its current state into core help it
On 7/9/2006 8:32 AM, Martijn van Oosterhout wrote:
On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
>I hope the above example is strong enough to elicit a comment from a
>qualified developer. If it is not, consider that stored procedures
On 6/30/2006 11:55 AM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 6/30/2006 11:17 AM, Marko Kreen wrote:
If the xxid-s come from different DB-s, then there can still be problems.
How so? They are allways part of a multi-key index having the
originating node ID first.
On 6/30/2006 11:17 AM, Marko Kreen wrote:
On 6/30/06, Jan Wieck <[EMAIL PROTECTED]> wrote:
With the final implementation of log switching, the problem of xxid
wraparound will be avoided entirely. Every now and then slony will
switch from one to another log table and when the old one is d
On 6/30/2006 9:55 AM, Tom Lane wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
The sl_log_* tables are indexed on xid, where the relations between
values are not exactly stable. When having high enough activity on
one node or having nodes with XIDs on different enough positions
funny things ha
On 6/25/2006 10:12 PM, Bruce Momjian wrote:
When you are using the update chaining, you can't mark that index row as
dead because it actually points to more than one row on the page, some
are non-visible, some are visible.
Back up the truck ... you mean in the current code base we have heap
tu
On 6/25/2006 5:18 PM, Bruce Momjian wrote:
Jan Wieck wrote:
>> An update that results in all the same values of every indexed column of
>> a known deleted invisible tuple. This reused tuple can by definition not
>> be the one currently updated. So unless it is a table
On 6/25/2006 2:24 PM, Bruce Momjian wrote:
Jan Wieck wrote:
>> Sure, but index reuse seems a lot easier, as there is nothing additional
>> to remember or clean out when doing it.
>
> Yes, seems so. TODO added:
>
> * Reuse index tuples that point to heap tuples
On 6/24/2006 4:10 PM, Hannu Krosing wrote:
Ühel kenal päeval, L, 2006-06-24 kell 15:44, kirjutas Jan Wieck:
>> That fixes the symptom, not the problem. The problem is performance
>> steadily degrades over time.
>
> No, you got it backwards. The performance degradation is t
On 6/25/2006 12:27 PM, Bruce Momjian wrote:
Hannu Krosing wrote:
> > Maybe we could start from reusing the index tuples which point to
> > invisible tuples ? The index is not MVCC anyway, so maybe it is easier
> > to do in-place replacement there ?
> >
> > This probably has the same obstacles
On 6/25/2006 6:52 AM, Mark Woodward wrote:
On 6/24/2006 9:23 AM, Mark Woodward wrote:
On Sat, 24 Jun 2006, Mark Woodward wrote:
I'm probably mistaken, but aren't there already forward references in
tuples to later versions? If so, I'm only sugesting reversing the
order
and referencing the lat
On 6/22/2006 2:37 PM, Alvaro Herrera wrote:
Adding back pgsql-hackers.
Mark Woodward wrote:
> Mark Woodward wrote:
>
>> Hmm, OK, then the problem is more serious than I suspected.
>> This means that every index on a row has to be updated on every
>> transaction that modifies that row. Is that
On 6/24/2006 9:23 AM, Mark Woodward wrote:
On Sat, 24 Jun 2006, Mark Woodward wrote:
I'm probably mistaken, but aren't there already forward references in
tuples to later versions? If so, I'm only sugesting reversing the order
and referencing the latest version.
I thought I understood your i
On 6/23/2006 9:56 PM, [EMAIL PROTECTED] wrote:
On Fri, Jun 23, 2006 at 03:08:34PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
> ...
> suggesting. We're having a hard enough time debugging and optimizing
> *one* storage model. I think the correct path forward is to stick with
> the same basic
On 6/23/2006 3:10 PM, Mark Woodward wrote:
This is NOT an "in-place" update. The whole MVCC strategy of keeping old
versions around doesn't change. The only thing that does change is one
level of indirection. Rather than keep references to all versions of all
rows in indexes, keep only a referen
Someone correct me if I'm wrong, but I was allways under the impression
that Oracle's ROWNUM is a thing attached to a row in the final result
set, whatever (possibly random) order that happens to have. Now a) this
is something that IMHO belongs into the client or stored procedure code,
b) if I
On 3/10/2006 10:53 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 3/8/2006 5:31 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>> > Log Message:
>> > ---
>> > Remove Christof Petig copyright on include file, per author re
missed it, but I didn't see him asking to
remove the copyright.
We certainly have copyrights attributed to individual people. Jan Wieck
has his name on the PL/Tcl and PL/pgSQL files, for example.
We should not have individual copyrights to individuals in our source
tree. If Jan's is in
On 1/27/2006 10:56 AM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I think this is unquestionably
a bug, at least for autovacuum's purposes --- though it might be OK
for the original intent of the stats system, which was simply to track
activity levels.
Any thou
On 1/27/2006 10:53 AM, Alvaro Herrera wrote:
Tom Lane wrote:
I think this is the fault of the stats system design. AFAICT from a
quick look at the code, inserted/updated/deleted tuples are reported
to the collector in the same way regardless of whether the sending
transaction committed or roll
On 1/2/2006 3:20 PM, Tom Lane wrote:
[ moving to -hackers ]
Bruce Momjian writes:
I did some research on this because the numbers Tom quotes indicate there
is something wrong in the way we process stats_command_string
statistics.
[ ... proposed patch that seems pretty klugy to me ... ]
I wo
On 12/9/2005 8:27 PM, Stephan Szabo wrote:
On Fri, 9 Dec 2005, Jan Wieck wrote:
On 12/8/2005 8:53 PM, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Yeah. I really don't understand it, but it appears to me to be explicitly
>> different in the spec
On 12/8/2005 8:53 PM, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
Yeah. I really don't understand it, but it appears to me to be explicitly
different in the spec for on delete cascade even compared to the rest of
the referential actions.
One problem I see is, what do we do if
On 12/8/2005 2:05 PM, Jim C. Nasby wrote:
On Thu, Dec 08, 2005 at 08:33:59AM -0800, Darcy Buskermolen wrote:
On Wednesday 07 December 2005 20:24, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Anyone remember this patch?
> > http://gorda.di.uminho.pt/community/pgsqlho
On 12/7/2005 11:24 PM, Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Anyone remember this patch?
http://gorda.di.uminho.pt/community/pgsqlhooks/
The discussion seems to be pretty minimal:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00859.php
Does anyone see a n
On 12/8/2005 1:28 PM, Gustavo Tonini wrote:
Are you sure that no way to implement a generic aproach on the backend? What
You mean "generic" as in a replication system that can do asynchronous
master-slave, asynchronous multimaster with conflict resolution based on
timestamps, system priority
On 12/8/2005 1:42 PM, Jim C. Nasby wrote:
On Thu, Dec 08, 2005 at 10:03:43AM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > This seems like a useful feature to add, allowing for eas
On 12/7/2005 4:50 PM, Stephan Szabo wrote:
On Wed, 7 Dec 2005, Bruce Momjian wrote:
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Would someone supply text for a TODO entry on this, as I don't think we
fixed it in 8.1.
I'd split this into two separate items n
On 12/7/2005 9:37 AM, Devrim GUNDUZ wrote:
Hi,
I'd like to inform the people who does not read Planet PostgreSQL
Command Prompt Inc.has just hired me for my community work I have been
doing so far, like PostgreSQL RPM stuff and other PostgreSQL related
RPMs, such as Slony-I, pgpool, PostGIS, e
On 12/6/2005 9:03 PM, Euler Taveira de Oliveira wrote:
Hi,
I'm doing some tests with a 700 columns' table. But when I try to load
some data with INSERT or COPY I got that message. I verified that the
BLCKZ is limiting the tuple size but I couldn't have a clue why it's
not using TOAST. I'm using
On 12/6/2005 11:23 AM, Mario Weilguni wrote:
IMO this is not true. You can get affordable 10GBit network adapters, so you
can have plenty of bandwith in a db server pool (if they are located in the
same area). Even 1GBit Ethernet greatly helps here, and would make it possible
to balance read-
On 12/6/2005 8:10 AM, Markus Schiltknecht wrote:
On Tue, 2005-12-06 at 10:03 -0200, Gustavo Tonini wrote:
But, wouldn't the performance be better? And wouldn't asynchronous
messages be better processed?
At least for synchronous multi-master replication, the performance
bottelneck is going to
On 12/5/2005 8:18 PM, Gustavo Tonini wrote:
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
We do not plan to implement replication inside the backend. Replication
needs are so diverse that pluggable replication
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
"
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value,
and a cycle o
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
"
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum value,
a minimum value,
and a cycle option. ...
"
The exact properties of a sequence. It would be a good idea to be a
On 12/3/2005 4:23 PM, Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be able to handle this:
cre
On 12/2/2005 6:19 PM, Marc G. Fournier wrote:
I haven't received any yet, that I can tell ... sure its coming through
the lists, and not around them?
Some "Tom Lane" guy and a bunch of other well known addresses sent it.
Could be forged From fields though ;-)
Jan
On Fri, 2 Dec 2005, Sim
On 11/25/2005 7:14 AM, Martijn van Oosterhout wrote:
On Thu, Nov 24, 2005 at 11:11:34AM -0500, Jan Wieck wrote:
I guess you misunderstood. [...]
But I'm not sure we're supposed to handle that case anyway. Oracle at
least doesn't require an index on the table being merged. And
On 11/24/2005 1:30 AM, Martijn van Oosterhout wrote:
On Wed, Nov 23, 2005 at 04:55:25PM -0500, Jan Wieck wrote:
The largest problem I see with MERGE is the question of BEFORE triggers.
Consider a BEFORE INSERT trigger that modifies a third table, after
which the constraint or whatever post
201 - 300 of 970 matches
Mail list logo
