Re: BUG #7914: pg_dump aborts occasionally

From: "Shin-ichi MORITA" <s-morita(at)beingcorp(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #7914: pg_dump aborts occasionally
Date: 2013-03-06 03:59:27
Message-ID: D21BF31C50304BEEB86E10C12ED7E1FE@25a038note
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>>> Hm. Can you create a reproducible test case for this?
>> I think this issue happens when pg_dump is slower than the backend
>> for some reason.
>
> If so, perhaps injecting a sleep() delay into the right place in pg_dump
> or libpq would make it reproducible? I wouldn't have any problem
> crediting a test with such modified code as being a valid test.

I think it's a good idea.
Although I can not confirm this by actually modifying the code right now,
somewhere in the loop calling PQgetCopyData() in pg_dump.c would be good.

pg_dump.c:
1348: for (;;)
1349: {
1350: ret = PQgetCopyData(conn, &copybuf, 0);
1351:
1352: if (ret < 0)
1353: break; /* done or error */
1354:
1355: if (copybuf)
1356: {
1357: WriteData(fout, copybuf, ret);
1358: PQfreemem(copybuf);
1359: }
sleep(1); /* maybe */

An alternative way would be running pg_dump with a lower priority.
Actually, I can reproduce this issue by setting the priority of
pg_dump to Low using Windows Task Manager
on the "single processor" environment.

Regards,
Shin-ichi MORITA

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message maxim.boguk 2013-03-06 09:15:01 BUG #7920: Sequence rename leave stale value for sequence_name
Previous Message adrianopatrick 2013-03-06 02:42:28 BUG #7918: limitation of pagination with LIMIT and OFFSET