On Tue, Sep 7, 2021 at 11:10 AM Amit Kapila wrote:
>> Isn't it better if we use option 2) at all places as then we won't
> >> need any special check inside ReorderBufferChangeMemoryUpdate()?
> >
> >
> > If we want to do this then be careful about
> REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID change.
On Tue, Sep 7, 2021 at 11:06 AM Amit Kapila wrote:
> On Mon, Sep 6, 2021 at 11:21 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Sep-06, Rahila Syed wrote:
> >
> > > > > ... ugh. Since CASCADE is already defined to be a
> > > > > potentially-data-loss operation, then that may be acceptable
> > > >
On Mon, Sep 6, 2021 at 5:29 PM Ashutosh Bapat
wrote:
>
> Yeah, I agree. Sorry for missing that.
>
> The updated patch looks good to me.
>
Pushed!
--
With Regards,
Amit Kapila.
On Tue, Sep 7, 2021 at 11:08 AM Dilip Kumar wrote:
>
> On Tue, Sep 7, 2021 at 8:38 AM Amit Kapila wrote:
>>
>> On Mon, Sep 6, 2021 at 9:14 PM Dilip Kumar wrote:
>> >
>> > On Mon, Sep 6, 2021 at 8:54 PM Drouvot, Bertrand
>> > wrote:
>> >>
>> >> Thanks for your feedback!
>> >>
>> >> That seems
On Tue, Sep 7, 2021 at 8:38 AM Amit Kapila wrote:
> On Mon, Sep 6, 2021 at 9:14 PM Dilip Kumar wrote:
> >
> > On Mon, Sep 6, 2021 at 8:54 PM Drouvot, Bertrand
> wrote:
> >>
> >> Thanks for your feedback!
> >>
> >> That seems indeed more logical, so I see 3 options to do so:
> >>
> >> 1) Add a
On Mon, Sep 6, 2021 at 11:21 PM Alvaro Herrera wrote:
>
> On 2021-Sep-06, Rahila Syed wrote:
>
> > > > ... ugh. Since CASCADE is already defined to be a
> > > > potentially-data-loss operation, then that may be acceptable
> > > > behavior. For sure the default RESTRICT behavior shouldn't do it,
On Tue, Sep 07, 2021 at 01:11:49PM +0800, Julien Rouhaud wrote:
> Yes, that's because json identifiers have different rules from
> relation identifiers. Your only option here is to use the real /
> truncated identifier. Also I don't think it would be a good thing to
> add a way to truncate
On Fri, Sep 03, 2021 at 09:23:27PM -0500, Justin Pryzby wrote:
> On Fri, Sep 03, 2021 at 01:23:56PM +0530, Nitin Jadhav wrote:
> > Please find the updated patch attached.
>
> Please check
> CA+TgmoZtbqxaOLdpNkBcDbz=41tWALA8kpH4M=rwtpyhc7-...@mail.gmail.com
>
> I agree with Robert that a standby
On Tue, Sep 7, 2021 at 11:27 AM Денис Романенко wrote:
>
> If we create a column name longer than 64 bytes, it will be truncated in
> PostgreSQL to max (NAMEDATALEN) length.
>
> For example:
> "VeryLongNameVeryLongNameVeryLongNameVeryLongNameVeryLongNameVeryLongName"
> will be truncated in
On Mon, Sep 6, 2021 at 9:25 PM Rahila Syed wrote:
>
> On Mon, Sep 6, 2021 at 8:53 AM Amit Kapila wrote:
>>
>
>> Did you give any thoughts to my earlier suggestion related to syntax [1]?
>>
>>
>> [1] -
>>
On Fri, Mar 26, 2021 at 09:54:21AM -0400, David Steele wrote:
> I'm going to move this to the 2021-07 CF and leave it in the Waiting for
> Author state. It would probably be best to wait until just before the CF to
> rebase since anything you do now will likely be broken by the flurry of
> commits
Hello,
Thank you everyone for comments.
In the thread [1] that Horiguchi told me about, there is already a review going
on about GUC for HugePages memory.
For this reason, I have removed the new GUC implementation and attached a patch
that changes only the message at instance startup.
[1]
On Mon, Sep 6, 2021 at 1:49 PM houzj.f...@fujitsu.com
wrote:
>
> From Mon, Sep 6, 2021 3:59 PM tanghy.f...@fujitsu.com
> wrote:
> > I met a problem when using logical replication. Maybe it's a bug in logical
> > replication.
> > When publishing a partition table without replica identity, update
On Mon, Sep 06, 2021 at 11:55:42PM +, Bossart, Nathan wrote:
> Attached is a new patch set. The first two patches just add the new
> GUCs, and the third is an attempt at providing useful values for those
> GUCs via -C.
+ sprintf(buf, "%lu MB", size_mb);
+
Hi,
While working on [1], we found that EXPLAIN(VERBOSE) to CTE with SEARCH
BREADTH FIRST ends up ERROR.
This can be reproduced at the current HEAD(4c3478859b7359912d7):
=# create table graph0( f int, t int, label text);
CREATE TABLE
=# insert into graph0 values (1, 2, 'arc 1 ->
On 2021-08-20 01:12, Fujii Masao wrote:
On 2021/08/11 21:14, torikoshia wrote:
As far as I looked into, pg_log_current_plan() can call InstrEndLoop()
through ExplainNode().
I added a flag to ExplainState to avoid calling InstrEndLoop() when
ExplainNode() is called from pg_log_current_plan().
On 2021/09/07 10:32, kuroda.hay...@fujitsu.com wrote:
Dear Fujii-san,
I confirmed it and I think it's OK.
Other comments should be included in 0002.
Pushed 0001 patch. Thanks!
Could you rebase 0002 patch?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and
If we create a column name longer than 64 bytes, it will be truncated in
PostgreSQL to max (NAMEDATALEN) length.
For example: "
VeryLongNameVeryLongNameVeryLongNameVeryLongNameVeryLongNameVeryLongName"
will be truncated in database to "
On Mon, Sep 6, 2021 at 9:14 PM Dilip Kumar wrote:
>
> On Mon, Sep 6, 2021 at 8:54 PM Drouvot, Bertrand wrote:
>>
>> Thanks for your feedback!
>>
>> That seems indeed more logical, so I see 3 options to do so:
>>
>> 1) Add a new API say ReorderBufferChangeMemorySubstractSize() (with a Size
>>
At Tue, 7 Sep 2021 09:37:10 +0900, Michael Paquier wrote
in
> On Mon, Sep 06, 2021 at 12:03:32PM -0400, Tom Lane wrote:
> > I scraped the buildfarm logs looking for similar failures, and didn't
> > find any. (019_replslot_limit.pl hasn't failed at all in the farm
> > since the last fix it
On Mon, Sep 06, 2021 at 02:08:45PM +0900, Michael Paquier wrote:
> A minor point: this introduces PostgreSQL::Test::PostgresVersion.
> Could be this stripped down to PostgreSQL::Test::Version instead?
This fails to apply since 5fcb23c, but the conflicts are simple enough
to solve. Sorry about
On Mon, 6 Sep 2021 20:47:37 +0100, Tom Lane said:
> I'm confused by your description of this patch. AFAIK, OpenSSL verifies
> against the system-wide CA pool by default. Why do we need to do
> anything?
Experimentally, no it doesn't. Or if it does, then it doesn't verify
the CN/altnames of the
On Mon, Sep 6, 2021 at 7:09 PM Thomas Munro wrote:
> FTR I have a patch in development that adds a demand-paged (though
> Anastasia recently suggested reconsidering that) per-SMGR relation
> shmem object pool that initially tracks precisely "how long it is",
> but I hope it would provide a hook
On Thu, Sep 2, 2021 at 4:28 PM vignesh C wrote:
>
> Thanks for the comments, the attached v24 patch has the changes for the same.
>
Just a note that these patches no longer apply due to a recent commit
related to logical replication (0c6828fa98).
Regards,
Greg Nancarrow
Fujitsu Australia
On Thu, Aug 26, 2021 at 5:59 AM Robert Haas wrote:
> Andres has been working -- I think for years now -- on replacing the
> buffer mapping table with a radix tree of some kind. That strikes me
> as very similar to what you're doing here. The per-relation data can
> then include not only the kind
On Tue, Sep 7, 2021 at 5:44 AM Victor Spirin wrote:
> I have changed the way I add the manifest to projects. I used the
> AdditionalManifestFiles option for a VS project.
Hi Victor,
Thanks for working on this!
I wonder if POSIX-style rename is used automatically on recent
Windows, based on the
Dear Fujii-san,
I confirmed it and I think it's OK.
Other comments should be included in 0002.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
On 2021/09/06 21:28, Fujii Masao wrote:
>
>
> On 2021/09/06 16:48, Masahiro Ikeda wrote:
>> On 2021-09-06 13:21, kuroda.hay...@fujitsu.com wrote:
>>> Dear Ikeda-san,
>>>
I agree that this feature is useful. Thanks for working this.
>>>
>>> Thanks .
>>>
1)
Why does
On Mon, Sep 06, 2021 at 09:18:13PM -0300, Alvaro Herrera wrote:
> On 2021-Aug-14, Justin Pryzby wrote:
>
> > I elaborated on your definition and added here.
> > https://commitfest.postgresql.org/34/3285/
>
> Thanks! This works for me. After looking at it, it seemed to me that
> listing the
On Mon, Sep 06, 2021 at 12:03:32PM -0400, Tom Lane wrote:
> I scraped the buildfarm logs looking for similar failures, and didn't
> find any. (019_replslot_limit.pl hasn't failed at all in the farm
> since the last fix it received, in late July.)
The interesting bits are in
Here are some v5 review comments for your consideration:
--
1. src/backend/access/common/relation.c
@@ -215,3 +217,22 @@ relation_close(Relation relation, LOCKMODE lockmode)
if (lockmode != NoLock)
UnlockRelationId(, lockmode);
}
+
+/*
+ * Return a bitmapset of attributes given the
On Mon, Sep 6, 2021 at 4:33 PM Hannu Krosing wrote:
> When I have been thinking of this type of problem it seems that the
> latest -- and correct :) -- place which should do all kinds of
> cleanup like removing aborted tuples, freezing committed tuples and
> setting any needed hint bits would be
On 2021-Sep-06, Laurenz Albe wrote:
> I agree with Greg that the current behavior is annoying and would
> welcome the change. This has bothered me before.
It has bothered me too. I am particularly bothered by the uselessness
that M-# results in -- namely, inserting a # at the start of the
On 2021-Aug-14, Justin Pryzby wrote:
> I elaborated on your definition and added here.
> https://commitfest.postgresql.org/34/3285/
Thanks! This works for me. After looking at it, it seemed to me that
listing the autovacuum launcher is perfectly adapted, so we might as
well do it; and add
When I have been thinking of this type of problem it seems that the
latest -- and correct :) -- place which should do all kinds of
cleanup like removing aborted tuples, freezing committed tuples and
setting any needed hint bits would be background writer or CHECKPOINT.
This would be more
On Mon, Aug 16, 2021 at 5:15 PM Peter Geoghegan wrote:
> This is actually quite simple -- the chaos that follows is where it
> gets truly complicated (and not necessarily worth getting into just
> yet). The update of a given order and its order lines entries takes
> place hours later, within a
On 9/6/21 7:51 PM, Alvaro Herrera wrote:
> On 2021-Sep-06, Rahila Syed wrote:
>
... ugh. Since CASCADE is already defined to be a
potentially-data-loss operation, then that may be acceptable
behavior. For sure the default RESTRICT behavior shouldn't do it,
though.
>>>
>>>
On Mon, Sep 6, 2021 at 12:53 PM Paul A Jungwirth <
p...@illuminatedcomputing.com> wrote:
> On Sat, Sep 4, 2021 at 12:56 PM Jaime Casanova
> wrote:
> >
> > patch 01: does apply but doesn't compile, attached the compile errors.
> > patch 04: does not apply clean.
>
> Thanks for taking a look! I've
Thomas Habets writes:
> With Letsencrypt now protecting web servers left and right, and it makes
> sense to me to just re-use the cert that the server may already have
> installed.
I'm confused by your description of this patch. AFAIK, OpenSSL verifies
against the system-wide CA pool by
With Letsencrypt now protecting web servers left and right, and it makes
sense to me to just re-use the cert that the server may already have
installed.
I've tested this on debian with the client compiled from the master branch,
against a 13.3 server.
This is my first patch to postgresql, so I
On Mon, Sep 06, 2021 at 07:50:15AM -0700, David G. Johnston wrote:
> On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote:
> > I've attached a patch that corrects the behaviour.
> > For the type of lines mentioned, the patch makes the history behave
> > more like Bash history.
The behavior of
Got this warning:
/pgsql/source/master/contrib/postgres_fdw/postgres_fdw.c: In function
'GetResultRelCheckAsUser':
/pgsql/source/master/contrib/postgres_fdw/postgres_fdw.c:1898:7: warning:
unused variable 'result' [-Wunused-variable]
Oid result;
^~
I think the idea that
Artur Zakirov writes:
> I attached the patch which fixes it in a different way. It calls
> SignalBackends() in AtCommit_Notify(). It is possible to call SignalBackends()
> outside of ProcessCompletedNotifies() after the commit
> 51004c7172b5c35afac050f4d5849839a06e8d3b, which removes necessity of
The code in get_rel_sync_entry() changes current memory context to
CacheMemoryContext, then does a bunch of memory-leaking things. This is
not good, because that memory context has to be very carefully managed
to avoid permanent memory leaks. I suppose you added that because you
need something
On 2021-Sep-06, Rahila Syed wrote:
> > > ... ugh. Since CASCADE is already defined to be a
> > > potentially-data-loss operation, then that may be acceptable
> > > behavior. For sure the default RESTRICT behavior shouldn't do it,
> > > though.
> >
> > That makes sense to me.
>
> However, the
Hello.
I have changed the way I add the manifest to projects. I used the
AdditionalManifestFiles option for a VS project.
Victor Spirin
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
08.07.2021 1:32, Victor Spirin пишет:
Thanks!
In this version of the patch,
On 2021/07/29 13:23, Yugo NAGATA wrote:
Hello,
On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
Fabien COELHO wrote:
Attached Yugo-san patch with some updates discussed in the previous mails,
so as to move things along.
I attached the patch rebased to a change due to 856de3b39cf.
+
On 2021/09/06 3:11, Alvaro Herrera wrote:
On 2021-Sep-03, Kyotaro Horiguchi wrote:
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 24165ab03e..b621ad6b0f 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@
On Mon, Sep 6, 2021 at 2:41 AM Ronan Dunklau wrote:
> Le lundi 6 septembre 2021, 11:25:39 CEST Zhihong Yu a écrit :
> > On Mon, Sep 6, 2021 at 1:17 AM Ronan Dunklau wrote:
> > > Le vendredi 3 septembre 2021, 22:54:25 CEST David Zhang a écrit :
> > > > The following review has been posted
On 2021/09/04 15:27, Fabien COELHO wrote:
Hello Fujii-san,
ISTM that the patch changes pgbench so that it can skip counting
some skipped transactions here even for realistic rates under -T.
Of course, which would happen very rarely. Is this understanding right?
Yes. The point is to get
Alvaro Herrera writes:
> On 2021-Sep-06, Michael Paquier wrote:
>> # poll_query_until timed out executing this query:
>> # SELECT wal_status FROM pg_replication_slots WHERE slot_name = 'rep3'
> Hmm, I've never seen that, and I do run tests in parallel quite often.
I scraped the buildfarm logs
On Mon, 2021-09-06 at 07:50 -0700, David G. Johnston wrote:
> On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote:
> > I've attached a patch that corrects the behaviour.
> > For the type of lines mentioned, the patch makes the history behave
> > more like Bash history.
>
> I have my doubts that
Hi,
On Mon, Sep 6, 2021 at 8:53 AM Amit Kapila wrote:
> On Sat, Sep 4, 2021 at 8:11 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Sep-04, Amit Kapila wrote:
> >
> > > On Thu, Sep 2, 2021 at 2:19 PM Alvaro Herrera
> wrote:
> > > >
> > > > On 2021-Sep-02, Rahila Syed wrote:
> > > >
> > > > > After
Aleksander Alekseev writes:
>> Anyway, attached is a revised patch that gets rid of the antique
>> code, and it produces correct results AFAICT.
> I tested your patch against the current master branch 78aa616b on
> MacOS Catalina. I have nothing to add to the patch.
Thanks. Pushed, along with
On Mon, Sep 6, 2021 at 8:54 PM Drouvot, Bertrand
wrote:
> Thanks for your feedback!
>
> That seems indeed more logical, so I see 3 options to do so:
>
> 1) Add a new API say ReorderBufferChangeMemorySubstractSize() (with a
> Size as one parameter) and make use of it in
Hi,
‐‐‐ Original Message ‐‐‐
On Tuesday, August 24th, 2021 at 13:20, Ranier Vilela
wrote:
> Em ter., 24 de ago. de 2021 às 03:11, Masahiko Sawada
> escreveu:
>
> > On Mon, Aug 23, 2021 at 10:46 AM Masahiko Sawada
> > wrote:
> >
> > >
> > > On Thu, Aug 19, 2021 at 10:52 PM Ranier
Hello
On 2021-Sep-06, Michael Paquier wrote:
> Running the recovery tests in a parallel run, enough to bloat a
> machine in resources, sometimes leads me to the following failure:
> ok 19 - walsender termination logged
> # poll_query_until timed out executing this query:
> # SELECT wal_status
On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote:
> I've attached a patch that corrects the behaviour.
> For the type of lines mentioned, the patch makes the history behave
> more like Bash history.
>
I have my doubts that you've really fixed anything here since Bash is a
line-oriented shell
Hi,
Single lines entered in PSQL interactive-mode, containing just
whitespace or an SQL comment ("--..."), don't seem to be stored
correctly in the history.
For example, such lines are currently prepended to the history of the
next command entered, rather than having their own history entry.
Hi,
On 06.09.2021 14:39, gkokola...@pm.me wrote:
I apply patches by `git apply` and executing the command on the latest version
of your patch, produces:
$ git apply lo-list-acl-v2.patch
lo-list-acl-v2.patch:349: new blank line at EOF.
+
warning: 1 line adds whitespace errors
On Mon, Sep 6, 2021 at 6:36 PM Michael Paquier wrote:
> Having a non-invasive fix for this long-standing issue would be really
> great, even if that means reducing the scope of systems where this can
> be fixed.
I hope those patches fix at least the basebackup problem on all
relevant OS
On 2021/09/06 16:48, Masahiro Ikeda wrote:
On 2021-09-06 13:21, kuroda.hay...@fujitsu.com wrote:
Dear Ikeda-san,
I agree that this feature is useful. Thanks for working this.
Thanks :-).
1)
Why does postgres_fdw.application_name override the server's option?
> + establishes a
Yeah, I agree. Sorry for missing that.
The updated patch looks good to me.
On Mon, Sep 6, 2021 at 3:25 PM Amit Kapila wrote:
> On Tue, Aug 17, 2021 at 11:58 AM Ashutosh Bapat
> wrote:
> >
> > Hi Amit and Andres,
> > Here's updated patch
> >
>
> I think we can log the required information
On Mon, Sep 6, 2021 at 4:04 PM Amit Kapila wrote:
> On Fri, Aug 13, 2021 at 3:15 PM Drouvot, Bertrand
> wrote:
> >
> >
> > Please find attached a patch proposal to avoid the failed assertion (by
> ensuring that ReorderBufferChangeMemoryUpdate() being triggered with
> "addition" set to false in
On 2021/09/06 10:32, kuroda.hay...@fujitsu.com wrote:
I think we should SELECT ft6 because foreign server 'loopback'
doesn't have application_name server option.
Yes. I forgot to update that... Thanks for the review!
Attached is the updated version of the patch.
Regards,
--
Fujii Masao
On Mon, Sep 6, 2021 at 9:44 AM Andres Freund wrote:
> Is it guaranteed, or at least reliable, that the status we fetch with
> RtlGetLastNtStatus is actually from the underlying filesystem operation,
> rather than some other work that happens during the win32->nt translation?
> E.g. a memory
‐‐‐ Original Message ‐‐‐
On Sunday, September 5th, 2021 at 21:47, Pavel Luzanov
wrote:
Hi,
> Hi,
>
> On 03.09.2021 15:25, Georgios Kokolatos wrote:
>
> > On a high level I will recommend the addition of tests. There are similar
> > tests
>
> Tests added.
Thanks! The tests look good.
On Fri, Aug 13, 2021 at 3:15 PM Drouvot, Bertrand wrote:
>
>
> Please find attached a patch proposal to avoid the failed assertion (by
> ensuring that ReorderBufferChangeMemoryUpdate() being triggered with
> "addition" set to false in ReorderBufferToastReplace() is done after the
>
> BTW, it's customary to *not* include catversion bumps in submitted
> patches
Thanks, Tom.
> Anyway, attached is a revised patch that gets rid of the antique
> code, and it produces correct results AFAICT.
I tested your patch against the current master branch 78aa616b on
MacOS Catalina. I have
Hi Nagata-san,
I'm still reading the patch.
I have additional comments.
(1)
In v23-0001-Add-a-syntax-to-create-Incrementally-Maintainabl.patch, ivm member
is added to IntoClause struct.
I think it is necessary to modify _copyIntoClause() and _equalIntoClause()
functions.
(2)
By executing
On Tue, Aug 17, 2021 at 11:58 AM Ashutosh Bapat
wrote:
>
> Hi Amit and Andres,
> Here's updated patch
>
I think we can log the required information immediately after
releasing spinlock, otherwise, the other logs from
LogicalConfirmReceivedLocation() might interleave. I have made that
change and
Le lundi 6 septembre 2021, 11:25:39 CEST Zhihong Yu a écrit :
> On Mon, Sep 6, 2021 at 1:17 AM Ronan Dunklau wrote:
> > Le vendredi 3 septembre 2021, 22:54:25 CEST David Zhang a écrit :
> > > The following review has been posted through the commitfest application:
> > > make installcheck-world:
On Mon, Sep 6, 2021 at 1:17 AM Ronan Dunklau wrote:
> Le vendredi 3 septembre 2021, 22:54:25 CEST David Zhang a écrit :
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, failed
> > Implements feature: tested, passed
> > Spec
On Mon, Sep 6, 2021 at 11:17 AM Dilip Kumar wrote
>
> Okay, that makes sense. Infact for using the shared buffers for the
> destination database's relation we don't even have the locking issue,
> because that database is not yet accessible to anyone right?
>
Based on all these discussions I am
On 05.09.21 21:57, Tom Lane wrote:
Peter Eisentraut writes:
Makes sense. I think we could do it without hardcoding those library
names, as in the attached patch. But it comes out to the same result
AFAICT.
This has been pushed, but the CF entry is still open, which is
making the cfbot
>From Mon, Sep 6, 2021 3:59 PM tanghy.f...@fujitsu.com
> wrote:
> I met a problem when using logical replication. Maybe it's a bug in logical
> replication.
> When publishing a partition table without replica identity, update
> or delete operation can be successful in some cases.
>
> For
On Mon, Sep 6, 2021 at 9:53 AM tanghy.f...@fujitsu.com
wrote:
>
> On Thursday, September 2, 2021 2:36 PM vignesh C wrote:
> >
> > On Wed, Sep 1, 2021 at 11:14 AM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > 3. When using '\dn+', I noticed that the list of publications only
> > > contains the
Le vendredi 3 septembre 2021, 22:54:25 CEST David Zhang a écrit :
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not
On 2021/09/02 21:47, Fujii Masao wrote:
On 2021/09/02 20:54, houzj.f...@fujitsu.com wrote:
Hi,
When reviewing other patches, I noticed two typos:
Thanks! Both fixes look good to me.
Barring any objection, I will commit the patch.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced
I add a test to reproduce the problem, you can see the attachment for specific
content
during the last sleep time of the test, use pstack to get the stack of the
backend process, which is as follows:
#0 0x7f6ebdd744d3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1
Hi
I met a problem when using logical replication. Maybe it's a bug in logical
replication.
When publishing a partition table without replica identity, update
or delete operation can be successful in some cases.
For example:
create table tbl1 (a int) partition by range ( a );
create table
On 2021-09-06 13:21, kuroda.hay...@fujitsu.com wrote:
Dear Ikeda-san,
I agree that this feature is useful. Thanks for working this.
Thanks :-).
1)
Why does postgres_fdw.application_name override the server's option?
> + establishes a connection to a foreign server. This overrides
>
On Mon, 2021-09-06 at 00:22 -0700, Andres Freund wrote:
> On 2021-09-06 09:12:58 +0200, Laurenz Albe wrote:
> > Reading your patch, I am still confused about the following:
> > There are potentially several calls to "pgstat_send_tabstat" in
> > "pgstat_report_stat".
> > It seems to me that if it
That seems good for me.
Thx !
Regards/Cordialement,
Tony Reix
tony.r...@atos.net
ATOS / Bull SAS
ATOS Expert
IBM-Bull Cooperation Project: Architect & OpenSource Technical Leader
1, rue de Provence - 38432 ECHIROLLES - FRANCE
Hi,
On 2021-09-06 09:12:58 +0200, Laurenz Albe wrote:
> Reading your patch, I am still confused about the following:
> There are potentially several calls to "pgstat_send_tabstat" in
> "pgstat_report_stat".
> It seems to me that if it were called more than once, session statistics would
> be
On Mon, Sep 06, 2021 at 12:37:29PM +0530, Bharath Rupireddy wrote:
> -1 for READ_PHYSICAL_REPLICATION_SLOT or failing on the server. What
> happens if we have another slot type "PHYSIOLOGICAL" or "FOO" or "BAR"
> some other? IMO, READ_REPLICATION_SLOT should just return info of all
> slots. The
Le vendredi 3 septembre 2021 17:49:34 CEST, vous avez écrit :
> On Fri, Sep 3, 2021 at 3:28 PM Ronan Dunklau wrote:
> > There is still the concern raised by Bharath about being able to select
> > the
> > way to fetch the replication slot information for the user, and what
> > should or should not
On Fri, 2021-09-03 at 17:04 -0700, Andres Freund wrote:
> Hi,
>
> On 2021-08-31 21:56:50 -0700, Andres Freund wrote:
> > On 2021-08-27 13:57:45 +0900, Michael Paquier wrote:
> > > On Wed, Aug 25, 2021 at 01:20:03AM -0700, Andres Freund wrote:
> > > > On 2021-08-25 12:51:58 +0900, Michael Paquier
On Mon, Sep 6, 2021 at 12:20 PM Ronan Dunklau wrote:
>
> Le lundi 6 septembre 2021, 06:22:30 CEST Michael Paquier a écrit :
> > On Fri, Sep 03, 2021 at 11:58:27AM +0200, Ronan Dunklau wrote:
> > > 0002 for pg_receivewal tried to simplify the logic of information to
> > > return, by using a
Le lundi 6 septembre 2021, 06:22:30 CEST Michael Paquier a écrit :
> On Fri, Sep 03, 2021 at 11:58:27AM +0200, Ronan Dunklau wrote:
> > 0002 for pg_receivewal tried to simplify the logic of information to
> > return, by using a dedicated struct for this. This accounts for Bahrath's
> > demands to
> If DeleteFile() is automatically using
> FILE_DISPOSITION_POSIX_SEMANTICS by default when possible on recent
> releases as per the SO link that Andres posted above ("18363.657
> definitely has the new behavior"), then that's great news and maybe we
> shouldn't even bother to try to request that
91 matches
Mail list logo
