From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: WAL prefetch (another approach) |
Date: | 2020-09-01 14:18:26 |
Message-ID: | 20200901141826.gbhqz664brtt4y2t@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 02, 2020 at 02:05:10AM +1200, Thomas Munro wrote:
>On Wed, Sep 2, 2020 at 1:14 AM Tomas Vondra
><tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> from the archive
>
>Ahh, so perhaps that's the key.
>
Maybe. For the record, the commands look like this:
archive_command = 'gzip -1 -c %p > /mnt/raid/wal-archive/%f.gz'
restore_command = 'gunzip -c /mnt/raid/wal-archive/%f.gz > %p.tmp && mv %p.tmp %p'
>> I've tested this applied on 6ca547cf75ef6e922476c51a3fb5e253eef5f1b6,
>> and the failure seems fairly similar to what I reported before, except
>> that now it happened right at the very beginning.
>
>Thanks, will see if I can work out why. My newer version probably has
>the same problem.
OK.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-09-01 15:03:07 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
Previous Message | Thomas Munro | 2020-09-01 14:05:10 | Re: WIP: WAL prefetch (another approach) |