On Thu, 2008-10-23 at 13:40 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The patch isn't ready to apply standalone because we need to include the
> > changes to XidInMVCCSnapshot() also, which would take a little while to
> > extract. Let me know if that is worth producing a standalon
Simon Riggs wrote:
The patch isn't ready to apply standalone because we need to include the
changes to XidInMVCCSnapshot() also, which would take a little while to
extract. Let me know if that is worth producing a standalone patch for.
FWIW, this patch becomes a lot simpler if you don't change
On Thu, 2008-10-23 at 08:40 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2008-10-22 at 21:47 +0100, Simon Riggs wrote:
> >
> >> But once you reach 64 transactions, you'll need to write an extra WAL
> >> record for every subtransaction, which currently I've managed to avoid.
>
Simon Riggs wrote:
On Wed, 2008-10-22 at 21:47 +0100, Simon Riggs wrote:
But once you reach 64 transactions, you'll need to write an extra WAL
record for every subtransaction, which currently I've managed to avoid.
Yes, I've managed to avoid it, but it will simplify the patch if you
think its
On Wed, 2008-10-22 at 21:47 +0100, Simon Riggs wrote:
> But once you reach 64 transactions, you'll need to write an extra WAL
> record for every subtransaction, which currently I've managed to avoid.
Some further notes/tests on the optimisation you discovered.
Because of the way I have changed
On Wed, 2008-10-22 at 21:47 +0100, Simon Riggs wrote:
> But once you reach 64 transactions, you'll need to write an extra WAL
> record for every subtransaction, which currently I've managed to avoid.
Yes, I've managed to avoid it, but it will simplify the patch if you
think its not worth botheri
On Wed, 2008-10-22 at 22:38 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > If you don't mark subtrans, you will need to keep things in shared
> > memory. I agree you can defer marking subtrans until your shared memory
> > fills, but you will still need to keep track of the parent for ea
Simon Riggs wrote:
If you don't mark subtrans, you will need to keep things in shared
memory. I agree you can defer marking subtrans until your shared memory
fills, but you will still need to keep track of the parent for each
subtransaction until you do. If you don't *know* the parent, how will
y
On Wed, 2008-10-22 at 20:42 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2008-10-22 at 17:18 +0300, Heikki Linnakangas wrote:
> >
> >> It doesn't need to be in subtrans before it appears on
> >> disk, AFAICS.
> >
> > I don't make these rules. Read comments in AssignTransact
Simon Riggs wrote:
On Wed, 2008-10-22 at 17:18 +0300, Heikki Linnakangas wrote:
It doesn't need to be in subtrans before it appears on
disk, AFAICS.
I don't make these rules. Read comments in AssignTransactionId().
You mean this one:
/*
* Generate a new Xid and record it
On Wed, 2008-10-22 at 17:40 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > If that makes snapshot overflow,
> > we have a big problem: we would be forced to say "sorry snapshot cannot
> > be issued at this time, please wait". Ugh!
>
> BTW, we'll need to do that anyway, if we guess the
On Wed, 2008-10-22 at 17:29 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > You may be missing my point.
> >
> > We need an initial state to work from.
> >
> > I am proposing we write a full snapshot after each checkpoint because it
> > allows us to start recovery again from that poin
Simon Riggs wrote:
If that makes snapshot overflow,
we have a big problem: we would be forced to say "sorry snapshot cannot
be issued at this time, please wait". Ugh!
BTW, we'll need to do that anyway, if we guess the max_connections
setting in the master incorrectly. We should avoid having to
On Wed, 2008-10-22 at 17:18 +0300, Heikki Linnakangas wrote:
> The list of xids in a snapshot is just a palloc'd array, in
> backend-local memory, so we can easily make it as large as we need to.
It's malloc'd before we hold the lock. Yes, we can make it as large as
we need to, but that would ch
Hannu Krosing wrote:
On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
Also, I can't help thinking that this would be a lot simpler if we just
treated all subtransactions the same as top-level transactions. The only
problem with that is that there can be a lot of subtransactions, whi
On Wed, 2008-10-22 at 17:18 +0300, Heikki Linnakangas wrote:
> It doesn't need to be in subtrans before it appears on
> disk, AFAICS.
I don't make these rules. Read comments in AssignTransactionId().
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Simon Riggs wrote:
On Wed, 2008-10-22 at 12:29 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
* The backend slot may not be reused for some time, so we should take
additional actions to keep state current and
Simon Riggs wrote:
On Wed, 2008-10-22 at 12:29 +0300, Heikki Linnakangas wrote:
How about:
1. Keep all transactions and subtransactions in UnobservedXids.
2. If it fills up, remove all subtransactions from it, that the startup
process knows to be subtransactions and knows the parents, and upd
On Wed, 2008-10-22 at 12:29 +0300, Heikki Linnakangas wrote:
> How about:
>
> 1. Keep all transactions and subtransactions in UnobservedXids.
> 2. If it fills up, remove all subtransactions from it, that the startup
> process knows to be subtransactions and knows the parents, and update
> subt
On Wed, 2008-10-22 at 12:29 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> * The backend slot may not be reused for some time, so we should take
> >>> additional actions to keep state current and
On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
>
> Also, I can't help thinking that this would be a lot simpler if we just
> treated all subtransactions the same as top-level transactions. The only
> problem with that is that there can be a lot of subtransactions, which
> means tha
Simon Riggs wrote:
On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
* The backend slot may not be reused for some time, so we should take
additional actions to keep state current and true. So we choose to log a
snapshot from the master into WAL after each checkpoi
On Thu, 2008-10-16 at 18:52 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Each backend that existed on the master is represented by a PROC
> > structure in the ProcArray. These are known as "recovery procs" and are
> > similar to the dummy procs used for prepared transactions. All reco
Simon Riggs wrote:
Each backend that existed on the master is represented by a PROC
structure in the ProcArray. These are known as "recovery procs" and are
similar to the dummy procs used for prepared transactions. All recovery
procs are "owned by" the Startup process. So there is no process for
On Thu, 2008-10-16 at 15:20 +0100, Simon Riggs wrote:
> I've integrated my five patches together into one now:
> * recovery_infrastruc.v9.patch
> * atomic_subxids.v7.patch
> * hs_connect
> * hs_checks
> * hs_snapshot
>
> Seems positive that it all integrated so quickly and tests OK.
> More later
On Thu, 2008-10-16 at 13:55 +0100, Simon Riggs wrote:
> Other related patches are
> * recovery_infrastruc.v9.patch
> * atomic_subxids.v7.patch
> They don't all apply cleanly together, but the changes are unrelated, so
> those patches can still be reviewed without wasting energy.
>
> Next phase i
On Wed, 2008-10-15 at 12:58 -0700, Jeff Davis wrote:
> On Tue, 2008-10-14 at 18:50 +0100, Simon Riggs wrote:
> > I've worked out what I think is a workable, efficient process for
> > deriving snapshots during recovery. I will be posting a patch to show
> > how this works tomorrow [Wed 15 Oct], jus
On Tue, 2008-10-14 at 18:50 +0100, Simon Riggs wrote:
> I've worked out what I think is a workable, efficient process for
> deriving snapshots during recovery. I will be posting a patch to show
> how this works tomorrow [Wed 15 Oct], just doing cleanup now.
How will this interact with an idea like
I've worked out what I think is a workable, efficient process for
deriving snapshots during recovery. I will be posting a patch to show
how this works tomorrow [Wed 15 Oct], just doing cleanup now.
Recovery Snapshots are snapshots taken during recovery. They are valid
snapshots in all ways for tes
29 matches
Mail list logo
