From: | "Daniel Fink (PDF)" <daniel(dot)fink(at)pdf(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | pg_wal fills up on big update query |
Date: | 2019-08-07 13:34:39 |
Message-ID: | 4b0d1ee711c4079c0544216bb2bdff4b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi all,
I have a migration where I
· Add a new nullable column to a table
· update almost every row in this big table (8 million rows) from
another table where I set this new column
I have also a replication setup running.
The database has a size of around 20GB.
While the migration is running, it more than doubles is size and fills up
all space.
Then the migration fails and is rolled back.
What is the best way of keeping this from happening?
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.
Is my thinking here correct?
Thanks in advance and Best Regards,
Daniel
--
This message may contain confidential and privileged information. If it has
been sent to you in error, please reply to advise the sender of the error
and then immediately permanently delete it and all attachments to it from
your systems. If you are not the intended recipient, do not read, copy,
disclose or otherwise use this message or any attachments to it. The sender
disclaims any liability for such unauthorized use. PLEASE NOTE that all
incoming e-mails sent to PDF e-mail accounts will be archived and may be
scanned by us and/or by external service providers to detect and prevent
threats to our systems, investigate illegal or inappropriate behavior,
and/or eliminate unsolicited promotional e-mails (“spam”). If you have any
concerns about this process, please contact us at legal(dot)department(at)pdf(dot)com
<mailto:legal(dot)department(at)pdf(dot)com>.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2019-08-07 14:19:49 | Re: Why must AUTOCOMMIT be ON to do txn control in plpgsql procedure? |
Previous Message | Laura Smith | 2019-08-07 09:36:26 | Re: Guidance needed on an alternative take on common prefix SQL |