Jeff Davis wrote:
On Wed, 2007-06-06 at 22:36 +0100, Simon Riggs wrote:
.) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
is considered to be "later" than any other xid.
So you are bumping FirstNormalTransactionId up by one for this?
You're assuming then that we will
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
Jeff Davis wrote:
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
similar?
Simon Riggs wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Added a new GUC operational_mode, which can be set to either
readwrite or readonly. If it is set to readwrite (the default),
postgres behaves as usual. All the following changes are only
in effect if op
Florian G. Pflug wrote:
Jeff Davis wrote:
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
similar?
Thats what I currently do
On Wed, 2007-06-06 at 22:36 +0100, Simon Riggs wrote:
> > .) Transactions are assigned a dummy xid ReadOnlyTransactionId, that
> > is considered to be "later" than any other xid.
>
> So you are bumping FirstNormalTransactionId up by one for this?
>
> You're assuming then that we will "free
Alvaro Herrera wrote:
Simon Riggs wrote:
On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if
On Wed, 2007-06-06 at 17:14 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
> > > Florian G. Pflug wrote:
> > > > Work done so far:
> > > > -
> > > > .) Don't start autovacuum and bgwriter.
> > >
> > > Do table s
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
> .) Added a new GUC operational_mode, which can be set to either
> readwrite or readonly. If it is set to readwrite (the default),
> postgres behaves as usual. All the following changes are only
> in effect if operational_mode
Simon Riggs wrote:
> On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
> > Florian G. Pflug wrote:
> > > Work done so far:
> > > -
> > > .) Don't start autovacuum and bgwriter.
> >
> > Do table stats used by the planner get replicated on a PITR slave? I
> > assume s
On Wed, 2007-06-06 at 12:17 -0400, Matthew T. O'Connor wrote:
> Florian G. Pflug wrote:
> > Work done so far:
> > -
> > .) Don't start autovacuum and bgwriter.
>
> Do table stats used by the planner get replicated on a PITR slave? I
> assume so, but if not, you would need autov
On Wed, 2007-06-06 at 19:25 +0200, Florian G. Pflug wrote:
> Thats what I currently do - the xip array on the slave is sized to
> hold max_connections entries (Actually, it's max_connections +
> max_prepared_xacts I think). The problem occurs exactly if those
> values are set too small on the slave
Jeff Davis wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Since the slaves needs to track an Snapshot in shared memory, it cannot
resize that snapshot to accomodate however many concurrent transactions
might have been running on the master. My current plan is
Matthew T. O'Connor wrote:
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if not, you would need autovac to do analyzes.
Yes - everything that get wal-
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
>.) Since the slaves needs to track an Snapshot in shared memory, it cannot
> resize that snapshot to accomodate however many concurrent transactions
> might have been running on the master. My current plan is to detect if
>
Florian G. Pflug wrote:
Work done so far:
-
.) Don't start autovacuum and bgwriter.
Do table stats used by the planner get replicated on a PITR slave? I
assume so, but if not, you would need autovac to do analyzes.
---(end of broadcast)-
Hi
This is a description of the GSoC work I've so for on readonly
support for PITR slaves. I'm looking for any kind of comments
on this - I want to make sure that I work in a direction that
the community approves.
Work done so far:
-
.) Added a new GUC operational_mode, which can
16 matches
Mail list logo
