| From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
|---|---|
| To: | "Daniel Fink (PDF)" <daniel(dot)fink(at)pdf(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_wal fills up on big update query |
| Date: | 2019-08-07 14:34:55 |
| Message-ID: | CAKoxK+4MoyYoFggQAok=AR2_+riv_yTFes1oAqLD_5FA3KZhVA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Aug 7, 2019 at 3:34 PM Daniel Fink (PDF) <daniel(dot)fink(at)pdf(dot)com> wrote:
> My current idea is to lock both tables completely from access (the queried and the updated one) so that postgresql does not have to ensure isolation for concurrent queries by keeping a copy of each row.
I'm not sure that locking will prevent the snapshotting and the WAL
machinery, but someone more expert on the are could clarify this.
Since the column is nullable, I would apply it outside of the
transaction, and then do the update. If that still fails, I would try
to split the update on small chunks (after all, it's an update, so it
is smething you can line up data).
Luca
| From | Date | Subject | |
|---|---|---|---|
| Next Message | stan | 2019-08-07 18:07:17 | Input validation |
| Previous Message | Rob Sargent | 2019-08-07 14:22:06 | Re: pg_wal fills up on big update query |