| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Antonin Houska <ah(at)cybertec(dot)at> |
| Subject: | Re: 2pc leaks fds |
| Date: | 2020-04-06 05:26:48 |
| Message-ID: | 20200406052648.GB2066@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Apr 05, 2020 at 07:56:51PM -0700, Andres Freund wrote:
> I found this while trying to benchmark the effect of my snapshot changes
> on 2pc. I just used the attached pgbench file.
>
> I've not yet reviewed the change sufficiently to pinpoint the issue.
Indeed. It takes seconds to show up.
> It's a bit sad that nobody has hit this in the last few months :(.
2PC shines with the code of xlogreader.c in this case because it keeps
opening and closing XLogReaderState for a short amount of time. So it
is not surprising to me to see this error only months after the fact
because recovery or pg_waldump just use one XLogReaderState. From
what I can see, the error is that the code only bothers closing
WALOpenSegment->seg when switching to a new segment, but we need also
to close it when finishing the business in XLogReaderFree().
I am adding an open item, and attached is a patch to take care of the
problem. Thoughts?
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| xlogreader-leak.patch | text/x-diff | 489 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-04-06 05:44:49 | Re: 2pc leaks fds |
| Previous Message | Fabien COELHO | 2020-04-06 05:18:10 | Re: backup manifests and contemporaneous buildfarm failures |