On Mon, Apr 11, 2022 at 6:33 PM Bharath Rupireddy
wrote:
>
> On Mon, Apr 11, 2022 at 4:21 PM Amit Kapila wrote:
> >
> > On Thu, Apr 7, 2022 at 3:35 PM Bharath Rupireddy
> > wrote:
> > >
> >
> > I am facing the below doc build failure on my machine due to this work:
> >
> > ./filelist.sgml:
> >
On Mon, Apr 11, 2022 at 4:21 PM Amit Kapila wrote:
>
> On Thu, Apr 7, 2022 at 3:35 PM Bharath Rupireddy
> wrote:
> >
>
> I am facing the below doc build failure on my machine due to this work:
>
> ./filelist.sgml:
> Tabs appear in SGML/XML files
> make: *** [check-tabs] Error 1
>
> The attached
On Thu, Apr 7, 2022 at 3:35 PM Bharath Rupireddy
wrote:
>
I am facing the below doc build failure on my machine due to this work:
./filelist.sgml:
Tabs appear in SGML/XML files
make: *** [check-tabs] Error 1
The attached patch fixes this for me.
--
With Regards,
Amit Kapila.
On Wed, Apr 6, 2022 at 2:15 PM Bharath Rupireddy
wrote:
>
> Attaching v17 patch-set with the above review comments addressed.
> Please have a look at it.
Had to rebase because of 5c279a6d350 (Custom WAL Resource Managers.).
Please find v18 patch-set.
Regards,
Bharath Rupireddy.
From
On Wed, Apr 6, 2022 at 10:32 AM Jeff Davis wrote:
>
> On Mon, 2022-04-04 at 09:15 +0530, Bharath Rupireddy wrote:
> > My intention is to return the overall undecoded WAL record [5] i.e.
> > the data starting from XLogReadRecord's output [6] till length
> > XLogRecGetTotalLen(xlogreader);. Please
On Mon, 2022-04-04 at 09:15 +0530, Bharath Rupireddy wrote:
> My intention is to return the overall undecoded WAL record [5] i.e.
> the data starting from XLogReadRecord's output [6] till length
> XLogRecGetTotalLen(xlogreader);. Please see [7], where Andres agreed
> to have this function, I also
On Sat, Apr 2, 2022 at 5:05 AM Jeff Davis wrote:
>
> On Sat, 2022-03-26 at 10:31 +0530, Bharath Rupireddy wrote:
> > Attaching v16 patch-set, only change in v16-0002-pg_walinspect.patch,
> > others remain the same.
>
> I looked more closely at this patch.
Thanks Jeff for reviewing this.
> * It
Hi,
On 2022-04-01 16:35:38 -0700, Jeff Davis wrote:
> * I don't think we need the stats at all. We can run GROUP BY queries
> on the results of pg_get_wal_records_info().
It's well over an order of magnitude slower. And I don't see how that can be
avoided. That makes it practically useless.
See
On Sat, 2022-03-26 at 10:31 +0530, Bharath Rupireddy wrote:
> Attaching v16 patch-set, only change in v16-0002-pg_walinspect.patch,
> others remain the same.
I looked more closely at this patch.
* It seems that pg_get_wal_record() is not returning the correct raw
data for the record. I tested
On Fri, Mar 25, 2022 at 8:37 PM RKN Sai Krishna
wrote:
>
> Hi Bharath,
>
> First look at the patch, bear with me if any of the following comments are
> repeated.
Thanks RKN, for playing around with the patches.
> 1. With pg_get_wal_record(lsn), say a WAL record start, end lsn range
> contains
Hi Bharath,
First look at the patch, bear with me if any of the following comments are
repeated.
1. With pg_get_wal_record(lsn), say a WAL record start, end lsn range
contains the specified LSN, wouldn't it be more meaningful to show the
corresponding WAL record.
For example, upon providing
On Fri, Mar 25, 2022 at 12:18 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-03-24 15:02:29 +0530, Bharath Rupireddy wrote:
> > On Thu, Mar 24, 2022 at 10:22 AM Kyotaro Horiguchi
> > > This doesn't seem to be a part of xlogreader. Couldn't we add a new
> > > module "xlogstats"?
Hi,
On 2022-03-24 15:02:29 +0530, Bharath Rupireddy wrote:
> On Thu, Mar 24, 2022 at 10:22 AM Kyotaro Horiguchi
> > This doesn't seem to be a part of xlogreader. Couldn't we add a new
> > module "xlogstats"? XLogRecGetBlockRefInfo also doesn't seem to me as
> > a part of xlogreader, the
On Thu, Mar 24, 2022 at 10:22 AM Kyotaro Horiguchi
wrote:
> +void
> +XLogRecGetBlockRefInfo(XLogReaderState *record, char *delimiter,
> + uint32 *fpi_len, bool
> detailed_format,
> + StringInfo buf)
> ...
> +
At Wed, 23 Mar 2022 21:36:09 +0530, Bharath Rupireddy
wrote in
> Here's a refactoring patch that basically moves the pg_waldump's
> functions and stats structures to xlogreader.h/.c so that the
> pg_walinspect can reuse them. If it looks okay, I will send the
> pg_walinspect patches based on
On Tue, Mar 22, 2022 at 11:30 PM Andres Freund wrote:
>
> > > To me duplicating this much code from waldump seems like a bad idea from a
> > > maintainability POV.
> >
> > Even if we were to put the above code from pg_walinspect and
> > pg_waldump into, say, walutils.c or some other existing
On Tue, Mar 22, 2022 at 11:30 PM Andres Freund wrote:
>
> > > Why "CALLED ON NULL INPUT"? It doesn't make sense to call the function
> > > with a
> > > NULL lsn, does it? Also, that's the default, why is it restated here?
> >
> > pg_get_wal_records_info needed that option (if end_lsn being the
At Wed, 23 Mar 2022 11:51:25 +0900 (JST), Kyotaro Horiguchi
wrote in
> The two places emit different outputs but the only difference is the
> delimiter between two blockrefs. (By the way, the current code forgets
> to insert a delimiter there). So even if the function took "bool
> is_waldump",
At Tue, 22 Mar 2022 11:00:06 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-03-22 21:57:51 +0530, Bharath Rupireddy wrote:
> > > This is probably close to an order of magnitude slower than pg_waldump
> > > --stats. Which imo renders this largely useless.
> >
> > Yeah that's true. Do you
Hi,
On 2022-03-22 21:57:51 +0530, Bharath Rupireddy wrote:
> On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
> > On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > > +--
> > > +-- pg_get_raw_wal_record()
> >
> > What is raw about the function?
>
> It right now gives data starting
On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
>
> Hi,
>
> First look at this patch, so I might be repeating stuff already commented on /
> discussed.
Thanks for taking a look at the patch.
> On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > +--
> > +-- pg_get_raw_wal_record()
>
On Fri, Mar 18, 2022 at 8:07 PM Nitin Jadhav
wrote:
>
> Hi Bharath,
>
> Due to recent commits on master, the pg_walinpect module is not
> compiling. Kindly update the patch.
Thanks Nitin. Here's an updated v12 patch-set. I will respond to
Andres comments in a while.
Regards,
Bharath Rupireddy.
Hi,
First look at this patch, so I might be repeating stuff already commented on /
discussed.
On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> +--
> +-- pg_get_raw_wal_record()
> +--
> +CREATE FUNCTION pg_get_raw_wal_record(IN in_lsn pg_lsn,
> +OUT start_lsn pg_lsn,
> +OUT
Hi Bharath,
Due to recent commits on master, the pg_walinpect module is not
compiling. Kindly update the patch.
pg_walinspect.c: In function ‘GetXLogRecordInfo’:
pg_walinspect.c:362:39: error: ‘XLogReaderState’ {aka ‘struct
XLogReaderState’} has no member named ‘max_block_id’
362 | for
On Thu, Mar 17, 2022 at 10:48 AM Kyotaro Horiguchi
wrote:
>
> It still suggests unspecifiable end-LSN..
>
> > select * from pg_get_wal_records_info('4/4B28EB68', '4/4C60');
> > ERROR: cannot accept future end LSN
> > DETAIL: Last known WAL LSN on the database system is 4/4C60.
Thanks
On Wed, Mar 16, 2022 at 8:49 PM Ashutosh Sharma wrote:
>
> I can see that the pg_get_wal_records_info function shows the details
> of the WAL record whose existence is beyond the user specified
> stop/end lsn pointer. See below:
>
> ashu@postgres=# select * from
At Wed, 16 Mar 2022 20:49:12 +0530, Ashutosh Sharma
wrote in
> I can see that the pg_get_wal_records_info function shows the details
> of the WAL record whose existence is beyond the user specified
> stop/end lsn pointer. See below:
>
> ashu@postgres=# select * from
I can see that the pg_get_wal_records_info function shows the details
of the WAL record whose existence is beyond the user specified
stop/end lsn pointer. See below:
ashu@postgres=# select * from pg_get_wal_records_info('0/0128',
'0/0129');
-[ RECORD 1
Greetings,
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> On Tue, Mar 15, 2022 at 7:21 AM Bharath Rupireddy
> wrote:
> >
> > On Mon, Mar 14, 2022 at 8:25 PM Stephen Frost wrote:
> > >
> > > > As this patch is currently written, pg_monitor has access these
> > > >
On Tue, Mar 15, 2022 at 7:21 AM Bharath Rupireddy
wrote:
>
> On Mon, Mar 14, 2022 at 8:25 PM Stephen Frost wrote:
> >
> > > As this patch is currently written, pg_monitor has access these
> > > functions, though I don't think that's the right privilege level at
> > > least for
On Mon, Mar 14, 2022 at 8:25 PM Stephen Frost wrote:
>
> > As this patch is currently written, pg_monitor has access these
> > functions, though I don't think that's the right privilege level at
> > least for pg_get_raw_wal_record().
>
> Yeah, I agree that pg_monitor isn't the right thing for
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Thu, 2022-03-10 at 15:54 -0500, Stephen Frost wrote:
> > The standard is basically that all of the functions it brings are
> > written to enforce the PG privilege system and you aren't able to use
> > the extension to bypass those
At Fri, 11 Mar 2022 15:39:13 -0500, Robert Haas wrote
in
> On Thu, Mar 10, 2022 at 9:38 PM Kyotaro Horiguchi
> wrote:
> > It seems to me too rigorous that pg_get_wal_records_info/stats()
> > reject future LSNs as end-LSN and I think WARNING or INFO and stop at
> > the real end-of-WAL is more
On Sat, Mar 12, 2022 at 2:09 AM Robert Haas wrote:
>
> On Thu, Mar 10, 2022 at 9:38 PM Kyotaro Horiguchi
> wrote:
> > It seems to me too rigorous that pg_get_wal_records_info/stats()
> > reject future LSNs as end-LSN and I think WARNING or INFO and stop at
> > the real end-of-WAL is more kind to
On Fri, Mar 11, 2022 at 7:53 PM Ashutosh Sharma wrote:
>
> Some comments on pg_walinspect-docc.patch this time:
>
> +
> +
> + pg_get_wal_record_info(in_lsn pg_lsn, lsn OUT pg_lsn,
> prev_lsn OUT pg_lsn, xid OUT xid, resource_manager OUT text, length
> OUT int4, total_length OUT int4,
On Thu, 2022-03-10 at 15:54 -0500, Stephen Frost wrote:
> The standard is basically that all of the functions it brings are
> written to enforce the PG privilege system and you aren't able to use
> the extension to bypass those privileges. In some cases that means
> that
Every extension should
On Thu, Mar 10, 2022 at 9:38 PM Kyotaro Horiguchi
wrote:
> It seems to me too rigorous that pg_get_wal_records_info/stats()
> reject future LSNs as end-LSN and I think WARNING or INFO and stop at
> the real end-of-WAL is more kind to users. I think the same with the
> restriction that start and
On Fri, Mar 11, 2022 at 8:22 AM Kyotaro Horiguchi
wrote:
> >
> - The difference between pg_get_wal_record_info and _records_ other than
> - the number of argument is the former accepts incorrect LSNs.
>
> The discussion is somewhat confused after some twists and turns.. It
> should be something
Some comments on pg_walinspect-docc.patch this time:
+
+
+ pg_get_wal_record_info(in_lsn pg_lsn, lsn OUT pg_lsn,
prev_lsn OUT pg_lsn, xid OUT xid, resource_manager OUT text, length
OUT int4, total_length OUT int4, description OUT text, block_ref OUT
text, data OUT bytea, data_len OUT
On Fri, Mar 11, 2022 at 8:08 AM Kyotaro Horiguchi
wrote:
>
> > Attaching the v8 patch-set resolving above comments and some tests for
> > checking function permissions. Please review it further.
>
> I played with this a bit, and would like to share some thoughts on it.
Thanks a lot Kyotaro-san
On Fri, Mar 11, 2022 at 8:22 AM Kyotaro Horiguchi
wrote:
>
> - The difference between pg_get_wal_record_info and _records_ other than
> - the number of argument is the former accepts incorrect LSNs.
>
> The discussion is somewhat confused after some twists and turns.. It
> should be something
On Fri, Mar 11, 2022 at 8:22 AM Kyotaro Horiguchi
wrote:
>
> Sorry, some minor non-syntactical corrections.
>
> At Fri, 11 Mar 2022 11:38:22 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I played with this a bit, and would like to share some thoughts on it.
> >
> > It seems to me too rigorous
Sorry, some minor non-syntactical corrections.
At Fri, 11 Mar 2022 11:38:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> I played with this a bit, and would like to share some thoughts on it.
>
> It seems to me too rigorous that pg_get_wal_records_info/stats()
> reject future LSNs as end-LSN and
At Thu, 10 Mar 2022 22:15:42 +0530, Bharath Rupireddy
wrote in
> On Thu, Mar 10, 2022 at 1:52 PM Jeff Davis wrote:
> >
> > On Wed, 2022-03-02 at 22:37 +0530, Bharath Rupireddy wrote:
> > >
> > > Attaching v6 patch set with above review comments addressed. Please
> > > review it further.
>
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 3:22 AM Jeff Davis wrote:
> > * Can we mark this extension 'trusted'? I'm not 100% clear on the
> > standards for that marker, but it seems reasonable for a database owner
> > with the right privileges might want
On Thu, Mar 10, 2022 at 3:22 AM Jeff Davis wrote:
> * Can we mark this extension 'trusted'? I'm not 100% clear on the
> standards for that marker, but it seems reasonable for a database owner
> with the right privileges might want to install it.
I'm not clear on the standard either, exactly, but
On Thu, Mar 10, 2022 at 1:52 PM Jeff Davis wrote:
>
> On Wed, 2022-03-02 at 22:37 +0530, Bharath Rupireddy wrote:
> >
> > Attaching v6 patch set with above review comments addressed. Please
> > review it further.
Thanks Jeff for reviewing it. I've posted the latest v7 patch-set
upthread [1]
On Wed, 2022-03-02 at 22:37 +0530, Bharath Rupireddy wrote:
>
> Attaching v6 patch set with above review comments addressed. Please
> review it further.
* Don't issue WARNINGs or other messages for ordinary situations, like
when pg_get_wal_records_info() hits the end of WAL.
* It feels like the
Thanks Bharath for working on all my review comments. I took a quick
look at the new version of the patch (v7-pg_walinspect.patch) and this
version looks a lot better. I'll do some detailed review later (maybe
next week or so) and let you know my further comments, if any.
--
With Regards,
On Thu, Mar 3, 2022 at 10:05 PM Robert Haas wrote:
>
> On Fri, Feb 25, 2022 at 6:03 AM Bharath Rupireddy
> wrote:
> > Added a new function that returns the first and last valid WAL record
> > LSN of a given WAL file.
>
> Sounds like fuzzy thinking to me. WAL records can cross file
> boundaries,
On Fri, Feb 25, 2022 at 6:03 AM Bharath Rupireddy
wrote:
> Added a new function that returns the first and last valid WAL record
> LSN of a given WAL file.
Sounds like fuzzy thinking to me. WAL records can cross file
boundaries, and forgetting about that leads to all sorts of problems.
Just give
I think we should also see if we can allow end users to input timeline
information with the pg_walinspect functions. This will help the end
users to get information about WAL records from previous timeline
which can be helpful in case of restored servers.
--
With Regards,
Ashutosh Sharma.
On
Here are a few comments.
1)
> > > ==
> > >
> > > +--
> > > +-- pg_get_wal_records_info_till_end_of_wal()
> > > +--
> > > +CREATE FUNCTION pg_get_wal_records_info_till_end_of_wal(IN start_lsn
> > > pg_lsn,
> > > +OUT lsn pg_lsn,
> > > +OUT prev_lsn pg_lsn,
> > > +OUT xid xid,
> > >
>
Hi.
+#ifdef FRONTEND
+/*
+ * Functions that are currently not needed in the backend, but are better
+ * implemented inside xlogreader.c because of the internal facilities available
+ * here.
+ */
+
#endif /* FRONTEND */
Why didn't you remove the
On Wed, Mar 2, 2022 at 10:37 PM Bharath Rupireddy
wrote:
>
> On Wed, Mar 2, 2022 at 8:12 PM Ashutosh Sharma wrote:
> >
> > Some review comments on v5 patch (v5-0001-pg_walinspect.patch)
>
> Thanks for reviewing.
>
> > +--
> > +-- pg_get_wal_records_info()
> > +--
> > +CREATE FUNCTION
On Wed, Mar 2, 2022 at 8:12 PM Ashutosh Sharma wrote:
>
> Some review comments on v5 patch (v5-0001-pg_walinspect.patch)
Thanks for reviewing.
> +--
> +-- pg_get_wal_records_info()
> +--
> +CREATE FUNCTION pg_get_wal_records_info(IN start_lsn pg_lsn,
> +IN end_lsn pg_lsn,
> +IN
Some review comments on v5 patch (v5-0001-pg_walinspect.patch)
+--
+-- pg_get_wal_records_info()
+--
+CREATE FUNCTION pg_get_wal_records_info(IN start_lsn pg_lsn,
+IN end_lsn pg_lsn,
+IN wait_for_wal boolean DEFAULT false,
+OUT lsn pg_lsn,
What does the wait_for_wal flag mean here
On Wed, Feb 16, 2022 at 9:04 AM Ashutosh Sharma wrote:
> I don't think that's the use case of this patch. Unless there is some
> other valid reason, I would suggest you remove it.
Removed the function pg_verify_raw_wal_record. Robert and Greg also
voted for removal upthread.
> > > Should we add
On Wed, Feb 16, 2022 at 1:01 AM Bharath Rupireddy
wrote:
>
> On Mon, Feb 14, 2022 at 8:32 PM Ashutosh Sharma wrote:
> >
> > Here are few comments:
>
> Thanks for reviewing the patches.
>
> > +/*
> > + * Verify the authenticity of the given raw WAL record.
> > + */
> > +Datum
> >
On Wed, Feb 16, 2022 at 1:57 AM Robert Haas wrote:
>
> On Tue, Feb 15, 2022 at 2:31 PM Bharath Rupireddy
> wrote:
> > > +/*
> > > + * Verify the authenticity of the given raw WAL record.
> > > + */
> > > +Datum
> > > +pg_verify_raw_wal_record(PG_FUNCTION_ARGS)
> > > +{
> > >
> > >
> > > Do we
On Tue, Feb 15, 2022 at 2:31 PM Bharath Rupireddy
wrote:
> > +/*
> > + * Verify the authenticity of the given raw WAL record.
> > + */
> > +Datum
> > +pg_verify_raw_wal_record(PG_FUNCTION_ARGS)
> > +{
> >
> >
> > Do we really need this function? I see that whenever the record is
> > read, we
On Mon, Feb 14, 2022 at 8:32 PM Ashutosh Sharma wrote:
>
> Here are few comments:
Thanks for reviewing the patches.
> +/*
> + * Verify the authenticity of the given raw WAL record.
> + */
> +Datum
> +pg_verify_raw_wal_record(PG_FUNCTION_ARGS)
> +{
>
>
> Do we really need this function? I see
Here are few comments:
+/*
+ * Verify the authenticity of the given raw WAL record.
+ */
+Datum
+pg_verify_raw_wal_record(PG_FUNCTION_ARGS)
+{
Do we really need this function? I see that whenever the record is
read, we verify it. So could there be a scenario where any of these
functions would
On Thu, Feb 10, 2022 at 9:55 PM Peter Geoghegan wrote:
>
> On Sun, Feb 6, 2022 at 7:45 AM Robert Haas wrote:
> > For what it's worth, I am generally in favor of having something like
> > this in PostgreSQL. I think it's wrong of us to continue assuming that
> > everyone has command-line access.
On 2/6/22 10:45, Robert Haas wrote:
> For what it's worth, I am generally in favor of having something like
> this in PostgreSQL. I think it's wrong of us to continue assuming that
> everyone has command-line access. Even when that's true, it's not
> necessarily convenient. If you choose to use
On Sun, Feb 6, 2022 at 7:45 AM Robert Haas wrote:
> For what it's worth, I am generally in favor of having something like
> this in PostgreSQL. I think it's wrong of us to continue assuming that
> everyone has command-line access. Even when that's true, it's not
> necessarily convenient. If you
On Sun, Feb 6, 2022 at 9:15 PM Robert Haas wrote:
>
> On Mon, Jan 31, 2022 at 4:40 PM Greg Stark wrote:
> > So I looked at this patch and I have the same basic question as Bruce.
> > Do we really want to expose every binary tool associated with Postgres
> > as an extension? Obviously this is
On Mon, Jan 31, 2022 at 4:40 PM Greg Stark wrote:
> So I looked at this patch and I have the same basic question as Bruce.
> Do we really want to expose every binary tool associated with Postgres
> as an extension? Obviously this is tempting for cloud provider users
> which is not an unreasonable
On Tue, Feb 1, 2022 at 3:10 AM Greg Stark wrote:
>
> So I looked at this patch and I have the same basic question as Bruce.
Thanks a lot for the comments.
> Do we really want to expose every binary tool associated with Postgres
> as an extension? Obviously this is tempting for cloud provider
Additionally I've looked at the tests and I'm not sure but I don't
think this arrangement is going to work. I don't have the time to run
CLOBBER_CACHE and CLOBBER_CACHE_ALWAYS tests but I know they run
*really* slowly. So the test can't just do a CHECKPOINT and then trust
that the next few
On Mon, Jan 31, 2022 at 04:40:09PM -0500, Greg Stark wrote:
> 4) This isn't really an issue with your patch at all but why on earth
> do we have a bitvector for WAL compression methods?! Like, what does
> it mean to have multiple compression methods set? That should just be
> a separate field with
So I looked at this patch and I have the same basic question as Bruce.
Do we really want to expose every binary tool associated with Postgres
as an extension? Obviously this is tempting for cloud provider users
which is not an unreasonable argument. But it does have consequences.
1) Some things
On Thu, Nov 25, 2021 at 5:54 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 25, 2021 at 3:49 PM Bharath Rupireddy
> wrote:
> > >
> > > Thanks all. Here's the v1 patch set for the new extension pg_walinspect.
> > > Note that I didn't include the documentation part now, I will be doing it
> > > a
On Thu, Nov 25, 2021 at 3:49 PM Bharath Rupireddy
wrote:
> >
> > Thanks all. Here's the v1 patch set for the new extension pg_walinspect.
> > Note that I didn't include the documentation part now, I will be doing it a
> > bit later.
> >
> > Please feel free to review and provide your thoughts.
On Thu, Nov 18, 2021 at 6:43 PM Bharath Rupireddy
wrote:
>
> On Thu, Oct 7, 2021 at 10:43 AM Bharath Rupireddy
> wrote:
> > > Looking at the proposed API from the initial email, I like that there's
> > > both stats functionality and WAL record inspection functionality
> > > (similar to
On Thu, Oct 7, 2021 at 10:43 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> > Looking at the proposed API from the initial email, I like that there's
> > both stats functionality and WAL record inspection functionality
> > (similar to pg_waldump). I like that there's the
On Wed, Oct 6, 2021 at 10:26 PM Jeremy Schneider
wrote:
>
> On 10/5/21 17:43, Bruce Momjian wrote:
> > On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
> >> Specifically exposing pg_waldump functionality in SQL could speed up
> >> finding bugs in the PG logical replication code.
On 2021-Oct-06, Jeremy Schneider wrote:
> Well this whole conversation is just theoretical anyway until the code
> is shared. :) But if Bharath is writing functions to decode WAL, then
> wouldn't we just have pg_waldump use these same functions in order to
> avoid duplicating code?
Actually, a
On Wed, Oct 6, 2021 at 09:56:34AM -0700, Jeremy Schneider wrote:
> On 10/5/21 17:43, Bruce Momjian wrote:
> > On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
> >> Specifically exposing pg_waldump functionality in SQL could speed up
> >> finding bugs in the PG logical replication
On 10/5/21 17:43, Bruce Momjian wrote:
> On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
>> Specifically exposing pg_waldump functionality in SQL could speed up
>> finding bugs in the PG logical replication code. We found and fixed a
>> few over this past year, but there are more
On Tue, Oct 5, 2021 at 03:30:07PM -0700, Jeremy Schneider wrote:
> On 10/5/21 15:07, Bruce Momjian wrote:
> > On Wed, Sep 8, 2021 at 07:18:08PM +0530, Bharath Rupireddy wrote:
> >> While working on one of the internal features, we found that it is a
> >> bit difficult to run pg_waldump for a
On Tue, Oct 5, 2021 at 06:22:19PM -0400, Chapman Flack wrote:
> On 10/05/21 18:07, Bruce Momjian wrote:
> > Uh, are we going to implement everything that is only available at the
> > command line as an extension just for people who are using managed cloud
> > services
>
> One extension that runs
On 10/5/21 15:07, Bruce Momjian wrote:
> On Wed, Sep 8, 2021 at 07:18:08PM +0530, Bharath Rupireddy wrote:
>> While working on one of the internal features, we found that it is a
>> bit difficult to run pg_waldump for a normal user to know WAL info and
>> stats of a running postgres database
On 10/05/21 18:07, Bruce Momjian wrote:
> Uh, are we going to implement everything that is only available at the
> command line as an extension just for people who are using managed cloud
> services
One extension that runs a curated menu of command-line tools for you
and returns their stdout?
On Wed, Sep 8, 2021 at 07:18:08PM +0530, Bharath Rupireddy wrote:
> Hi,
>
> While working on one of the internal features, we found that it is a
> bit difficult to run pg_waldump for a normal user to know WAL info and
> stats of a running postgres database instance in the cloud. Many a
> times
On Fri, Sep 10, 2021 at 7:21 AM Michael Paquier wrote:
>
> On Thu, Sep 09, 2021 at 10:49:46PM +, Bossart, Nathan wrote:
> > +1
>
> A backend approach has the advantage that you can use the proper locks
> to make sure that a segment is not recycled or removed by a concurrent
> checkpoint, so
On Thu, Sep 09, 2021 at 10:49:46PM +, Bossart, Nathan wrote:
> +1
A backend approach has the advantage that you can use the proper locks
to make sure that a segment is not recycled or removed by a concurrent
checkpoint, so that would be reliable.
--
Michael
signature.asc
Description: PGP
On 9/8/21, 6:49 AM, "Bharath Rupireddy"
wrote:
> How about we create a new extension, called pg_walinspect (synonymous
> to pageinspect extension) with a bunch of SQL-callable functions that
> get the raw WAL records or stats out of a running postgres database
> instance in a more structured way
Hi,
While working on one of the internal features, we found that it is a
bit difficult to run pg_waldump for a normal user to know WAL info and
stats of a running postgres database instance in the cloud. Many a
times users or DBAs or developers would want to get and analyze
following:
1) raw WAL
89 matches
Mail list logo
