Jim Nasby wrote:
> On 6/14/15 9:50 AM, Alvaro Herrera wrote:
> >+values[0] = MultiXactState->oldestMultiXactId;
>
> What about oldestOffset and offsetStopLimit? Seems those would be useful
> too. Looks good other than that.
Yeah, that's what I was trying to say. How about this?
I realized t
On 6/14/15 9:50 AM, Alvaro Herrera wrote:
+ values[0] = MultiXactState->oldestMultiXactId;
What about oldestOffset and offsetStopLimit? Seems those would be useful
too. Looks good other than that.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in
Josh Berkus wrote:
>
> > You can see the current multixact value in pg_controldata output. Keep
> > timestamped values of that somewhere (a table?) so that you can measure
> > consumption rate. I don't think we provide SQL-level access to those
> > values.
>
> Bleh. Do we provide SQL-level acc
On Fri, Sep 5, 2014 at 07:39:36PM -0400, Bruce Momjian wrote:
> On Wed, Sep 3, 2014 at 05:17:17PM -0400, Robert Haas wrote:
> > > I had a look at this and came upon a problem --- there is no multi-xid
> > > SQL data type, and in fact the system catalogs that store mxid values
> > > use xid, e.g.:
On Wed, Sep 3, 2014 at 05:17:17PM -0400, Robert Haas wrote:
> > I had a look at this and came upon a problem --- there is no multi-xid
> > SQL data type, and in fact the system catalogs that store mxid values
> > use xid, e.g.:
> >
> > relminmxid | xid | not null
> >
> > With no
On Tue, Sep 2, 2014 at 8:18 PM, Bruce Momjian wrote:
> On Thu, Aug 28, 2014 at 09:32:17AM -0700, Josh Berkus wrote:
>> On 08/28/2014 09:09 AM, Alvaro Herrera wrote:
>> > Josh Berkus wrote:
>> >> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
>> >>> Josh Berkus wrote:
>>
>> > You can see th
On Thu, Aug 28, 2014 at 09:32:17AM -0700, Josh Berkus wrote:
> On 08/28/2014 09:09 AM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
> >>> Josh Berkus wrote:
>
> > You can see the current multixact value in pg_controldata output. Keep
> >>
On 08/28/2014 09:09 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
>>> Josh Berkus wrote:
> You can see the current multixact value in pg_controldata output. Keep
> timestamped values of that somewhere (a table?) so that you can measure
Josh Berkus wrote:
> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >>
> >>> You can see the current multixact value in pg_controldata output. Keep
> >>> timestamped values of that somewhere (a table?) so that you can measure
> >>> consumption rate. I don't think we provid
On Wed, Apr 16, 2014 at 4:39 PM, Josh Berkus wrote:
>> Hmm, are you sure it's INT_MAX and not 4244967297? Heikki reported
>> that: http://www.postgresql.org/message-id/52401aea.9000...@vmware.com
>> The absolute value is not important; I think that's mostly harmless. I
>> don't think applying ag
>> So if age() doesn't mean anything, then how are users to know when the
>> need to freeze?
>
> I don't understand. Autovacuum will freeze this automatically when the
> threshold is reached. Users don't need to do anything.
What I'm asking is:
- how do users know if Autovacuum is keeping up
Josh Berkus wrote:
> > Josh Berkus wrote:
> >>
> >>> You can see the current multixact value in pg_controldata output. Keep
> >>> timestamped values of that somewhere (a table?) so that you can measure
> >>> consumption rate. I don't think we provide SQL-level access to those
> >>> values.
> >>
On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>>
>>> You can see the current multixact value in pg_controldata output. Keep
>>> timestamped values of that somewhere (a table?) so that you can measure
>>> consumption rate. I don't think we provide SQL-level access to those
>>>
Josh Berkus wrote:
>
> > You can see the current multixact value in pg_controldata output. Keep
> > timestamped values of that somewhere (a table?) so that you can measure
> > consumption rate. I don't think we provide SQL-level access to those
> > values.
>
> Bleh. Do we provide SQL-level acc
> You can see the current multixact value in pg_controldata output. Keep
> timestamped values of that somewhere (a table?) so that you can measure
> consumption rate. I don't think we provide SQL-level access to those
> values.
Bleh. Do we provide SQL-level access in 9.4? If not, I think that
Josh Berkus wrote:
> On 04/15/2014 02:25 PM, Josh Berkus wrote:
> > Hackers,
> >
> > We need documentation on how users should intelligently set the
> > multixact freeze settings. I'm happy to write the actual text, but I
> > definitely don't have any idea how to set these myself. Under what
> >
On 04/15/2014 02:25 PM, Josh Berkus wrote:
> Hackers,
>
> We need documentation on how users should intelligently set the
> multixact freeze settings. I'm happy to write the actual text, but I
> definitely don't have any idea how to set these myself. Under what
> circumstances should they be dif
Hackers,
We need documentation on how users should intelligently set the
multixact freeze settings. I'm happy to write the actual text, but I
definitely don't have any idea how to set these myself. Under what
circumstances should they be different from freeze_max_age? How?
--
Josh Berkus
Post
18 matches
Mail list logo
