Ok thanks for all these precisions
Regards
Fabrice
On Tue, Dec 19, 2023 at 2:00 PM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Tue, 19 Dec 2023, 12:27 Fabrice Chapuis,
> wrote:
> >
> > Hi,
> > Is it possible to visualize the DDL with the pg_waldump tool. I created
> a postg
On Tue, 19 Dec 2023, 12:27 Fabrice Chapuis, wrote:
>
> Hi,
> Is it possible to visualize the DDL with the pg_waldump tool. I created a
> postgres user but I cannot find the creation command in the wals
Not really, no. PostgreSQL does not log DDL or DML as such in WAL.
Essentially all catalog upd
On Sat, Aug 12, 2023 at 08:15:31PM -0700, Noah Misch wrote:
> The attached 010_zero.pl, when run as part of the pg_waldump test suite, fails
> at today's master (c36b636) and v15 (1bc19df). It passes at v14 (5a32af3).
> Command "pg_waldump --start 0/0100 --end 0/01000100" fails as follows:
>
On 29.06.23 21:16, Tristen Raab wrote:
I've reviewed your latest v3 patches on Ubuntu 23.04. Both patches apply
correctly and all the tests run and pass as they should. Execution time was
normal for me, I didn't notice any significant latency when compared to other
tests. The only other feedba
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Hello,
I've reviewed your latest v3 patches on Ubuntu 23.04. Both pa
On 14.06.23 09:16, Peter Eisentraut wrote:
On 06.09.22 07:57, Peter Eisentraut wrote:
I wrote a test for coverage.
Unfortunately, it seems to take quite a while to run the test.
I want to improve these execution times, but I don't know exactly
what to do.
Therefore, I want to hear feedback fro
On 06.09.22 07:57, Peter Eisentraut wrote:
I wrote a test for coverage.
Unfortunately, it seems to take quite a while to run the test.
I want to improve these execution times, but I don't know exactly what
to do.
Therefore, I want to hear feedback from many people.
I think having some more te
Hi,
On 2022-08-23 10:50:08 +0900, Dong Wook Lee wrote:
> I wrote a test for coverage.
Unfortunately the test doesn't seem to pass on windows, and hasn't ever done so:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/39/3834
Due to the merge of the meson patchset, you should al
On 23.08.22 03:50, Dong Wook Lee wrote:
Hi Hackers,
I wrote a test for coverage.
Unfortunately, it seems to take quite a while to run the test.
I want to improve these execution times, but I don't know exactly what to do.
Therefore, I want to hear feedback from many people.
I don't find these t
On Sun, Jul 10, 2022 at 02:39:00PM -0700, Andres Freund wrote:
> On 2022-07-10 21:51:04 +0900, Dong Wook Lee wrote:
> > I don't know if this is an error.
> > when I do ./initdb -D ../data and execute pg_waldump like this, In the last
> > part I got an error.
> >
> > ```
> > ./pg_waldump ../data/p
Hi,
On 2022-07-10 21:51:04 +0900, Dong Wook Lee wrote:
> I don't know if this is an error.
> when I do ./initdb -D ../data and execute pg_waldump like this, In the last
> part I got an error.
>
> ```
> ./pg_waldump ../data/pg_wal/00010001
> ```
>
> pg_waldump: error: error in
On Wed, Dec 01, 2021 at 11:44:02AM +0530, Bharath Rupireddy wrote:
> Here's the v6 patch that has the SIGINT handling enabled for non-WIN32
> platforms (note that I haven't specified anything in the
> documentation) much like pg_receivewal and pg_recvlogical.
I have added a safeguard in XLogDumpDi
On Mon, Nov 29, 2021 at 1:16 PM Bharath Rupireddy
wrote:
>
> On Mon, Nov 29, 2021 at 11:09 AM Michael Paquier wrote:
> >
> > On Sun, Nov 28, 2021 at 12:13:08PM +0530, Bharath Rupireddy wrote:
> > > Thanks. Here's the v5.
> >
> > By the way, one thing that I completely forgot here is that SIGINT i
On Mon, Nov 29, 2021 at 11:09 AM Michael Paquier wrote:
>
> On Sun, Nov 28, 2021 at 12:13:08PM +0530, Bharath Rupireddy wrote:
> > Thanks. Here's the v5.
>
> By the way, one thing that I completely forgot here is that SIGINT is
> not handled on Windows. If we want to make that work for a WIN32
>
On Sun, Nov 28, 2021 at 12:13:08PM +0530, Bharath Rupireddy wrote:
> Thanks. Here's the v5.
By the way, one thing that I completely forgot here is that SIGINT is
not handled on Windows. If we want to make that work for a WIN32
terminal, we would need to do something similar to
src/fe_utils/cancel
On Sun, Nov 28, 2021 at 9:50 AM Michael Paquier wrote:
> v4 is just moving this paragraph in its correct subsection. My
> wording may have been confusing here, sorry about that. What I meant
> is that there is no need to mention --follow at all, as an
> interruption done before reaching the end
On Fri, Nov 26, 2021 at 03:47:30PM +0530, Bharath Rupireddy wrote:
> On Fri, Nov 26, 2021 at 11:50 AM Michael Paquier wrote:
>> +When --follow is used with --stats and
>> +the pg_waldump is terminated or interrupted
>> +with signal SIGINT or
>> SIGTERM
>> +or SIGQUIT, the summary
On Fri, Nov 26, 2021 at 11:50 AM Michael Paquier wrote:
>
> On Sat, Nov 20, 2021 at 11:46:35AM +0530, Bharath Rupireddy wrote:
> > Thanks. Here's the v3 patch, a much simpler one. Please review it.
>
> + pqsignal(SIGINT, SignalHandlerForTermination);
> + pqsignal(SIGTERM, SignalHandlerForTermi
On Sat, Nov 20, 2021 at 11:46:35AM +0530, Bharath Rupireddy wrote:
> Thanks. Here's the v3 patch, a much simpler one. Please review it.
+ pqsignal(SIGINT, SignalHandlerForTermination);
+ pqsignal(SIGTERM, SignalHandlerForTermination);
+ pqsignal(SIGQUIT, SignalHandlerForTermination);
FWIW, I
On Sat, Nov 20, 2021 at 11:10 AM Michael Paquier wrote:
> What you should do is to set such a flag in the signal handler, and
> then check its value in the main loop of pg_waldump, dumping the stats
> if it is detected as turned on because of a signal.
Thanks. Here's the v3 patch, a much simpler
On Sat, Nov 20, 2021 at 10:03:27AM +0530, Bharath Rupireddy wrote:
> Here's the v2 patch with the above changes i.e. pg_waldump now eimits
> the computed stats at the time of termination. Please review it.
+#define MAX_XLINFO_TYPES 16
+#define fatal_error(...) do { pg_log_fatal(__VA_ARGS__);
exit(
On Thu, Nov 18, 2021 at 2:03 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 18, 2021 at 1:51 PM Michael Paquier wrote:
> >
> > On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> > > Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> > > and then it should emit
On Thu, Nov 18, 2021 at 1:51 PM Michael Paquier wrote:
>
> On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> > Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> > and then it should emit the computed stats in those handlers the
> > comobinations - "-s/-f/-z
On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> and then it should emit the computed stats in those handlers the
> comobinations - "-s/-f/-z" and "-s/-e/-f/-z". I'm okay with this
> behaviour. Michael Paqui
On Thu, Nov 18, 2021 at 12:05 AM Alvaro Herrera wrote:
>
> On 2021-Nov-17, Bharath Rupireddy wrote:
>
> > On Wed, Nov 17, 2021 at 7:49 AM Michael Paquier wrote:
> > >
> > > At the same time, we could also just let things as they are. --follow
> > > and --stats being specified together is what th
On 2021-Nov-17, Bharath Rupireddy wrote:
> On Wed, Nov 17, 2021 at 7:49 AM Michael Paquier wrote:
> >
> > At the same time, we could also just let things as they are. --follow
> > and --stats being specified together is what the user looked for, so
> > they get what they wanted.
>
> I think the
On Wed, Nov 17, 2021 at 7:49 AM Michael Paquier wrote:
>
> At the same time, we could also just let things as they are. --follow
> and --stats being specified together is what the user looked for, so
> they get what they wanted.
I think the existing way of pg_waldump getting stuck with the
combi
On Tue, Nov 16, 2021 at 09:34:25AM +0530, Bharath Rupireddy wrote:
> It looks okay to be more responsive with the -f option so that the
> above commands keep emitting stats for every 1 second(the --follow
> option waits for 1 second). Should we really be emitting stats for
> every 1 second? Isn't t
On Tue, Nov 16, 2021 at 8:26 AM Michael Paquier wrote:
>
> On Mon, Nov 15, 2021 at 07:32:38PM +0530, Bharath Rupireddy wrote:
> > pg_waldump options, --follow or -f(to keep polling once per second for
> > new WAL to appear) and --stats or -z don't work well together i.e. the
> > command stucks [1]
On Mon, Nov 15, 2021 at 07:32:38PM +0530, Bharath Rupireddy wrote:
> pg_waldump options, --follow or -f(to keep polling once per second for
> new WAL to appear) and --stats or -z don't work well together i.e. the
> command stucks [1]. I think the pg_waldump should emit an error. Note
> that the pg_
On Mon, Jan 4, 2021 at 2:06 PM Peter Geoghegan wrote:
> Right. Self-consistency matters, as does consistency with the source
> code itself.
Pushed a commit that standardizes on the name latestRemovedXid within
rmgr desc output routines just now.
Thanks
--
Peter Geoghegan
On Sun, Jan 3, 2021 at 8:58 PM Masahiko Sawada wrote:
> On Mon, Jan 4, 2021 at 12:55 PM Peter Geoghegan wrote:
> +1 for changing heapdesc.c on master. It's not only readable but also
> consistent with other *desc showing the field named latestRemovedXid.
> For instance, nbtdesc.c has:
>
>
On Mon, Jan 4, 2021 at 1:12 PM Andres Freund wrote:
> I personally mildly prefer remxid - anything that is understandable but
> shortens the line length is good for my uses of waldump.
I want to use latestRemovedXid here because it is quite recognizable
to me as a symbol name. It appears as a sym
Hi,
On 2021-01-03 19:54:38 -0800, Peter Geoghegan wrote:
> I notice that heapdesc.c outputs the field latestRemovedXid as
> "remxid". But why? What sense is there in changing the name for output
> by tools like pg_waldump, which are intrinsically internals focussed?
I personally mildly prefer rem
At 2021-01-03 19:54:38 -0800, p...@bowt.ie wrote:
>
> It just seems worth removing gratuitous inconsistencies,
> such as this one.
Agreed.
-- Abhijit
On Mon, Jan 4, 2021 at 12:55 PM Peter Geoghegan wrote:
>
> I notice that heapdesc.c outputs the field latestRemovedXid as
> "remxid". But why? What sense is there in changing the name for output
> by tools like pg_waldump, which are intrinsically internals focussed?
Not sure but it has been "remx
On 12/13/20, 7:01 PM, "Michael Paquier" wrote:
> On Mon, Dec 14, 2020 at 10:26:01AM +0900, Kyotaro Horiguchi wrote:
>> Yeah, I had the same feeling. At least, the two LSNs in the message
>> under discussion are simply redundant. So +1 to just remove the LSN at
>> the caller site.
>
> That would me
On Mon, Dec 14, 2020 at 11:34:51AM +0900, Kyotaro Horiguchi wrote:
> Apart from this issue, while checking that, I noticed that if server
> starts having WALs from a server of a different systemid, the server
> stops with obscure messages.
Wouldn't it be better to discuss that on a separate thread
On Mon, Dec 14, 2020 at 10:26:01AM +0900, Kyotaro Horiguchi wrote:
> Yeah, I had the same feeling. At least, the two LSNs in the message
> under discussion are simply redundant. So +1 to just remove the LSN at
> the caller site.
That would mean that we are ready to accept that we will never forget
> At Fri, 11 Dec 2020 19:27:31 +, "Bossart, Nathan"
> wrote in
> > I looked through all the calls to report_invalid_record() in
> > xlogreader.c and noticed that all but a few in
> > XLogReaderValidatePageHeader() already report an LSN. Of the calls in
> > XLogReaderValidatePageHeader() tha
At Fri, 11 Dec 2020 19:27:31 +, "Bossart, Nathan"
wrote in
> On 12/10/20, 9:23 PM, "Michael Paquier" wrote:
> > Please note that this is documented in xlogreader.h. Hmm. I can see
> > your point here, still I think that what both of you are suggesting
> > is not completely correct. For e
On 12/10/20, 9:23 PM, "Michael Paquier" wrote:
> Please note that this is documented in xlogreader.h. Hmm. I can see
> your point here, still I think that what both of you are suggesting
> is not completely correct. For example, switching to EndRecPtr would
> cause DecodeXLogRecord() to report
At Fri, 11 Dec 2020 17:19:33 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 11 Dec 2020 14:21:57 +0900, Michael Paquier
> wrote in
> > On Fri, Dec 11, 2020 at 01:30:16PM +0900, Kyotaro Horiguchi wrote:
> > > currRecPtr is a private member of the struct (see the definition of
> > > the stru
At Fri, 11 Dec 2020 14:21:57 +0900, Michael Paquier wrote
in
> On Fri, Dec 11, 2020 at 01:30:16PM +0900, Kyotaro Horiguchi wrote:
> > currRecPtr is a private member of the struct (see the definition of
> > the struct XLogReaderState). We should instead use EndRecPtr outside
> > xlog reader.
>
On Fri, Dec 11, 2020 at 01:30:16PM +0900, Kyotaro Horiguchi wrote:
> currRecPtr is a private member of the struct (see the definition of
> the struct XLogReaderState). We should instead use EndRecPtr outside
> xlog reader.
Please note that this is documented in xlogreader.h. Hmm. I can see
your
At Thu, 10 Dec 2020 18:47:58 +, "Bossart, Nathan"
wrote in
> Hi,
>
> I noticed that when pg_waldump finds an invalid record, the
> corresponding error message seems to point to the last valid record
> read.
Good catch!
> rmgr: ... lsn: 0/090E5AF8, prev 0/090E59D0, ...
> pg_waldump
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 Wed, 30 Oct 2019 09:26:21 +0900
Michael Paquier wrote:
> On Tue, Oct 29, 2019 at 04:42:07PM -0700, Peter Geoghegan wrote:
> > The same commit from Heikki omitted one field from that record, for no
> > good reason. I backpatched a bugfix to the output format for nbtree
> > page splits a few wee
Hi,
On 2019-10-29 16:33:41 -0700, Andres Freund wrote:
> Hi,
>
> When using -b, --bkp-details pg_waldump outputs an unnecessary newline
> for blocks that contain an FPW.
>
> In --bkp-details block references are output on their own lines, like:
>
> rmgr: SPGist len (rec/tot): 4348/ 4348
On Tue, Oct 29, 2019 at 04:42:07PM -0700, Peter Geoghegan wrote:
> The same commit from Heikki omitted one field from that record, for no
> good reason. I backpatched a bugfix to the output format for nbtree
> page splits a few weeks ago, fixing that problem. I agree that we
> should also backpatch
On Tue, Oct 29, 2019 at 4:33 PM Andres Freund wrote:
> Does anybody have an opinion about fixing it just in master or also
> backpatching it? I guess there could be people having written parsers
> for the waldump output? I'm inclined to backpatch.
The same commit from Heikki omitted one field fr
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.,
82 matches
Mail list logo
