Hi,
> It only needed trivial rebasing; I have committed it after doing that.
I have updated the patches to support server compression (gzip) for
plain format backup. Please find attached v4 patches.
Thanks,
Dipesh
From 4d0c84d6fac841aafb757535cc0e48334a251581 Mon Sep 17 00:00:00 2001
From:
On Fri, Oct 01, 2021 at 05:03:04PM -0300, Ranier Vilela wrote:
> For me the assertion remains valid and usable.
Well, I was looking at this thread again, and I still don't see what
we benefit from this change. One thing that could also be done is to
initialize "result" at {0} at the top of
Here are some review comments for v71-0001
~~~
1. Commit Message - database
"...that don't satisfy this WHERE clause will be filtered out. This allows a
database or set of tables to be partially replicated. The row filter is
per table. A new row filter can be added simply by specifying a
At Thu, 27 Jan 2022 15:31:37 +0900, Michael Paquier wrote
in
> On Thu, Jan 20, 2022 at 12:13:08PM +0530, Amul Sul wrote:
> > I found the cause for the test failing on window -- is due to the
> > custom archive command setting which wasn't setting the correct window
> > archive directory path.
>
On Tue, Jan 18, 2022 at 06:46:03AM +0100, Ronan Dunklau wrote:
> Hum, there was a missing import in csvlog.c from the fix above. Sorry about
> that.
+
You are also forgetting that the table listing all the jsonlog fields
needs a refresh with this new key called "tags", and that it has a
JSON
On Wed, Nov 03, 2021 at 04:59:04PM +, Simon Riggs wrote:
> Thanks. Fixed and rebased.
+ if (xact_info == XLOG_XACT_PREPARE)
+ {
+ if (recoveryTargetUseOriginTime)
+ {
+ xl_xact_prepare *xlrec = (xl_xact_prepare *)
XLogRecGetData(record);
+
On Thu, Jan 27, 2022 at 4:59 PM Peter Smith wrote:
>
> On Thu, Jan 27, 2022 at 9:40 AM Greg Nancarrow
wrote:
> >
> > On Wed, Jan 26, 2022 at 2:08 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > There was a miss in the posted patch which didn't initialize the
parameter in
> > >
On Tue, Jan 25, 2022 at 12:12:40PM +0200, Heikki Linnakangas wrote:
> In last round of review, I spotted one bug: I had mixed up the meaning of
> EndOfLogTLI. It is the TLI in the *filename* of the WAL segment that we read
> the last record from, which can be different from the TLI that the last
>
On Thu, Jan 20, 2022 at 12:13:08PM +0530, Amul Sul wrote:
> I found the cause for the test failing on window -- is due to the
> custom archive command setting which wasn't setting the correct window
> archive directory path.
After reading this patch and this thread, I have noticed that you are
On Thu, Jan 27, 2022 at 10:24:14AM +0530, Anand Sowmithiran wrote:
> The INSERT...ON CONFLICT is used for doing upserts in one of our app.
> Our app works with both MS SQL and Postgresql, based on customer needs.
>
> Unlike the MS SQL MERGE command's OUTPUT clause that gives the $action
>
On Thu, Jan 27, 2022 at 9:40 AM Greg Nancarrow wrote:
>
> On Wed, Jan 26, 2022 at 2:08 PM houzj.f...@fujitsu.com
> wrote:
> >
> > There was a miss in the posted patch which didn't initialize the parameter
> > in
> > RelationBuildPublicationDesc, sorry for that. Attach the correct patch this
>
On Thu, Jan 27, 2022 at 5:54 PM Anand Sowmithiran wrote:
> Is there any workaround to get this info ?
There's an undocumented trick:
https://stackoverflow.com/questions/34762732/how-to-find-out-if-an-upsert-was-an-update-with-postgresql-9-5-upsert
On Wed, Jan 26, 2022 at 8:02 PM Amit Kapila wrote:
>
> On Wed, Jan 26, 2022 at 12:51 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 26, 2022 at 1:43 PM David G. Johnston
> > wrote:
> > >
> > > We probably should just provide an option for the user to specify
> > > "subrelid". If null, only
Hi,
I didn't quite get to responding in depth, but I wanted to at least respond to
one point today.
On 2022-01-25 20:27:07 +0900, Masahiko Sawada wrote:
> > The pgstat entries are quite wide (292 bytes), because of the error message
> > stored. That's nearly twice the size of
On Wed, Jan 26, 2022 at 11:07 AM Bharath Rupireddy
wrote:
>
> On Tue, Jan 25, 2022 at 12:00 PM vignesh C wrote:
> > Thanks for the comments, attached v17 patch has the fix for the same.
>
> Have a minor comment on v17:
>
> can we modify the elog(LOG, to new style ereport(LOG, ?
> +
On Wednesday, January 26, 2022, Anand Sowmithiran
wrote:
> The INSERT...ON CONFLICT is used for doing upserts in one of our app.
> Our app works with both MS SQL and Postgresql, based on customer needs.
>
> Unlike the MS SQL MERGE command's OUTPUT clause that gives the $action
>
On Wed, Jan 26, 2022 at 09:57:59AM +0900, Michael Paquier wrote:
> Yeah, that sounds like a good compromise. At least, I find the whole
> a bit easier to follow.
So, I have been checking this idea in details, and spotted what looks
like one issue in CreateRestartPoint(), as of:
/*
The INSERT...ON CONFLICT is used for doing upserts in one of our app.
Our app works with both MS SQL and Postgresql, based on customer needs.
Unlike the MS SQL MERGE command's OUTPUT clause that gives the $action
(this is off-topic)
At Thu, 27 Jan 2022 13:23:06 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 26 Jan 2022 17:25:14 -0800, Nathan Bossart
> wrote in
> > On Thu, Jan 27, 2022 at 10:07:38AM +0900, Kyotaro Horiguchi wrote:
> > > pg_waldump complains at the end in any case. I noticed that
On Wed, Jan 26, 2022 at 04:17:19PM -0500, Robert Haas wrote:
> 1. snapper failed 4 out of the last 5 runs in recoveryCheck. The
> latest run as of this writing shows this:
>
> [19:09:50] t/026_overwrite_contrecord.pl ok43136 ms
> # poll_query_until timed out executing this query:
> #
At Wed, 26 Jan 2022 17:25:14 -0800, Nathan Bossart
wrote in
> On Thu, Jan 27, 2022 at 10:07:38AM +0900, Kyotaro Horiguchi wrote:
> > pg_waldump complains at the end in any case. I noticed that the LSN
> > it shows in the finish message is incorrect. (I faintly thought that
> > I posted about
Kyotaro Horiguchi writes:
> I'm not sure why walsender of the standby continued running not knowing the
> primary has been once dead for such a long time.
Isn't this precisely the problem that made us revert the "graceful
disconnection" patch [1]? Munro seems to have a theory about
why that
On 2022/01/26 14:28, torikoshia wrote:
On 2022-01-26 13:17, Fujii Masao wrote:
Hi,
pg_log_backend_memory_contexts() should be designed not to send the
messages about the memory contexts to the client regardless of
client_min_messages. But I found that the message "logging memory
contexts of
On 2022/01/26 14:27, Bharath Rupireddy wrote:
On Wed, Jan 26, 2022 at 10:46 AM Bharath Rupireddy
wrote:
On Wed, Jan 26, 2022 at 9:48 AM Fujii Masao wrote:
Hi,
pg_log_backend_memory_contexts() should be designed not to send the messages about the
memory contexts to the client
At Wed, 26 Jan 2022 18:45:53 -0500, Andrew Dunstan wrote
in
> It's very unlikely any of this is your fault. In any case, intermittent
> failures are very hard to nail down.
The primary starts at 2022-01-26 16:30:06.613 the accepted a connectin
from the standby at 2022-01-26 16:30:09.911.
P:
Hi,
On Thu, Jan 27, 2022 at 10:28 AM TAO TANG wrote:
> the plan shows all the partitions are pruned, but in gdb tracing, it shows
> that
> the pruning happens in ExecInitAppend, and during planning stage pg does not
> prune any partitions. this is because in function
>
At Tue, 25 Jan 2022 17:34:56 +0900 (JST), Kyotaro Horiguchi
wrote in
> This v8 is changed in...
>
> - Added tests to 011_crash_recovery.pl
>
> - Fixed a bug that server emits "end-of-wal" messages even if it have
> emitted an error message for the same LSN.
>
> - Changed
Hi,
I tested the following case in PostgreSQL master:58e2e6
the partition table created:
create table tbl_dts (dts timestamp with time zone not null) partition
by range(dts);
create table tbl_dts_1 partition of tbl_dts for values from
('2021-07-02') to ('2021-08-01');
create table
On Thu, Jan 27, 2022 at 10:07:38AM +0900, Kyotaro Horiguchi wrote:
> pg_waldump complains at the end in any case. I noticed that the LSN
> it shows in the finish message is incorrect. (I faintly thought that
> I posted about this but I didn't find it..)
Is this thread [0] what you are
On Wed, Jan 26, 2022 at 2:08 PM houzj.f...@fujitsu.com
wrote:
>
> There was a miss in the posted patch which didn't initialize the parameter in
> RelationBuildPublicationDesc, sorry for that. Attach the correct patch this
> time.
>
I have some additional doc update suggestions for the v71-0001
Hello.
pg_waldump complains at the end in any case. I noticed that the LSN
it shows in the finish message is incorrect. (I faintly thought that
I posted about this but I didn't find it..)
> pg_waldump: fatal: error in WAL record at 0/15073F8: invalid record length at
> 0/1507470: wanted 24,
On Fri, Jan 21, 2022 at 11:49:56AM -0800, Andres Freund wrote:
> On 2022-01-20 20:41:16 +, Bossart, Nathan wrote:
>> Here's this part.
>
> And pushed to all branches. Thanks.
Thanks!
I spent some time thinking about the right way to proceed here, and I came
up with the attached patches.
On Tue, Jan 25, 2022 at 07:30:33PM +, Bossart, Nathan wrote:
> I think the patch is in decent shape. There may be a few remaining
> places where GetMaxBackends() is called repeatedly in the same
> function, but IIRC v4 already clears up the obvious ones. I don't
> know if this is worth
On Wed, 2022-01-26 at 15:59 -0800, Andres Freund wrote:
> > > Do we have a testcase for embedded NULLs in common names?
> >
> > We don't, neither for OpenSSL or NSS. AFAICR Jacob spent days trying to
> > get a
> > certificate generation to include an embedded NULL byte but in the end gave
> >
Hi,
On 2022-01-26 21:39:16 +0100, Daniel Gustafsson wrote:
> > What about
> > reconfiguring (note: add --enable-depend) the linux tasks to build against
> > nss, and then run the relevant subset of tests with it? Most tests don't
> > use
> > tcp / SSL anyway, so rerunning a small subset of
On Wed, 26 Jan 2022 at 18:46, Greg Stark wrote:
>
> On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
> >
> > In my view, previous efforts in this area have been too simplistic.
> >
>
> One thing I've been wanting to do something about is I think
> autovacuum needs to be a little cleverer about
On Wed, Jan 26, 2022 at 3:46 PM Greg Stark wrote:
> One thing I've been wanting to do something about is I think
> autovacuum needs to be a little cleverer about when *not* to vacuum a
> table because it won't do any good.
There was a thread about this exact thing not too long ago:
On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
>
> In my view, previous efforts in this area have been too simplistic.
>
One thing I've been wanting to do something about is I think
autovacuum needs to be a little cleverer about when *not* to vacuum a
table because it won't do any good.
I've
On 1/26/22 16:17, Robert Haas wrote
> 3. fairywren failed the last run in module-commit_tsCheck. It's unhappy
> because:
>
> [16:30:02] t/002_standby.pl ok13354 ms ( 0.06 usr 0.00 sys +
> 1.11 cusr 3.20 csys = 4.37 CPU)
> # poll_query_until timed out executing this query:
> #
On Wed, Jan 26, 2022 at 07:31:00PM +0100, Tomas Vondra wrote:
> I actually tried doing that, but I was not very happy with the result. The
> test has to call pg_resetwal, but then it also has to fake pg_xact data and
> so on, which seemed a bit ugly so did not include the test in the patch.
On Wed, Jan 26, 2022 at 2:08 PM houzj.f...@fujitsu.com
wrote:
>
> There was a miss in the posted patch which didn't initialize the parameter in
> RelationBuildPublicationDesc, sorry for that. Attach the correct patch this
> time.
>
A few comments for the v71-0001 patch:
On Tue, Jan 25, 2022 at 2:18 PM houzj.f...@fujitsu.com
wrote:
>
> On Monday, January 24, 2022 4:38 PM Peter Smith
> >
...
> > 5. src/include/catalog/pg_publication.h - typedef struct PublicationDesc
> >
> > +typedef struct PublicationDesc
> > +{
> > + /*
> > + * true if the columns referenced in
> On Wed, Jan 26, 2022 at 10:55 AM Robert Haas wrote:
> On Tue, Jan 25, 2022 at 3:32 PM Peter Geoghegan wrote:
> > For example, a
> > page that has 5 dead heap-only tuples is vastly different to a similar
> > page that has 5 LP_DEAD items instead -- and yet our current approach
> > makes no
I was thinking about whether it made sense to try to commit anything
and decided it would be a good idea to check how the buildfarm looks
first. It doesn't look great.
1. snapper failed 4 out of the last 5 runs in recoveryCheck. The
latest run as of this writing shows this:
[19:09:50]
On Tue, Jan 25, 2022 at 11:22 AM tushar wrote:
> A)Getting syntax error if -z is used along with -t
>
> [edb@centos7tushar bin]$ ./pg_basebackup -t server:/tmp/data902 -z -Xfetch
> pg_basebackup: error: could not initiate base backup: ERROR: syntax error
Oops. The attached patch should fix
On Tue, Jan 25, 2022 at 8:15 PM Michael Paquier wrote:
> Sure, but I don't think that it is a good idea to unify that yet, at
> least not until pg_dump is able to handle LZ4 as an option, as the
> main benefit that we'd gain here is to be able to change the code to a
> switch/case without
On Tue, Jan 25, 2022 at 3:34 PM John Naylor
wrote:
> I was thinking along the same lines as Dilip: If the anti-wraparound
> risk is really far in the future, there might not be much eligible
> freezing work to do. Dead tuples can be removed as soon as visibility
> rules allow it. With a separate
On Tue, Jan 25, 2022 at 3:32 PM Peter Geoghegan wrote:
> For example, a
> page that has 5 dead heap-only tuples is vastly different to a similar
> page that has 5 LP_DEAD items instead -- and yet our current approach
> makes no distinction. Chances are very high that if the only dead
> tuples are
On 1/25/22 04:25, Michael Paquier wrote:
On Mon, Jan 24, 2022 at 10:45:48PM +0100, Tomas Vondra wrote:
On 1/24/22 22:28, Bossart, Nathan wrote:
Attached patch is fixing this by just sorting the XIDs logically. The
xidComparator is meant for places that can't do logical ordering. But
these
On Tue, 2022-01-25 at 22:26 +, Jacob Champion wrote:
> On Wed, 2022-01-19 at 10:01 +0100, Daniel Gustafsson wrote:
> > > On 18 Jan 2022, at 17:37, Jacob Champion wrote:
> > >
> > > On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > > > I've attached a v50 which fixes the issues
On 2022-Jan-26, Robert Haas wrote:
> On Tue, Jan 25, 2022 at 10:12 PM Tomas Vondra
> wrote:
> > 2) brin_summarize_range()
> >
> > Now, the issue I think is more serious, more likely to happen, and
> > harder to fix. When summarizing a range, we write two WAL records:
> >
> > INSERT heapBlk 2
Hi,
On 2022-01-19 18:18:59 -0800, Andres Freund wrote:
> > robocopy /e /NFL /NDL tmp_install\initdb_template t\
> > 575ms
> >
> > So I guess we could use robocopy? That's shipped as part of windows
> > starting in
> > windows 10... xcopy has been there for longer, so I might just default to
On Tue, Jan 25, 2022 at 10:12 PM Tomas Vondra
wrote:
> 1) brin_desummarize_range()
>
> But if the cluster/VM/... crashes right after you ran the function (and
> it completed just fine, possibly even in an explicit transaciton), that
> change will get lost. Not really a serious data
On Tue, Jan 25, 2022 at 8:23 PM Michael Paquier wrote:
> On Tue, Jan 25, 2022 at 03:54:52AM +, Shinoda, Noriyoshi (PN Japan FSIP)
> wrote:
> > Michael, I am proposing to that we remove this message as part of
> > this commit:
> >
> > -pg_log_info("no value specified for
> On Jan 17, 2022, at 1:54 PM, Robert Haas wrote:
>
> + * dotcnt: how many separators were parsed from the pattern, by reference.
> + * Can be NULL.
>
> But then:
>
> +Assert(dotcnt != NULL);
Removed the "Can be NULL" part, as that use case doesn't make sense. The
caller should always
On 1/25/22 13:43, Alvaro Herrera wrote:
> On 2022-Jan-24, Peter Eisentraut wrote:
>
>> +decinteger {decdigit}(_?{decdigit})*
>> +hexinteger 0[xX](_?{hexdigit})+
>> +octinteger 0[oO](_?{octdigit})+
>> +bininteger 0[bB](_?{bindigit})+
> I think there should be
On 26.01.22 01:02, Tom Lane wrote:
Robert Haas writes:
On Tue, Jan 25, 2022 at 5:34 AM Peter Eisentraut
wrote:
Which part exactly? There are several different changes proposed here.
I was just going based on the description of the feature in your
original post. If someone is hoping that
On 1/25/22 18:08, David G. Johnston wrote:
> On Tue, Jan 25, 2022 at 3:38 PM Mikhail Dobrinin
> wrote:
>
> Hello,
>
> I have come across some missing documentation that I think could
> benefit the community.
>
> Several functions like `jsonb_exists`, `jsonb_exists_any`,
>
On Mon, Sep 27, 2021 at 8:48 AM Masahiko Sawada wrote:
>
Hi,
Here is the first WIP patch for the decoupling table and index vacuum.
The first mail of the thread has already explained the complete
background of why we want to do this so instead of describing that I
will directly jump into
Hi,
On Wed, Jan 26, 2022 at 02:43:54PM +0100, Pavel Stehule wrote:
>
> I think this is still necessary. The lock protects the variable against
> drop from the second session, but not for reverted deletion from the
> current session.
>
> This implementation is due Tomas's request for
>
> CREATE
command = SELECT pg_terminate_backend(pg_backend_pid());
result 1 status = PGRES_FATAL_ERROR
error message = "FATAL: terminating connection due to administrator command
"
result 2 status = PGRES_FATAL_ERROR
error message = "FATAL: terminating connection due to administrator command
server
> sessionvariable.c:
>
> + * Although session variables are not transactional, we don't
> + * want (and we cannot) to run cleaning immediately (when we
> + * got sinval message). The value of session variables can
> + * be still used or the operation that emits cleaning can be
> + * reverted.
Hi Julien,
On Tue, 2022-01-25 at 20:22 +0800, Julien Rouhaud wrote:
> To be honest I don't see how any monitoring solution could make any
> use of
> those fields as-is. For that reason in PoWA we unfortunately have to
> entirely
> ignore them. There was a previous attempt to provide a way to
On Tuesday, January 11, 2022 6:43 PM From: Ajin Cherian
wrote:
> Minor update to rebase the patch so that it applies clean on HEAD.
Hi, let me share some additional comments on v16.
(1) comment of pgoutput_change
@@ -630,11 +688,15 @@ pgoutput_change(LogicalDecodingContext *ctx,
I would not remove it altogether, there is plenty of consumers of this
extension's output in the wild (even if I think it's unfortunate) that might
not be interested in sequences, but changing it to off by default certainly
makes sense.
--
Petr Jelinek
> On 26. 1. 2022, at 11:09, Peter
Hi,
Sorry I somehow missed that email.
On Mon, Jan 24, 2022 at 7:53 AM Tom Lane wrote:
>
> Now, most of those are BSD machines --- but lapwing isn't.
> It says
>
> checking for python... (cached) /usr/bin/python
> configure: using python 3.6.9 (default, Jan 14 2022, 06:45:55)
> checking for
On Wed, Jan 26, 2022 at 12:51 PM Masahiko Sawada wrote:
>
> On Wed, Jan 26, 2022 at 1:43 PM David G. Johnston
> wrote:
> >
> > We probably should just provide an option for the user to specify
> > "subrelid". If null, only the main apply worker will skip the given xid,
> > otherwise only the
On Wed, Jan 26, 2022 at 8:37 AM houzj.f...@fujitsu.com
wrote:
>
> On Monday, January 24, 2022 4:38 PM Peter Smith wrote:
> >
> >
> > 3. src/backend/utils/cache/relcache.c - RelationBuildPublicationDesc
> >
> > +RelationBuildPublicationDesc(Relation relation)
> > {
> > List*puboids;
> >
On 26.01.22 03:16, Tomas Vondra wrote:
Here's a rebased version of the patch series. I decided to go back to
the version from 2021/12/14, which does not include the changes to WAL
logging.
I notice that test_decoding still has skip-sequences enabled by default,
"for backward compatibility".
On Tuesday, January 11, 2022 6:43 PM Ajin Cherian wrote:
> Minor update to rebase the patch so that it applies clean on HEAD.
Hi, thanks for you rebase.
Several comments.
(1) the commit message
"
transactions, keepalive messages are sent to keep the LSN locations updated
on the standby.
This
At Mon, 24 Jan 2022 23:33:20 +0300, Daniel Shelepanov
wrote in
> Hi. This is my first attempt to review a patch so feel free to tell me
> if I missed something.
Welcome!
> As of today's state of REL_14_STABLE
> (ef9706bbc8ce917a366e4640df8c603c9605817a), the problem is
> reproducible using
71 matches
Mail list logo
