| From: | Federico Campoli <federico(at)brandwatch(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica |
| Date: | 2013-06-04 15:36:53 |
| Message-ID: | 51AE0995.6010306@brandwatch.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 04/06/13 16:29, Andres Freund wrote:
> Hi,
>
> On 2013-06-04 16:20:12 +0100, Federico Campoli wrote:
>>> Well, if you check the output in that file you can see that 'apply' is
>>> progressing, so it's not stuck in some specific area.
>>> Is the startup process cpu bound during that time? If so, any chance to
>>> get a profile?
>>
>> Please find attached the profile file and the postgresql log generated in
>> the test run on my sandbox.
>
> Unfortunately a gprof profile isn't meaningful without the generating
> binary as far as I know. Could you either generate the callgraph or just
> generate a perf profile like:
>
> # start_test
> # perf record -a
> # ctrl-C
> # perf report > somefile
>
> And then send somefile?
>
> Greetings,
>
> Andres Freund
>
This is the gprof output for the profile.
Many thanks
Federico
--
Federico Campoli
Database Administrator brandwatch.com
| Attachment | Content-Type | Size |
|---|---|---|
| gprof_out.txt.gz | application/x-gzip | 23.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Berry | 2013-06-04 15:48:33 | Re: Segmentation Fault in Postgres server when using psqlODBC |
| Previous Message | Andres Freund | 2013-06-04 15:29:19 | Re: BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica |