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, ©buf, 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
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 |