Joe Conway wrote:
ivan wrote:
ok, but php should build this lang for postgres i think
so, we should talk with php group ?
I have been talking with several people about this on-and-off for a
while now. If I can find some time in the next few months, I will
probably write it (if no one beats me to
Bruce Momjian wrote:
Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code
Marcus Börger wrote:
Here's the current log while reusing the persistent connection:
DEBUG: InitPostgres
DEBUG: StartTransactionCommand
DEBUG: query: select getdatabaseencoding()
DEBUG: ProcessQuery
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: RESET ALL
DEBUG
Bruce Momjian wrote:
Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using transactions together with persistent conenctions
in a multithreaded environment
Marcus Börger wrote:
ATM i have a patch doing the following:
Connect:
If PQprotocolVersion() is available and >= 3 PQparameterStatus() is available
then i check the server version. Else i check the lib version (*).
If the version to check is >= 7.2 ido one of the following:
- If one of PQprotoc
It has been a big pleasure to me to get to know you,
and a big honor to work with you.
Do swidanie i bolshoi sbaseebo, Vadim.
Jan
--- Vadim Mikheev <[EMAIL PROTECTED]> wrote:
> FarewellIt's time for formal acknowledgement that
> I'm not in The Project any more.
>
> I'm not interested in small
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
select * from fk where not exists(select * from pk where pk.key=fk.key)
and key is not null;
(doing seq scan/subplan doing index scan - which is probably close to the
current system)
Actually, even that would probably be noticeably better
Bruce Momjian wrote:
Is there a TODO here?
Maybe!? It's one of these premature things noone can tell by now. So the
TODO would be "investigation" for now.
Jan
---
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECT
Some well known database that is very popular amongst people who care
more for their data than for license fees uses few very big files that
are statically allocated (if using files instead of raw devices).
Sure does Oracle internally maintain some sort of filesystem. But this
is more due to ot
Kurt Roeckx wrote:
On Thu, Sep 04, 2003 at 01:39:04AM -0400, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Doesn't the stats collector use unix domain sockets, not IP?
No. IIRC, we deliberately chose IP/UDP because it had buffering
behavior we liked.
Once you said it was because n
Bupp Phillips wrote:
Will this have the native Windows port?
Approximately "maybe" :-)
Jan
""Marc G. Fournier"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On Tue, 2 Sep 2003, postgresql wrote:
> Hi all
> Can anyone tell me the approximate pg 7.5 release date?
Summer of '04
Kurt Roeckx wrote:
It could be useful to have a warning at the following line:
if (memcmp(&fromaddr, &pgStatAddr, fromlen))
continue;
That way you can rule out that that is a problem.
Anyway, I still didn't see the error message he got i
Kurt Roeckx wrote:
On Thu, Sep 04, 2003 at 05:01:54PM -0400, Jan Wieck wrote:
Kurt Roeckx wrote:
>It could be useful to have a warning at the following line:
>
>if (memcmp(&fromaddr, &pgStatAddr, fromlen))
>continue;
They are both structures of type sockaddr_in (sin_family 2 is AF_INET
whereas sin_family 10 would've been AF_INET6), and all relevant fields
of the structure look the same to me. The problem lies in the padding
bytes that make sockaddr_in the same size as sockaddr.
Since the static structure pg
Redhat 7.1 says
The file descriptor sockfd must refer to a socket. If the
socket is of type SOCK_DGRAM then the serv_addr address is
the address to which datagrams are sent by default, and
the only address from which datagrams are received. If
Looks like the tes
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Redhat 7.1 says
The file descriptor sockfd must refer to a socket. If the
socket is of type SOCK_DGRAM then the serv_addr address is
the address to which datagrams are sent by default, and
the
says it limits for recv()
but we are using recvfrom() ... there might be a little difference on
that platform ...
Jan Wieck wrote:
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Redhat 7.1 says
The file descriptor sockfd must refer to a socket. If the
socket is of
Tom Lane wrote:
I was about to say "I give up, let's just take out the comparison".
Your point is interesting but easily avoided; if we aren't going to check
fromaddr anymore then there's no need to use recvfrom(), it could as
well be recv() and save the kernel a few cycles.
Which then get's us
Shridhar Daithankar wrote:
On Friday 22 August 2003 16:23, Manfred Koizar wrote:
On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>> Which leads us to a zero gravity vacuum, that does the lazy vacuum for
>> pages currently available in the buffer cache only. [.
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Shridhar Daithankar wrote:
Umm.. What does FSM does then? I was under impression that FSM stores page
pointers and vacuum work on FSM information only. In that case, it wouldn't
have to waste time to find out which pages to clean
Jan Wieck wrote:
Another way to give autovacuum some hints would be to return some number
as commandtuples from vacuum. like the number of tuples actually
vacuumed. That together with the new number of reltuples in pg_class
will tell autovacuum how frequent a relation really needs scanning
lease don't give us any vague "some other resident
process". This only indicates you don't really know what it requires for
a process to be able to read or write data in PostgreSQL.
Jan
Shridhar Daithankar wrote:
On 22 Aug 2003 at 11:03, Jan Wieck wrote:
Tom Lane wrote:
> Ja
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Okay, my proposal would be to have a VACUUM mode where it tells the
buffer manager to only return a page if it is already in memory, and
some "not cached" if it would have to read it from disk, and simply skip
the page in
Kurt Roeckx wrote:
On Tue, Sep 09, 2003 at 02:10:20AM -0700, Kevin Brown wrote:
> I could go for Jan's idea of putting a random key into the messages,
> if anyone feels that we should not trust to the kernel to enforce the
> packet source address restriction. But the memcmp() test seems a clear
Tom Lane wrote:
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
t
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.
Which style of conversion did you like? These were the choices:
3. Try to convert nonbooleans to boolean using plpgsql's
Bruce Momjian wrote:
Sounds good. I just think keywords in general are weird to use for
quoting. We use "'" for quoting, so something similar like another
operator combination would be nice. I have never been fond of the
here-document approach, though I can see the value of doing
here-documen
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Sounds good. I just think keywords in general are weird to use for
> quoting. We use "'" for quoting, so something similar like another
> operator combination would be nice. I have never been fond of the
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I made a patch to fix this, but in testing it I noticed that the stats
system doesn't work on shared tables as I was expecting it too (as my
latest patch requires it too :-). It treats instances of shared tables
in separate databas
sendmail.cf
Sean Chittenden wrote:
>> The $$FOO proposal I put forward earlier was consciously modeled on
>> here-documents.
> Couldn't we allow << at the beginning of the line to mean 'here' document?
No; you could easily be breaking existing queries, for example
Let me jump in for half a second
Can we add digits to the allowed character set of the marker? It'd make
life easier for languages that check if the quoting marker actually
occurs in the text to be quoted.
Jan
Tom Lane wrote:
Sean Chittenden <[EMAIL PROTECTED]> writes:
Using $$[.*]\n as a lexical token is a quasi-problematic
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I think calling it 'here-document' quoting is possibly unwise - it is
sufficiently different from here documents in shell and perl contexts to
make it confusing.
I agree. I've tried to think of a better alternative name, but without
m
The offending source code is in pg_dump.c line 3953, where at the lack
of an underlying conversion function and thus no clear namespace
relationship pg_dump simply ignores the cast.
IMHO a binary compatible cast should be dumped if one or both namespaces
of the underlying data types is included
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I classify this problem as a bug. Objections?
The question is not whether it is a bug, the question is what is correct
behavior instead.
Not yet, but when we have a decision and a fix it'll be the criterium
for applying it to 7.
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/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
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
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,
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
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
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: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 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 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 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
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 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
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/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 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 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 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 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
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 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.
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 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: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 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/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/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 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 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
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: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
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 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/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/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/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/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/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/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/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: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 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 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 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/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/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/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 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/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/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 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 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
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/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/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/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/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/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 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/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 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/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/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 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 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 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
501 - 600 of 970 matches
Mail list logo
