On Tue, Jan 26, 2021 at 1:27 PM Fujii Masao wrote:
> > Yes, so I pushed that change to stabilize the regression test.
> > Let's keep checking how the results of buildfarm members are changed.
Sorry, I'm unfamiliar with checking the system status on the build
farm website -
On 2021/01/26 17:07, Bharath Rupireddy wrote:
On Tue, Jan 26, 2021 at 1:27 PM Fujii Masao wrote:
Yes, so I pushed that change to stabilize the regression test.
Let's keep checking how the results of buildfarm members are changed.
Sorry, I'm unfamiliar with checking the system status on
On Tue, Jan 26, 2021 at 1:55 PM Fujii Masao wrote:
> Thanks for the patch! I also created that patch, confirmed that the test
> successfully passed with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS,
> and pushed the patch.
Thanks a lot!
With Regards,
Bharath Rupireddy.
EnterpriseDB:
Dear everyone,
I'm sorry for the late reply. I rebase my two patchsets onto the latest
master 411ae64.The one patchset prefixed with v4 is for non-volatile WAL
buffer; the other prefixed with v3 is for msync.
I will reply to your thankful feedbacks one by one within days. Please wait
for a
On 26/01/2021 06:46, Kyotaro Horiguchi wrote:
Looking the comment of SharedFileSetOnDetach:
| * everything in them. We can't raise an error on failures, because this runs
| * in error cleanup paths.
I feel that a function that shouldn't error-out also shouldn't be
cancellable. If that's the
On Mon, Jan 25, 2021 at 6:39 AM Kyotaro Horiguchi
wrote:
>
> Sorry for the dealy. I started to look this.
>
> At Fri, 25 Sep 2020 12:25:24 +0300, Surafel Temesgen
> wrote in
> > Hi Michael
> > On Thu, Sep 24, 2020 at 6:58 AM Michael Paquier wrote:
> >
> > > On Mon, Aug 10, 2020 at 01:23:44PM
> On 26 Jan 2021, at 04:28, Noah Misch wrote:
>
> On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
>> SHA-1 is now an option available for cryptohashes, and like the
>> existing set of functions of SHA-2, I don't really see a reason why we
>> should not have a SQL function for
Hi,
On 19/11/2020 07:25, Kyotaro Horiguchi wrote:
Performance measurement on the attached showed better result about
searching but maybe worse for cache entry creation. Each time number
is the mean of 10 runs.
# Cacache (negative) entry creation
: time(ms) (% to master)
master
Dear everyone, Tomas,
First of all, the "v4" patchset for non-volatile WAL buffer attached to the
previous mail is actually v5... Please read "v4" as "v5."
Then, to Tomas:
Thank you for your crash report you gave on Nov 27, 2020, regarding msync
patchset. I applied the latest msync patchset v3
On Mon, 2021-01-25 at 11:29 -0500, Dave Cramer wrote:
> Rebased against head
>
> Here's my summary of the long thread above.
>
> This change is in keeping with the SQL spec.
>
> There is an argument (Tom) that says that this will annoy more people than it
> will please.
> I presume this is
Hi,
When I read the documentation of ALTER SUBSCRIPTION ... SET PUBLICATION ...
WITH (...),
it says "set_publication_option" only support "refresh" in documentation [1].
However, we can also supply the "copy_data" option, and the code is:
case ALTER_SUBSCRIPTION_PUBLICATION:
Hello Joel,
Thank you for your kind words and happy that you benefited from this patch.
We simply assert that the update/delete method used is supported currently
only "NO ACTION" and "RESTRICT", this can be extended in future patches
without rework, just extra logic.
Please don't hesitate to
On Tue, Jan 26, 2021 at 7:06 PM Laurenz Albe wrote:
>
> On Mon, 2021-01-25 at 11:29 -0500, Dave Cramer wrote:
> > Rebased against head
> >
> > Here's my summary of the long thread above.
> >
> > This change is in keeping with the SQL spec.
> >
> > There is an argument (Tom) that says that this
> On 20 Jan 2021, at 20:07, Jacob Champion wrote:
>
> On Mon, 2021-01-18 at 11:23 +0100, Daniel Gustafsson wrote:
>> + /* use commas instead of slashes */
>> + X509_NAME_print_ex(bio, x509name, 0, XN_FLAG_SEP_COMMA_PLUS);
>> I don't have strong opinions on whether we
On 1/11/21 3:02 PM, Simon Riggs wrote:
> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
I'm still in the weeds of reviewing this patch, but why should this
fail? It should not fail.
--
Vik Fearing
Le mar. 26 janv. 2021 à 05:10, Julien Rouhaud a écrit :
> On Mon, Jan 25, 2021 at 9:34 PM Guillaume Lelarge
> wrote:
> >
> > "Anytime soon" was a long long time ago, and I eventually completely
> forgot this, sorry. As nobody worked on it yet, I took a shot at it. See
> attached patch.
>
>
> I think we can allow parallel insert in this case, because the column value
> is determined according to the DEFAULT definition of the target table
> specified in the INSERT statement. This is described here:
>
> https://www.postgresql.org/docs/devel/sql-createtable.html
>
> "Defaults may be
On Tue, 26 Jan 2021 at 13:46, japin wrote:
> Hi, Bharath
>
> Thanks for your reviewing.
>
> On Tue, 26 Jan 2021 at 12:55, Bharath Rupireddy
> wrote:
>> On Tue, Jan 26, 2021 at 9:25 AM japin wrote:
>>> > I think it's more convenient. Any thoughts?
>>>
>>> Sorry, I forgot to attach the patch.
At Tue, 26 Jan 2021 11:00:56 +0200, Heikki Linnakangas wrote
in
> On 26/01/2021 06:46, Kyotaro Horiguchi wrote:
> > Looking the comment of SharedFileSetOnDetach:
> > | * everything in them. We can't raise an error on failures, because this
> > | * runs
> > | * in error cleanup paths.
> > I
Hi Mark,
On Mon, Jan 25, 2021, at 09:14, Joel Jacobson wrote:
> I'll continue testing over the next couple of days and report if I find any
> more oddities.
I've continued testing by trying to make full use of this feature in the
catalog-diff-tool I'm working on.
Today I became aware of a SQL
Le mar. 26 janv. 2021 à 13:41, Guillaume Lelarge a
écrit :
> Le mar. 26 janv. 2021 à 05:10, Julien Rouhaud a
> écrit :
>
>> On Mon, Jan 25, 2021 at 9:34 PM Guillaume Lelarge
>> wrote:
>> >
>> > "Anytime soon" was a long long time ago, and I eventually completely
>> forgot this, sorry. As
On 1/26/21 1:16 PM, Simon Riggs wrote:
> On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing wrote:
>>
>> On 1/11/21 3:02 PM, Simon Riggs wrote:
>>> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
>>
>> I'm still in the weeds of reviewing this patch, but why should this
>>
On Tue, Jan 26, 2021 at 12:51 PM Vik Fearing wrote:
>
> On 1/26/21 1:16 PM, Simon Riggs wrote:
> > On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing
> > wrote:
> >>
> >> On 1/11/21 3:02 PM, Simon Riggs wrote:
> >>> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently
> >>> doesn't
>
On Tue, 26 Jan 2021 at 06:59, Masahiko Sawada wrote:
> On Tue, Jan 26, 2021 at 7:06 PM Laurenz Albe
> wrote:
> >
> > On Mon, 2021-01-25 at 11:29 -0500, Dave Cramer wrote:
> > > Rebased against head
> > >
> > > Here's my summary of the long thread above.
> > >
> > > This change is in keeping
On 1/2/21, 8:55 AM, "Andrey Borodin" wrote:
> Recently we had somewhat related incident. Do I understand correctly that
> this incident is related to the bug discussed in this thread?
I'm not sure that we can rule it out, but the log pattern I've
typically seen for this is "invalid contrecord
On Mon, Jan 25, 2021 at 4:40 PM Bruce Momjian wrote:
>
> On Sun, Jan 24, 2021 at 02:20:58PM +0100, Magnus Hagander wrote:
> > While at it, what point is "codelines" adding?
>
> That is the script I use to generate code line counts when comparing
> releases. I thought it should be in the tree so
On 13/01/2021 23:17, Stephen Frost wrote:
Would be great to get a review / comments from others as to if there's
any concerns. I'll admit that it seems reasonably straight-forward to
me, but hey, I wrote most of it, so that's not really a fair
assessment... ;)
Look good overall. A few minor
On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing wrote:
>
> On 1/11/21 3:02 PM, Simon Riggs wrote:
> > * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
>
> I'm still in the weeds of reviewing this patch, but why should this
> fail? It should not fail.
It should not be
On Fri, Oct 30, 2020 at 6:26 PM Heikki Linnakangas wrote:
> Yeah, you need to access the old tuple to update its t_ctid, but
> accessing it twice is still more expensive than accessing it once. Maybe
> you could optimize it somewhat by keeping the buffer pinned or
> something. Or push the
On 2021-Jan-20, Robert Haas wrote:
> On Wed, Jan 20, 2021 at 1:54 PM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Well, the patch seems small enough, and I don't think it'll be in any
> > > way helpful to omit that detail.
> >
> > I'm +1 for applying and back-patching that. I still think
On Wed, Jan 27, 2021 at 12:22 AM Kyotaro Horiguchi
wrote:
> At Tue, 26 Jan 2021 11:00:56 +0200, Heikki Linnakangas
> wrote in
> > Don't we potentially have the same problem with all on_dsm_detach
> > callbacks? Looking at the other on_dsm_detach callbacks, I don't see
> > any
On Tue, Jan 26, 2021 at 6:58 PM Bruce Momjian wrote:
>
> On Tue, Jan 26, 2021 at 05:03:30PM +0100, Magnus Hagander wrote:
> > On Mon, Jan 25, 2021 at 4:38 PM Bruce Momjian wrote:
> > >
> > > On Fri, Jan 22, 2021 at 01:07:36PM -0500, Tom Lane wrote:
> > > > > There's also src/tools/make_mkid
On Fri, Jan 22, 2021 at 10:59 PM Tomas Vondra
wrote:
>
>
> On 1/23/21 12:27 AM, John Naylor wrote:
> > Still, it would be great if multi-minmax can be a drop in replacement. I
> > know there was a sticking point of a distance function not being
> > available on all types, but I wonder if that
On Mon, Jan 25, 2021 at 10:48 PM Amit Kapila wrote:
> I need to spend more time on benchmarking to study the behavior and I
> think without that it would be difficult to make a conclusion in this
> regard. So, let's not consider any action on this front till I spend
> more time to find the
On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
> Reading more on this it seems we would essentially have to go with RFC 4514,
> as
> it's the closest to a standard which seems to exist. Having done a lot
> research on this topic, do you have a gut feeling on direction?
Yeah, if
I have nothing new to add, but wanted to point out this is still an issue.
This is on the v13 Opened Items list - for lack of anywhere else to put them, I
also added two other, unresolved issues.
https://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items=revision=35624=35352
On Tue,
Hi Tomas,
I took another look through the Bloom opclass portion (0004) with
sorted_mode omitted, and it looks good to me code-wise. I think this part
is close to commit-ready. I also did one more proofreading pass for
minor details.
+ rows per block). The default values is -0.1, and
+
On 12/17/20, 9:15 PM, "Kyotaro Horiguchi" wrote:
> At Thu, 17 Dec 2020 22:20:35 +, "Bossart, Nathan"
> wrote in
>> On 12/15/20, 2:33 AM, "Kyotaro Horiguchi" wrote:
>> > You're right in that regard. There's a window where partial record is
>> > written when write location passes F0 after
On Tue, Jan 26, 2021 at 11:15 AM Bruce Momjian wrote:
> This version fixes OpenSSL detection and improves docs for initdb
> interactions.
Hi,
I'm wondering whether you've considered storing all the keys in one
file instead of a file per key. The reason I ask is that it seems to
me that the key
On Mon, Jan 25, 2021 at 4:38 PM Bruce Momjian wrote:
>
> On Fri, Jan 22, 2021 at 01:07:36PM -0500, Tom Lane wrote:
> > > There's also src/tools/make_mkid which use this mkid tool. +1 for
> > > removing.
> > > If anything, it seems better replaced by extended documentation on the
> > > existing
On Tue, 26 Jan 2021 at 05:05, Laurenz Albe wrote:
> On Mon, 2021-01-25 at 11:29 -0500, Dave Cramer wrote:
> > Rebased against head
> >
> > Here's my summary of the long thread above.
> >
> > This change is in keeping with the SQL spec.
> >
> > There is an argument (Tom) that says that this will
On Tue, Jan 26, 2021 at 05:03:30PM +0100, Magnus Hagander wrote:
> On Mon, Jan 25, 2021 at 4:38 PM Bruce Momjian wrote:
> >
> > On Fri, Jan 22, 2021 at 01:07:36PM -0500, Tom Lane wrote:
> > > > There's also src/tools/make_mkid which use this mkid tool. +1 for
> > > > removing.
> > > > If
On Mon, Jan 25, 2021 at 2:39 PM Kyotaro Horiguchi
wrote:
> Sorry for the dealy. I started to look this.
>
>
Hi kyotaro,
Thanks for looking into this but did we agree to proceed
on this approach? I fear that it will be the west of effort if
Andrew comes up with the patch for his approach.
Andrew
On Tue, 2021-01-26 at 11:09 -0500, Dave Cramer wrote:
> On Tue, 26 Jan 2021 at 05:05, Laurenz Albe wrote:
>
> > I wonder about the introduction of the new USER_ERROR level:
> >
> > #define WARNING_CLIENT_ONLY20 /* Warnings to be sent to client as
> > usual, but
> >
On Tue, 26 Jan 2021 at 12:20, Laurenz Albe wrote:
> On Tue, 2021-01-26 at 11:09 -0500, Dave Cramer wrote:
> > On Tue, 26 Jan 2021 at 05:05, Laurenz Albe
> wrote:
> >
> > > I wonder about the introduction of the new USER_ERROR level:
> > >
> > > #define WARNING_CLIENT_ONLY20 /* Warnings to
On Thu, Jan 21, 2021 at 3:08 PM Matthias van de Meent
wrote:
> Re-thinking this, and after some research:
>
> Is the behaviour of "any process that invalidates TIDs in this table
> (that could be in an index on this table) always holds a lock that
> conflicts with CIC/RiC on that table" a
On 1/26/21 6:34 PM, Vik Fearing wrote:
> On 1/26/21 6:20 PM, Laurenz Albe wrote:
>> After thinking some more about it, I think that COMMIT AND CHAIN would have
>> to change behavior: if COMMIT throws an error (because the transaction was
>> aborted), no new transaction should be started.
On Tue, 2021-01-26 at 12:25 -0500, Dave Cramer wrote:
> > After thinking some more about it, I think that COMMIT AND CHAIN would have
> > to change behavior: if COMMIT throws an error (because the transaction was
> > aborted), no new transaction should be started. Everything else seems
> >
On Mon, Jan 25, 2021 at 11:56 PM Masahiro Ikeda
wrote:
>
> > (wal_write)
> > The number of times WAL buffers were written out to disk via XLogWrite
> >
>
> Thanks.
>
> I thought it's better to omit "The" and "XLogWrite" because other views'
> description
> omits "The" and there is no description
On 1/26/21 6:20 PM, Laurenz Albe wrote:
> After thinking some more about it, I think that COMMIT AND CHAIN would have
> to change behavior: if COMMIT throws an error (because the transaction was
> aborted), no new transaction should be started. Everything else seems fishy:
> the statement fails,
On Tue, 26 Jan 2021 at 12:46, Laurenz Albe wrote:
> On Tue, 2021-01-26 at 12:25 -0500, Dave Cramer wrote:
> > > After thinking some more about it, I think that COMMIT AND CHAIN would
> have
> > > to change behavior: if COMMIT throws an error (because the transaction
> was
> > > aborted), no new
On Mon, Jan 25, 2021 at 4:48 PM Amit Kapila wrote:
>
> On Mon, Jan 25, 2021 at 8:03 AM Peter Smith wrote:
> >
> > Hi Amit.
> >
> > PSA the v19 patch for the Tablesync Solution1.
> >
>
> I see one race condition in this patch where we try to drop the origin
> via apply process and
At Thu, 14 Jan 2021 17:32:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> The commit 4656e3d668 (debug_invalidate_system_caches_always)
> conflicted with this patch. Rebased.
At Wed, 27 Jan 2021 10:07:47 +0900 (JST), Kyotaro Horiguchi
wrote in
> (I found a bug in a benchmark-aid function
>
On 2021-01-26 09:58, Michael Paquier wrote:
On Mon, Jan 25, 2021 at 11:11:38PM +0300, Alexey Kondratov wrote:
I updated comment with CCI info, did pgindent run and renamed new
function
to SetRelationTableSpace(). New patch is attached.
[...]
Yeah, all these checks we complicated from the
On Tue, Jan 26, 2021 at 11:29 AM Masahiko Sawada wrote:
> > IMHO, adding an assertion in SearchCatCacheInternal(which is a most
> > generic code part within the server) with a few error context global
> > variables may not be always safe. Because we might miss using the
> > error context
On 22/01/2021 14:21, Heikki Linnakangas wrote:
On 22/01/2021 13:55, Heikki Linnakangas wrote:
I read through the latest patch,
v31-0001-Support-checksum-enable-disable-in-a-running-clu.patch. Some
comments below:
One more thing:
In SetRelationNumChecks(), you should use SearchSysCacheCopy1()
On Tue, Jan 26, 2021 at 10:19:44PM +0100, Magnus Hagander wrote:
> On Mon, Jan 25, 2021 at 4:40 PM Bruce Momjian wrote:
> >
> > On Sun, Jan 24, 2021 at 02:20:58PM +0100, Magnus Hagander wrote:
> > > While at it, what point is "codelines" adding?
> >
> > That is the script I use to generate code
Hi Amit-san,
On 2021/01/25 18:19, Amit Langote wrote:
On Mon, Jan 25, 2021 at 9:24 AM Corey Huinker wrote:
On Sun, Jan 24, 2021 at 6:51 AM Amit Langote wrote:
Here's v5.
v5 patches apply to master.
Suggested If/then optimization is implemented.
Suggested case merging is implemented.
I've created a new page, and added some unresolved items that I've been keeping
in my head.
https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items
Hi Hackers.
As discovered elsewhere [ak0125] there is a potential race condition
in the pg_replication_origin_drop API
The current code of pg_replication_origin_drop looks like:
roident = replorigin_by_name(name, false);
Assert(OidIsValid(roident));
replorigin_drop(roident, true);
On Tue, Jan 26, 2021 at 8:38 AM Bharath Rupireddy
wrote:
> I will post "keep_connections" GUC and "keep_connection" server level
> option patches later.
Attaching v19 patch set for "keep_connections" GUC and
"keep_connection" server level option. Please review them further.
With Regards,
Justin Pryzby writes:
> I have nothing new to add, but wanted to point out this is still an issue.
> This is on the v13 Opened Items list - for lack of anywhere else to put them,
> I
> also added two other, unresolved issues.
It's probably time to make a v14 open items page, and move anything
Alvaro Herrera writes:
> pgbench has one occurrence of the old pattern in master, in line 6043.
> However, since doConnect() returns NULL when it gets CONNECTION_BAD,
> that seems dead code. This patch kills it.
Oh ... I missed that because it wasn't adjacent to the PQconnectdbParams
call :-(.
On 1/26/21 7:52 PM, John Naylor wrote:
On Fri, Jan 22, 2021 at 10:59 PM Tomas Vondra
mailto:tomas.von...@enterprisedb.com>>
wrote:
>
>
> On 1/23/21 12:27 AM, John Naylor wrote:
> > Still, it would be great if multi-minmax can be a drop in
replacement. I
> > know there was a sticking
At Tue, 26 Jan 2021 11:43:21 +0200, Heikki Linnakangas wrote
in
> Hi,
>
> On 19/11/2020 07:25, Kyotaro Horiguchi wrote:
> > Performance measurement on the attached showed better result about
> > searching but maybe worse for cache entry creation. Each time number
> > is the mean of 10 runs.
>
On Wed, Jan 27, 2021 at 6:06 PM Michael Paquier wrote:
> On Wed, Jan 27, 2021 at 04:13:24PM +1300, Thomas Munro wrote:
> > I would like to commit this, because "waiting restore commands" have
> > confusing interactions with my proposed prefetching-during-recovery
> > patch[1]. Here's a version
At Wed, 27 Jan 2021 05:30:29 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Kyotaro Horiguchi
> > "CREATE TABLE" is not "CREATE LOGGED TABLE". We can assume that as
> > "CREATE TABLE", where the default logged-ness
> > varies according to context. Or it might have been so since the
On Wed, Jan 27, 2021 at 05:57:06AM +, Hou, Zhijie wrote:
>> Combocid's ==>> Combocids
>
> Ping again, just in case it’s missed.
There are in the comments "ComboCIDs", "combocids" and "ComboCids" on
top of the existing Combocid's. Your patch introduces a fourth way of
writing that. It may
Hi Amit-san,
+ case TM_Invisible:
+ elog(ERROR, "attempted to lock invisible tuple");
+ break;
+
+ case TM_SelfModified:
+ case TM_BeingModified:
+ case TM_WouldBlock:
+ elog(ERROR, "unexpected table_tuple_lock
> >> Combocid's ==>> Combocids
> >
> > Ping again, just in case it’s missed.
>
> There are in the comments "ComboCIDs", "combocids" and "ComboCids" on top
> of the existing Combocid's. Your patch introduces a fourth way of writing
> that. It may be better to just have one way to govern them
On Tue, Jan 26, 2021 at 2:00 AM Robert Haas wrote:
>
> On Sat, Jan 23, 2021 at 6:10 AM Bharath Rupireddy
> wrote:
> > +1 to just show the recovery pause state in the output of
> > pg_is_wal_replay_paused. But, should the function name
> > "pg_is_wal_replay_paused" be something like
> >
On Wed, Jan 20, 2021 at 05:07:08PM +, Jacob Champion wrote:
> Lovely. I didn't expect *removing* an extension to effectively *add*
> more, but I'm glad it works now.
My apologies for chiming in. I was looking at your patch set here,
and while reviewing the strong random and cryptohash parts
From: Kyotaro Horiguchi
> "CREATE TABLE" is not "CREATE LOGGED TABLE". We can assume that as
> "CREATE TABLE", where the default logged-ness
> varies according to context. Or it might have been so since the beginning.
> Currently we don't have the syntax "CREATE LOGGED TABLE", but we can add
>
On Sat, Jan 23, 2021 at 07:15:40PM +0900, Michael Paquier wrote:
> I have been looking at 0005, the patch dealing with the docs of the
> replication stats, and have some comments.
And attached is a patch to clarify all that. I am letting that sleep
for a couple of days for now, so please let me
> I found a possible typo in reorderbuffer.c
>
> * has got a combocid. Combocid's are only valid for the duration
> of a
>
> Combocid's ==>> Combocids
>
> Attatching a small patch to correct it.
>
Ping again, just in case it’s missed.
On Fri, Jan 22, 2021 at 2:00 PM Peter Geoghegan wrote:
>
> On Tue, Jan 19, 2021 at 2:57 PM Peter Geoghegan wrote:
> > Looks good. I'll give this version a review now. I will do a lot more
> > soon. I need to come up with a good benchmark for this, that I can
> > return to again and again during
On Sat, Jan 16, 2021 at 1:39 AM Zhihong Yu wrote:
>
> Hi,
Thank you for reviewing the patch!
> For v32-0004-Add-PrepareForeignTransaction-API.patch :
>
> + * Whenever a foreign transaction is processed, the corresponding FdwXact
> + * entry is update. To avoid holding the lock during
On Mon, 25 Jan 2021 16:27:25 +0300
Konstantin Knizhnik wrote:
> Hello,
>
> Thank you for review.
> My answers are inside.
Thank you for updating the patch and answering my questions.
> > (2)
> > If I understand correctly, your proposal consists of the following two
> > features.
> >
> > 1.
Yamada-san,
On Wed, Jan 27, 2021 at 8:51 AM Tatsuro Yamada
wrote:
> On 2021/01/25 18:19, Amit Langote wrote:
> > On Mon, Jan 25, 2021 at 9:24 AM Corey Huinker
> > wrote:
> >> Anybody else want to look this patch over before I mark it Ready For
> >> Committer?
> >
> > Would be nice to have
Hi,
${subject} happened while executing ${attached query} at regresssion
database, using 14dev (commit
d5a83d79c9f9b660a6a5a77afafe146d3c8c6f46) and produced ${attached
stack trace}.
Sadly just loading the regression database and executing this query is
not enough to reproduce. Not sure what
On Tue, Jan 26, 2021 at 10:52 PM Jaime Casanova
wrote:
> ${subject} happened while executing ${attached query} at regresssion
> database, using 14dev (commit
> d5a83d79c9f9b660a6a5a77afafe146d3c8c6f46) and produced ${attached
> stack trace}.
I see the bug: gistprunepage() calls
On 2021/01/18 14:54, Masahiko Sawada wrote:
On Fri, Jan 15, 2021 at 7:45 AM Zhihong Yu wrote:
For v32-0002-postgres_fdw-supports-commit-and-rollback-APIs.patch :
+ entry->changing_xact_state = true;
...
+ entry->changing_xact_state = abort_cleanup_failure;
I don't see return
On Sat, Jan 23, 2021 at 5:56 PM Amit Kapila wrote:
>
> On Sat, Jan 23, 2021 at 4:55 AM Peter Smith wrote:
> >
> > PSA the v18 patch for the Tablesync Solution1.
>
> 7. Have you tested with the new patch the scenario where we crash
> after FINISHEDCOPY and before SYNCDONE, is it able to pick up
On Wed, Jan 27, 2021 at 7:48 AM Zhihong Yu wrote:
> For 0002, a few comments on the description:
>
> bq. Avoid accessing system catalogues inside conversion_error_callback
>
> catalogues -> catalog
>
> bq. error context callback, because the the entire transaction might
>
> There is redundant
On Sat, Dec 5, 2020 at 7:27 AM Stephen Frost wrote:
> * Thomas Munro (thomas.mu...@gmail.com) wrote:
> > I just noticed this thread proposing to retire pg_standby on that
> > basis:
> >
> > https://www.postgresql.org/message-id/flat/20201029024412.GP5380%40telsasoft.com
> >
> > I'd be happy to
On Tue, Jan 26, 2021 at 10:38:43AM +0100, Daniel Gustafsson wrote:
> Agreed, and pgcrypto already allows for using sha1.
>
> It seems like any legitimate need for sha1 could be better served by an
> extension rather than supplying it in-core.
Both of you telling the same thing is enough for me
For 0002, a few comments on the description:
bq. Avoid accessing system catalogues inside conversion_error_callback
catalogues -> catalog
bq. error context callback, because the the entire transaction might
There is redundant 'the'
bq. Since get_attname() and get_rel_name() could search the
On Tue, Jan 26, 2021 at 8:53 PM Michael Paquier wrote:
> On Tue, Jan 26, 2021 at 10:38:43AM +0100, Daniel Gustafsson wrote:
> > Agreed, and pgcrypto already allows for using sha1.
> >
> > It seems like any legitimate need for sha1 could be better served by an
> > extension rather than supplying
On Tue, Jan 26, 2021, at 12:59, Mark Rofail wrote:
> Please don't hesitate to give your feedback.
The error message for insert or update violations looks fine:
UPDATE catalog_clone.pg_extension SET extconfig = ARRAY[12345] WHERE oid = 10;
ERROR: insert or update on table "pg_extension" violates
On Wed, Jan 27, 2021 at 01:00:50AM +0300, Alexey Kondratov wrote:
> CheckRelationTableSpaceMove() does not feel like a right place for invoking
> post alter hooks. It is intended only to check for tablespace change
> possibility. Anyway, ATExecSetTableSpace() and
> ATExecSetTableSpaceNoStorage()
On Tue, Jan 26, 2021 at 03:55:15PM -0600, Justin Pryzby wrote:
> I've created a new page, and added some unresolved items that I've been
> keeping
> in my head.
>
> https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items
Thanks, Justin!
--
Michael
signature.asc
Description: PGP signature
At Tue, 26 Jan 2021 19:13:57 +, "Bossart, Nathan"
wrote in
> On 12/17/20, 9:15 PM, "Kyotaro Horiguchi" wrote:
> > At Thu, 17 Dec 2020 22:20:35 +, "Bossart, Nathan"
> > wrote in
> >> On 12/15/20, 2:33 AM, "Kyotaro Horiguchi" wrote:
> >> > You're right in that regard. There's a window
On Wed, Nov 25, 2020 at 10:04 PM Peter Eisentraut
wrote:
> On 2020-11-21 20:41, Justin Pryzby wrote:
> > Oops. I guess I'd write something like this. If we just remove it, then
> > there'd no place to add a new server application, and "client applications"
> > would be the only subsection.
>
>
Hi,
When testing the patch with the following kind of sql.
---
Insert into part_table select 1;
Insert into part_table select generate_series(1,1,1);
Insert into part_table select * from testfunc();
---
we usually use these sqls to initialize the table or for testing purpose.
Personally I
On Wed, Jan 27, 2021 at 04:13:24PM +1300, Thomas Munro wrote:
> I would like to commit this, because "waiting restore commands" have
> confusing interactions with my proposed prefetching-during-recovery
> patch[1]. Here's a version that fixes an error when building the docs
> (there was a stray
Hi Amit-san,
Thanks for the answer!
> If you only tested insert/update on the referencing table, I would've
> expected to see nothing in the result of that query, because the patch
> eliminates all use of SPI in that case. I suspect the CachedPlan*
> memory contexts you are seeing belong to
On Wed, Jan 27, 2021 at 12:50 PM Masahiko Sawada wrote:
>
> On Tue, Jan 26, 2021 at 2:00 AM Robert Haas wrote:
> >
> > On Sat, Jan 23, 2021 at 6:10 AM Bharath Rupireddy
> > wrote:
> > > +1 to just show the recovery pause state in the output of
> > > pg_is_wal_replay_paused. But, should the
Hi Bharath,
I choose 5 cases which pick parallel insert plan in CTAS to measure the patched
performance. Each case run 30 times.
Most of the tests execution become faster with this patch.
However, Test NO 4(create table xxx as table xxx.) appears performance
degradation. I tested various
98 matches
Mail list logo
