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
Jan, et. al.,
On Jan 26, 2007, at 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.
As you should be concerned. Looking on my desk through the las
"Jan Wieck" <[EMAIL PROTECTED]> writes:
> backend1: select publish_snapshot(); -- will block
>
> backend2: start transaction;
> backend2: set transaction isolation level serializable;
> backend2: select clone_snapshot(); -- will unblock backend1
It seems simpler to have a current_
On Thu, 2007-01-25 at 22:19 -0500, Jan Wieck wrote:
> The idea is to clone an existing serializable transactions snapshot
> visibility information from one backend to another. The semantics would
> be like this:
>
> backend1: start transaction;
> backend1: set transaction isolation le
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm afraid the bug has been there for ages, but the 90%-fillfactor on
rightmost page patch made it much more likely to get triggered.
But that patch has been there for ages too; the only new thing in 8.2 is
that the fillfactor is c
Hi,
Nice proposal. I'd support that enhancement and could make use of such
triggers in Postgres-R as well, at least to provide these triggers to
the user.
Jan Wieck wrote:
Good question. I don't know. I'd rather error on the safe side and make
it multiple states, for now I only have Normal a
The CONNECT BY patch from evgen potemkin has been ported to pg 8.2...
and it's now in BSD License...
I will test it on our test environement
Le jeudi 25 janvier 2007 à 11:08 +, Gregory Stark a écrit :
> Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
> it quit
Jan Wieck wrote:
But it is a datum that needs to be collected at the moment where
basically the clog entry is made ... I don't think any external module
can do that ever.
How atomic does it need to be? External modules can register callbacks
that get called right after the clog update and rem
Hi,
Jan Wieck wrote:
The replication system I have in mind will have another field type of
the balance nature, where it will never communicate the current value
but only deltas that get applied regardless of the two timestamps.
I'd favor a more generally usable conflict resolution function
i
Hi,
Alvaro Herrera wrote:
Yeah. For what I need, the launcher just needs to know when a worker
has finished and how many workers there are.
Oh, so it's not all that less communication. My replication manager also
needs to know when a worker dies. You said you are using a signal from
manager
I'd like to see still more evidence that it's a problem before we start
changing that piece of code. It has served us well for years.
Bruce Momjian wrote:
Is there a TODO here?
---
Heikki Linnakangas wrote:
Pavan Deolase
Le jeudi 25 janvier 2007 à 12:12 -0500, Gregory Stark a écrit :
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > > That's basically how the existing patch approached the problem. It
> > > invents a
> > > new type of join and a new type of tuplestore that behaves this way. This
> > > has
>
Andrew Dunstan wrote:
I am constantly running into this:
Q. Does PostgreSQL have full text indexing?
A. Yes it is in contrib.
Q. But that isn't part of core.
A. *sigh*
Where on the website can I see what "plugins" are included with
PostgreSQL?
Where on the website can I see the Official Post
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.
Furthermore, what would be the ramifications of master and slave system
times being out of sync?
Finally what if system time i
101 - 114 of 114 matches
Mail list logo
