On Wed, Nov 20, 2019 at 04:16:45PM +0900, btkimurayuzk wrote:
> typedef struct xl_xact_relfilenodes
> {
> - int nrels; /* number of
> subtransaction XIDs */
> + int nrels; /* number of relations
> */
> RelFi
I did not see any problems in this version of the patch. The
information
displayed by pg_waldump for the PREPARE record is sufficient for use.
Thanks Andrey and Michael for the review! I committed the patch.
Regards,
Hi,
There is a mistake in the comment in the definition of
xl_xact_relfil
On Wed, Nov 13, 2019 at 3:53 PM Andrey Lepikhov
wrote:
>
>
>
> 12.11.2019 12:41, Fujii Masao пишет:
> > Ok, I changed the patch that way.
> > Attached is the latest version of the patch.
> >
> > Regards,
>
> I did not see any problems in this version of the patch. The information
> displayed by pg
12.11.2019 12:41, Fujii Masao пишет:
Ok, I changed the patch that way.
Attached is the latest version of the patch.
Regards,
I did not see any problems in this version of the patch. The information
displayed by pg_waldump for the PREPARE record is sufficient for use.
--
Andrey Lepikhov
P
On Tue, Nov 12, 2019 at 06:41:12PM +0900, Fujii Masao wrote:
> Ok, I changed the patch that way.
> Attached is the latest version of the patch.
Thanks for the new patch. Looks fine to me.
--
Michael
signature.asc
Description: PGP signature
On Tue, Nov 12, 2019 at 6:03 PM Michael Paquier wrote:
>
> On Tue, Nov 12, 2019 at 05:53:02PM +0900, Fujii Masao wrote:
> > Thanks for the review! But probably I failed to understand your point...
> > Could you clarify what actual change is necessary? You are thinking that
> > the check of "parsed
On Tue, Nov 12, 2019 at 05:53:02PM +0900, Fujii Masao wrote:
> Thanks for the review! But probably I failed to understand your point...
> Could you clarify what actual change is necessary? You are thinking that
> the check of "parsed.nmsgs >= 0" should be moved to the inside of
> standby_desc_inval
On Mon, Nov 11, 2019 at 4:16 PM Michael Paquier wrote:
>
> On Mon, Nov 11, 2019 at 01:21:28PM +0900, Fujii Masao wrote:
> > Thanks for the review! You are right.
> > I fixed this issue in the attached patch.
>
> The proposed format looks fine to me. I have just one comment. All
> three callers o
On Mon, Nov 11, 2019 at 01:21:28PM +0900, Fujii Masao wrote:
> Thanks for the review! You are right.
> I fixed this issue in the attached patch.
The proposed format looks fine to me. I have just one comment. All
three callers of standby_desc_invalidations() don't actually need to
print any data
On Fri, Nov 8, 2019 at 1:33 PM Andrey Lepikhov
wrote:
>
>
>
> On 08/11/2019 09:26, Kyotaro Horiguchi wrote:
> > Hello.
> >
> > At Fri, 8 Nov 2019 08:23:41 +0500, Andrey Lepikhov
> > wrote in
> >>> Can I switch the status back to "Needs review"?
> >>> Regards,
> >>>
> >>
> >> One issue is that yo
On 08/11/2019 09:26, Kyotaro Horiguchi wrote:
Hello.
At Fri, 8 Nov 2019 08:23:41 +0500, Andrey Lepikhov
wrote in
Can I switch the status back to "Needs review"?
Regards,
One issue is that your patch provides small information. WAL errors
Investigation often requires information on xid,
Hello.
At Fri, 8 Nov 2019 08:23:41 +0500, Andrey Lepikhov
wrote in
> > Can I switch the status back to "Needs review"?
> > Regards,
> >
>
> One issue is that your patch provides small information. WAL errors
> Investigation often requires information on xid, subxacts,
> delete-on-abort/commit
At Fri, 8 Nov 2019 09:53:07 +0900, Fujii Masao wrote in
> On Fri, Nov 8, 2019 at 9:41 AM Michael Paquier wrote:
> >
> > On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
> > > Sorry for the long delay... Yes, I will update the patch if necessary.
> >
> > Fujii-san, are you planning to
On 08/11/2019 05:53, Fujii Masao wrote:
On Fri, Nov 8, 2019 at 9:41 AM Michael Paquier wrote:
On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
Sorry for the long delay... Yes, I will update the patch if necessary.
Fujii-san, are you planning to update this patch then? I have
On Fri, Nov 8, 2019 at 9:41 AM Michael Paquier wrote:
>
> On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
> > Sorry for the long delay... Yes, I will update the patch if necessary.
>
> Fujii-san, are you planning to update this patch then? I have
> switched it as waiting on author.
On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
> Sorry for the long delay... Yes, I will update the patch if necessary.
Fujii-san, are you planning to update this patch then? I have
switched it as waiting on author.
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 3, 2019 at 3:04 AM Alvaro Herrera wrote:
>
> On 2019-Aug-01, Michael Paquier wrote:
>
> > I may be missing something of course, but in this case we argued about
> > adding a couple of more fields. In consequence, the patch should be
> > waiting on its author, no?
>
> Fujii,
>
> Are yo
Sorry for the long delay...
On Thu, Jul 4, 2019 at 5:25 PM Julien Rouhaud wrote:
>
> On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
> >
> > On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > > So the patch compiles and works as intended. I don't have much to say
> > > abo
On 2019-Aug-01, Michael Paquier wrote:
> I may be missing something of course, but in this case we argued about
> adding a couple of more fields. In consequence, the patch should be
> waiting on its author, no?
Fujii,
Are you in a position to submit an updated version of this patch?
Maybe Vign
On Thu, Aug 1, 2019 at 11:51 PM Michael Paquier wrote:
> On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> > I've moved this to the next CF, and set it to "Needs review" since a
> > rebase was provided.
>
> I may be missing something of course, but in this case we argued about
> addi
Hi,
Le jeu. 1 août 2019 à 13:51, Michael Paquier a écrit :
> On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> > I've moved this to the next CF, and set it to "Needs review" since a
> > rebase was provided.
>
> I may be missing something of course, but in this case we argued about
On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> I've moved this to the next CF, and set it to "Needs review" since a
> rebase was provided.
I may be missing something of course, but in this case we argued about
adding a couple of more fields. In consequence, the patch should be
wa
On Thu, Jul 4, 2019 at 8:25 PM Julien Rouhaud wrote:
> On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
> > On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > > So the patch compiles and works as intended. I don't have much to say
> > > about it, it all looks good to me, sin
On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
>
> On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > So the patch compiles and works as intended. I don't have much to say
> > about it, it all looks good to me, since the concerns about xactdesc.c
> > aren't worth the troubl
On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> So the patch compiles and works as intended. I don't have much to say
> about it, it all looks good to me, since the concerns about xactdesc.c
> aren't worth the trouble.
>
> I'm not sure that I understand Michael's objection though
On Wed, Jul 3, 2019 at 5:21 PM Fujii Masao wrote:
>
> On Tue, Jul 2, 2019 at 7:16 PM Julien Rouhaud wrote:
> >
> > On Fri, Apr 26, 2019 at 5:38 AM Michael Paquier wrote:
> > >
> > > On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> > > > On 2019-Apr-26, Fujii Masao wrote:
> > > >
On Tue, Jul 2, 2019 at 7:16 PM Julien Rouhaud wrote:
>
> On Fri, Apr 26, 2019 at 5:38 AM Michael Paquier wrote:
> >
> > On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> > > On 2019-Apr-26, Fujii Masao wrote:
> > >> I did that arrangement because the format of PREPARE TRANSACTION
On Fri, Apr 26, 2019 at 5:38 AM Michael Paquier wrote:
>
> On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> > On 2019-Apr-26, Fujii Masao wrote:
> >> I did that arrangement because the format of PREPARE TRANSACTION record,
> >> i.e., that struct, also needs to be accessed in backe
On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> On 2019-Apr-26, Fujii Masao wrote:
>> I did that arrangement because the format of PREPARE TRANSACTION record,
>> i.e., that struct, also needs to be accessed in backend and frontend.
>> But, of course, if there is smarter way, I'm h
On 2019-Apr-26, Fujii Masao wrote:
> On Fri, Apr 26, 2019 at 1:04 AM Alvaro Herrera
> wrote:
> > I also wonder if
> > defining the structs in the way you do is the most sensible arrangement.
>
> I did that arrangement because the format of PREPARE TRANSACTION record,
> i.e., that struct, also
On Fri, Apr 26, 2019 at 1:04 AM Alvaro Herrera wrote:
>
> On 2019-Apr-26, Fujii Masao wrote:
>
> > Hi,
> >
> > pg_waldump report no detail information about PREPARE TRANSACTION record,
> > as follows.
> >
> > rmgr: Transaction len (rec/tot):250/ 250, tx:485,
> > lsn: 0/02A8,
On 2019-Apr-26, Fujii Masao wrote:
> Hi,
>
> pg_waldump report no detail information about PREPARE TRANSACTION record,
> as follows.
>
> rmgr: Transaction len (rec/tot):250/ 250, tx:485,
> lsn: 0/02A8, prev 0/0260, desc: PREPARE
>
> I'd like to modify pg_waldump, i.e.,
Hi,
pg_waldump report no detail information about PREPARE TRANSACTION record,
as follows.
rmgr: Transaction len (rec/tot):250/ 250, tx:485,
lsn: 0/02A8, prev 0/0260, desc: PREPARE
I'd like to modify pg_waldump, i.e., xact_desc(), so that it reports
detail information li
33 matches
Mail list logo
