Hi Antonin, thanks for the review.
On 2020-May-11, Antonin Houska wrote:
> While looking at the changes, I've noticed a small comment issue in the
> XLogReaderRoutine structure definition:
>
> * "tli_p" is an input/output argument. XLogRead() uses it to pass the
>
> The XLogRead() functi
Alvaro Herrera wrote:
> On 2020-May-08, Kyotaro Horiguchi wrote:
>
> > I agree to the direction of this patch. Thanks for the explanation.
> > The patch looks good to me except the two points below.
>
> Thanks! I pushed the patch.
I tried to follow the discussion but haven't had better idea.
On 2020-May-08, Kyotaro Horiguchi wrote:
> I agree to the direction of this patch. Thanks for the explanation.
> The patch looks good to me except the two points below.
Thanks! I pushed the patch. I fixed the walsender commentary as you
suggested, but I'm still of the opinion that we might want
At Thu, 7 May 2020 19:28:55 -0400, Alvaro Herrera
wrote in
> On 2020-Apr-27, Kyotaro Horiguchi wrote:
>
> > At Fri, 24 Apr 2020 11:48:46 -0400, Alvaro Herrera
> > wrote in
>
> > Sorry for the ambiguity, I didn't meant I minded that this conflicts
> > with my patch or I don't want this to be
On 2020-Apr-27, Kyotaro Horiguchi wrote:
> At Fri, 24 Apr 2020 11:48:46 -0400, Alvaro Herrera
> wrote in
> Sorry for the ambiguity, I didn't meant I minded that this conflicts
> with my patch or I don't want this to be committed. It is easily
> rebased on this patch. What I was anxious about
At Fri, 24 Apr 2020 11:48:46 -0400, Alvaro Herrera
wrote in
> On 2020-Apr-24, Kyotaro Horiguchi wrote:
>
> > At Thu, 23 Apr 2020 19:16:03 -0400, Alvaro Herrera
> > wrote in
>
> > > Here's a first attempt at that. The segment_open/close callbacks are
> > > now given at XLogReaderAllocate ti
On 2020-Apr-24, Kyotaro Horiguchi wrote:
> At Thu, 23 Apr 2020 19:16:03 -0400, Alvaro Herrera
> wrote in
> > Here's a first attempt at that. The segment_open/close callbacks are
> > now given at XLogReaderAllocate time, and are passed the XLogReaderState
> > pointer. I wrote a comment to exp
At Thu, 23 Apr 2020 19:16:03 -0400, Alvaro Herrera
wrote in
> On 2020-Apr-22, Andres Freund wrote:
>
> > I'm in favor of doing so. Not necessarily primarily to avoid repeated
> > API changes, but because I don't think the v13 changes went in the quite
> > right direction.
> >
> > ISTM that we
On 2020-Apr-22, Andres Freund wrote:
> I'm in favor of doing so. Not necessarily primarily to avoid repeated
> API changes, but because I don't think the v13 changes went in the quite
> right direction.
>
> ISTM that we should:
> - have the three callbacks you mention above
> - change WALSegmentO
On 2020-Apr-22, Andres Freund wrote:
> On 2020-04-22 13:57:54 -0400, Alvaro Herrera wrote:
> > Concretely, I propose to have a new struct like
> >
> > typedef struct xlogReaderFuncs
> > {
> > XLogPageReadCB read_page;
> > XLogSegmentOpenCB open_segment;
> > XLogSegmentCloseCB open_seg
On 2020-04-22 13:57:54 -0400, Alvaro Herrera wrote:
> Concretely, I propose to have a new struct like
>
> typedef struct xlogReaderFuncs
> {
> XLogPageReadCB read_page;
> XLogSegmentOpenCB open_segment;
> XLogSegmentCloseCB open_segment;
> } xlogReaderFuncs;
>
> #define XLOGREAD
Concretely, I propose to have a new struct like
typedef struct xlogReaderFuncs
{
XLogPageReadCB read_page;
XLogSegmentOpenCB open_segment;
XLogSegmentCloseCB open_segment;
} xlogReaderFuncs;
#define XLOGREADER_FUNCS(...) &(xlogReaderFuncs){__VA_ARGS__}
and then invoke it
On 2020-Apr-08, Antonin Houska wrote:
> Specifically for 2PC, isn't it better to close some OS-level FD of an
> unrelated table scan and then succeed than to ERROR immediately? Anyway,
> 0dc8ead46 hasn't changed this.
I think for full generality of the interface, we pass a "close" callback
in add
I have tested with and without the commit from Andres using the pgbench
script (below) provided in the initial email.
pgbench -n -s 500 -c 4 -j 4 -T 10 -P1 -f pgbench-write-2pc.sql
I am not getting the leak anymore, it seems to be holding up pretty well.
On Wed, Apr 8, 2020 at 12:59 PM Anto
Andres Freund wrote:
> On 2020-04-06 09:12:32 +0200, Antonin Houska wrote:
> > Andres Freund wrote:
> > It should have allowed users to have different ways to *locate the segment*
> > file. The WALSegmentOpen callback could actually return file path instead of
> > the file descriptor and let WAL
Antonin Houska wrote:
> Andres Freund wrote:
> > But I'm not sure it's quite the right idea. I'm not sure I fully
> > understand the design of 0dc8ead46, but it looks to me like it's
> > intended to allow users of the interface to have different ways of
> > opening files. If we just close() the
On Tue, Apr 07, 2020 at 05:12:49PM -0700, Andres Freund wrote:
> I pushed a fix. While it might not be the best medium/long term fix, it
> unbreaks 2PC. Perhaps we should add an open item to track whether we
> want to fix this differently?
Sounds fine to me. I have updated the open item that we
Hi,
I pushed a fix. While it might not be the best medium/long term fix, it
unbreaks 2PC. Perhaps we should add an open item to track whether we
want to fix this differently?
On 2020-04-06 09:12:32 +0200, Antonin Houska wrote:
> Andres Freund wrote:
> It should have allowed users to have diffe
Hi,
On 2020-04-06 09:12:32 +0200, Antonin Houska wrote:
> Andres Freund wrote:
>
> > > 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(
Andres Freund wrote:
> > 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().
>
> Yea, I came to the same conclusion and locally fixed it the
Hi,
On 2020-04-06 14:26:48 +0900, Michael Paquier wrote:
> 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
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.
Hi,
Using 2PC with master very quickly leads to:
2020-04-05 19:42:18.368 PDT [2298126][5/2009:0] LOG: out of file descriptors:
Too many open files; release and retry
2020-04-05 19:42:18.368 PDT [2298126][5/2009:0] STATEMENT: COMMIT PREPARED
'ptx_2';
This started with:
commit 0dc8ead46363fec
23 matches
Mail list logo
