>
>
>> >Do you think that it is important to do so? Are you experiencing
> problems which you believe are due to missing/out of date >activity
> statistics? Or is this more for curiosity?
> I am making specifications for a tool which captures query plan
> statistics. I wanted its behavior to be t
On Wed, Jun 26, 2013 at 2:10 PM, Jeff Janes wrote:
> On Wednesday, June 19, 2013, Sameer Thakur wrote:
>>
>> Hello,
>> I was trying to figure out how does one recover server statistics to the
>> same snapshot to which a database is restored after PITR.
>
>
> Do you think that it is important to do
On Wednesday, June 19, 2013, Sameer Thakur wrote:
> Hello,
> I was trying to figure out how does one recover server statistics to the
> same snapshot to which a database is restored after PITR.
>
Do you think that it is important to do so? Are you experiencing problems
which you believe are due
> >
> > I did the following
> > 1. Enabled archiving
> > 2. Executed SQL's 3. Shutdown 4. copied data directory (including the
> > pgstats.stat under global) and archive directory under backup/1
> > repeated 2,3,4 once more
> > So now i have 2 backup directories.
> > Now i created recovery.conf und
On Tue, Jun 25, 2013 at 11:32 PM, Sameer Thakur wrote:
>>>But, if you do PITR using the same directory (which I haven't), I
>>>think you would need to somehow replace the stats with the ones you
>>>want, may be from your backup of the same (that is, of
>>>pg_stat/*.stat), though I am not sure if t
>>But, if you do PITR using the same directory (which I haven't), I
>>think you would need to somehow replace the stats with the ones you
>>want, may be from your backup of the same (that is, of
>>pg_stat/*.stat), though I am not sure if that would be correct. I
>>doubt if WAL replay (as in a consi
On Fri, Jun 21, 2013 at 11:35 AM, Amit Langote wrote:
> On Fri, Jun 21, 2013 at 2:44 PM, Sameer Thakur
> wrote:
> >
> >> >"You need to have statistics recovered to the same state as they were
> >> >when you took the FS level backup of your database after shutting down
> >> >the server."
> >
> >
On Fri, Jun 21, 2013 at 2:44 PM, Sameer Thakur wrote:
>
>> >"You need to have statistics recovered to the same state as they were
>> >when you took the FS level backup of your database after shutting down
>> >the server."
>
> Correct
>>
>>
>> >"Shutting down" is important since that is when yo
> >"You need to have statistics recovered to the same state as they were
> >when you took the FS level backup of your database after shutting down
> >the server."
>
Correct
>
> >"Shutting down" is important since that is when you would have
> >statistics files ($PGDATA/pg_stat/*.stat) availabl
On Thu, Jun 20, 2013 at 8:32 PM, Amit Langote wrote:
> On Thu, Jun 20, 2013 at 6:05 PM, Sameer Thakur wrote:
>>>Documentation mentions following:
>> Thanks, but how does this relate to statistics recovery wrt PITR?
>
> Upon clean server shutdown, you have the statistics files stored in
> the pg_s
On Thu, Jun 20, 2013 at 6:05 PM, Sameer Thakur wrote:
>>Documentation mentions following:
> Thanks, but how does this relate to statistics recovery wrt PITR?
Upon clean server shutdown, you have the statistics files stored in
the pg_stat (previously global/) directory, which persists across
serve
>Documentation mentions following:
Thanks, but how does this relate to statistics recovery wrt PITR?
regards
Sameer
On Thu, Jun 20, 2013 at 3:17 PM, Sameer Thakur wrote:
> Hello,
> I was trying to figure out how does one recover server statistics to the
> same snapshot to which a database is restored after PITR.
> The steps i had in mind were
> 1.Set up WAL archiving
> 2.On server shutdown one would need to bac
Hello,
I was trying to figure out how does one recover server statistics to the
same snapshot to which a database is restored after PITR.
The steps i had in mind were
1.Set up WAL archiving
2.On server shutdown one would need to backup pg_stat_tmp along with file
system level back of database
3. O
14 matches
Mail list logo
