On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm not following the point here. Dump and restore has never intended
>> to preserve the transaction counter, so why should it preserve
>> high-order bit
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm not following the point here. Dump and restore has never intended
>> to preserve the transaction counter, so why should it preserve
>> high-order bits of the transaction counter?
> Thus it guarantee
On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Dropping the pg_sync_txid() would be loss, because that means that
> user cannot just dump and restore the data and just continue where
> it left off. Maybe its not a problem for replication but for gener
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Dropping the pg_sync_txid() would be loss, because that means that
> user cannot just dump and restore the data and just continue where
> it left off. Maybe its not a problem for replication but for generic
> queueing it would need delicate juggling when
On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (I wouldn't do it like this though --- TransactionIdAdvance itself is
>> the place to bump the secondary counter.)
> Agreed.
I reconsidered after trying to do it that way --- although
Marko Kreen <[EMAIL PROTECTED]> writes:
> Following patch exports 8 byte txid and snapshot to user level
> allowing its use in regular SQL. It is based on Slony-I xxid
> module. It provides special 'snapshot' type for snapshot but
> uses regular int8 for transaction ID's.
Per discussion, I've ap
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The part of this that would actually be useful to put in core is
>> maintaining a 64-bit XID counter, ie, keep an additional counter that
>> bumps every time XID wraps around. This cannot be done very well from
>> outside core but it w
On 7/27/06, Darcy Buskermolen <[EMAIL PROTECTED]> wrote:
In one of those 3am lightbulbs I belive I have a way to make use of the 64-bit
XID counter and still maintain the ability to have backwards compatibility.
Is there any chance you could break this patch up into the 2 separate
componenets tha
On Wednesday 26 July 2006 14:27, Darcy Buskermolen wrote:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we would do it. T
Alvaro Herrera wrote:
Darcy Buskermolen wrote:
I'll take a bit more of a look through the patch and see if it is a real boot
to use it on those platforms that support it, and that we have a suitable way
around it on those that don't. But at this point I wouldn't hold my breath
on that
Ühel kenal päeval, K, 2006-07-26 kell 14:27, kirjutas Darcy Buskermolen:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we
Darcy Buskermolen wrote:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we would do it. The problem ends up
> > > being Sl
On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> >> The question though is if we did that, would Slony actually use it?
> >
> > If it made sence to do it, then yes we would do it. The problem ends up
> > being Slony is designed to work across a mult
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am sure you worked hard on this, but I don't see the use case, nor
> > have I heard people in the community requesting such functionality.
> > Perhaps pgfoundry would be a better place for this.
>
> The part of this that would actu
Ühel kenal päeval, K, 2006-07-26 kell 13:35, kirjutas Bruce Momjian:
> I am sure you worked hard on this, but I don't see the use case,
The use case is any slony-like replication system or queueing system
which needs consistent means of knowing batches of transactions which
have finished during s
Ühel kenal päeval, K, 2006-07-26 kell 13:41, kirjutas Darcy Buskermolen:
> On Wednesday 26 July 2006 13:04, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I am sure you worked hard on this, but I don't see the use case, nor
> > > have I heard people in the community requesting
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
>> The question though is if we did that, would Slony actually use it?
> If it made sence to do it, then yes we would do it. The problem ends up being
> Slony is designed to work across a multitude of versions of PG, and unless
> this was backported t
On Wednesday 26 July 2006 13:04, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am sure you worked hard on this, but I don't see the use case, nor
> > have I heard people in the community requesting such functionality.
> > Perhaps pgfoundry would be a better place for this.
>
> T
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am sure you worked hard on this, but I don't see the use case, nor
> have I heard people in the community requesting such functionality.
> Perhaps pgfoundry would be a better place for this.
The part of this that would actually be useful to put in cor
I am sure you worked hard on this, but I don't see the use case, nor
have I heard people in the community requesting such functionality.
Perhaps pgfoundry would be a better place for this.
---
Marko Kreen wrote:
>
> Intro
20 matches
Mail list logo
