On Fri, 24 May 2024 at 00:09, Kyotaro Horiguchi wrote:
> Along with rebasing, I changed the interface of XLogFsyncFile() to
> return a boolean instead of an error message.
Two notes after looking at this quickly during the advanced patch
feedback session:
1. I would maybe split 0003 into two
Rebased.
Along with rebasing, I changed the interface of XLogFsyncFile() to
return a boolean instead of an error message.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From bed74e638643d7491bbd86fe640c33db1e16f0e5 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Mon, 15
At Mon, 22 Jan 2024 15:36:31 +1100, Peter Smith wrote
in
> 2024-01 Commitfest.
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there was a CFbot test failure last time it was run [2]. Please have a
> look and post an updated version if necessary.
Thanks! I have added
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there was a CFbot test failure last time it was run [2]. Please have a
look and post an updated version if necessary.
==
[1] https://commitfest.postgresql.org/46/3461/
[2]
At Tue, 9 Jan 2024 15:07:20 +0530, vignesh C wrote in
> CFBot shows compilation issues at [1] with:
Thanks!
The reason for those errors was that I didn't consider Meson at the
time. Additionally, the signature change of reindex_index() caused the
build failure. I fixed both issues. While
On Mon, 4 Sept 2023 at 16:59, Kyotaro Horiguchi wrote:
>
> At Thu, 24 Aug 2023 11:22:32 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I could turn this into something like undo longs in a simple form, but
> > I'd rather not craft a general-purpose undo log system for this unelss
> > it's
At Thu, 24 Aug 2023 11:22:32 +0900 (JST), Kyotaro Horiguchi
wrote in
> I could turn this into something like undo longs in a simple form, but
> I'd rather not craft a general-purpose undo log system for this unelss
> it's absolutely necessary.
This is a patch for a basic undo log
Thank you for looking this!
At Mon, 14 Aug 2023 12:38:48 -0700, Nathan Bossart
wrote in
> I think there are some good ideas here. I started to take a look at the
> patches, and I've attached a rebased version of the patch set. Apologies
> if I am repeating any discussions from upthread.
>
>
I think there are some good ideas here. I started to take a look at the
patches, and I've attached a rebased version of the patch set. Apologies
if I am repeating any discussions from upthread.
First, I tested the time difference in ALTER TABLE SET UNLOGGED/LOGGED with
the patch applied, and
(I find the misspelled subject makes it difficult to find the thread..)
At Thu, 27 Apr 2023 14:47:41 +0200, Jakub Wartak
wrote in
> On Tue, Apr 25, 2023 at 9:55 AM Kyotaro Horiguchi
> wrote:
> >
> > Rebased.
> >
> > I fixed some code comments and commit messages. I fixed the wrong
> >
On Tue, Apr 25, 2023 at 9:55 AM Kyotaro Horiguchi
wrote:
>
> Rebased.
>
> I fixed some code comments and commit messages. I fixed the wrong
> arrangement of some changes among patches. Most importantly, I fixed
> the a bug based on a wrong assumption that init-fork is not resides on
> shared
At Fri, 17 Mar 2023 15:16:34 +0900 (JST), Kyotaro Horiguchi
wrote in
> Mmm. It took longer than I said, but this is the patch set that
> includes all three parts.
>
> 1. "Mark files" to prevent orphan storage files for in-transaction
> created relations after a crash.
>
> 2. In-place
At Fri, 03 Mar 2023 18:03:53 +0900 (JST), Kyotaro Horiguchi
wrote in
> Correctly they are three parts. The attached patch is the first part -
> the storage mark files, which are used to identify storage files that
> have not been committed and should be removed during the next
> startup. This
At Wed, 1 Mar 2023 14:56:25 -0500, "Gregory Stark (as CFM)"
wrote in
> On Mon, 6 Feb 2023 at 23:48, Kyotaro Horiguchi
> wrote:
> >
> > Thank you for the comment!
> >
> > At Fri, 3 Feb 2023 08:42:52 +0100, Heikki Linnakangas
> > wrote in
> > > I want to call out this part of this patch:
>
>
On Mon, 6 Feb 2023 at 23:48, Kyotaro Horiguchi wrote:
>
> Thank you for the comment!
>
> At Fri, 3 Feb 2023 08:42:52 +0100, Heikki Linnakangas wrote
> in
> > I want to call out this part of this patch:
Looks like this patch has received some solid feedback from Heikki and
you have a path
Thank you for the comment!
At Fri, 3 Feb 2023 08:42:52 +0100, Heikki Linnakangas wrote
in
> I want to call out this part of this patch:
>
> > Also this allows for the cleanup of files left behind in the crash of
> > the transaction that created it.
>
> This is interesting to a lot wider
I want to call out this part of this patch:
Also this allows for the cleanup of files left behind in the crash of
the transaction that created it.
This is interesting to a lot wider audience than ALTER TABLE SET
LOGGED/UNLOGGED. It also adds most of the complexity, with the new
marker
At Tue, 08 Nov 2022 11:33:53 +0900 (JST), Kyotaro Horiguchi
wrote in
> Indeed, thanks! I'll do that in a few days.
Got too late, but rebased.. The contents of the two patches in the
last version was a bit shuffled but they are fixed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software
At Fri, 4 Nov 2022 09:32:52 +0900, Ian Lawrence Barwick
wrote in
> cfbot reports the patch no longer applies. As CommitFest 2022-11 is
> currently underway, this would be an excellent time to update the patch.
Indeed, thanks! I'll do that in a few days.
regards.
--
Kyotaro Horiguchi
NTT
2022年9月28日(水) 17:21 Kyotaro Horiguchi :
>
> Just rebased.
Hi
cfbot reports the patch no longer applies. As CommitFest 2022-11 is
currently underway, this would be an excellent time to update the patch.
Thanks
Ian Barwick
Just rebased.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 8c0d5bd7b519149059d1b2b86a93ffe509e09b9b Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Tue, 19 Jul 2022 13:23:01 +0900
Subject: [PATCH v24 1/2] In-place table persistence change
Even though ALTER TABLE
(Mmm. I haven't noticed an annoying misspelling in the subejct X( )
> Thank you for checking that! It got a wider attack by b0a55e4329
> (RelFileNumber). The commit message suggests "relfilenode" as files
Then, now I stepped on my own foot. Rebased also on nodefuncs
autogeneration.
regards.
At Wed, 6 Jul 2022 08:44:18 -0700, Jacob Champion
wrote in
> On Thu, Mar 31, 2022 at 2:36 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 31 Mar 2022 18:33:18 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> > > I don't think this can be commited to 15. So I post the fixed version
> > > then move
On Thu, Mar 31, 2022 at 2:36 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 31 Mar 2022 18:33:18 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I don't think this can be commited to 15. So I post the fixed version
> > then move this to the next CF.
>
> Then done. Thanks!
Hello! This patchset will need
At Thu, 31 Mar 2022 18:33:18 +0900 (JST), Kyotaro Horiguchi
wrote in
> I don't think this can be commited to 15. So I post the fixed version
> then move this to the next CF.
Then done. Thanks!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Thu, 31 Mar 2022 00:37:07 -0500, Justin Pryzby wrote
in
> On Thu, Mar 31, 2022 at 01:58:45PM +0900, Kyotaro Horiguchi wrote:
> > Thanks! Version 20 is attached.
>
> The patch failed an all CI tasks, and seems to have caused the macos task to
> hang.
>
>
On Thu, Mar 31, 2022 at 01:58:45PM +0900, Kyotaro Horiguchi wrote:
> Thanks! Version 20 is attached.
The patch failed an all CI tasks, and seems to have caused the macos task to
hang.
http://cfbot.cputube.org/kyotaro-horiguchi.html
Would you send a fixed patch, or remove this thread from the
Thanks! Version 20 is attached.
At Wed, 30 Mar 2022 08:44:02 -0500, Justin Pryzby wrote
in
> On Tue, Mar 01, 2022 at 02:14:13PM +0900, Kyotaro Horiguchi wrote:
> > Rebased on a recent xlog refactoring.
>
> It'll come as no surprise that this neds to be rebased again.
> At least a few typos I
On Tue, Mar 01, 2022 at 02:14:13PM +0900, Kyotaro Horiguchi wrote:
> Rebased on a recent xlog refactoring.
It'll come as no surprise that this neds to be rebased again.
At least a few typos I reported in January aren't fixed.
Set to "waiting".
At Tue, 01 Mar 2022 14:14:13 +0900 (JST), Kyotaro Horiguchi
wrote in
> - Removed the default case in smgr_desc since it seems to me we don't
> assume out-of-definition values in xlog records elsewhere.
Stupid. The complier on the CI environemnt complains for
uninitialized variable even
Rebased on a recent xlog refactoring.
No functional changes have been made.
- Removed the default case in smgr_desc since it seems to me we don't
assume out-of-definition values in xlog records elsewhere.
- Simplified some added to storage.c.
- Fix copy-pasto'ed comments in extractPageInfo().
At Tue, 18 Jan 2022 10:37:53 -0500, Tom Lane wrote in
> Julien Rouhaud writes:
> > The cfbot is failing on all OS with this version of the patch. Apparently
> > v16-0002 introduces some usage of "testtablespace" client-side variable
> > that's
> > never defined, e.g.
>
> That test
Julien Rouhaud writes:
> The cfbot is failing on all OS with this version of the patch. Apparently
> v16-0002 introduces some usage of "testtablespace" client-side variable that's
> never defined, e.g.
That test infrastructure got rearranged very recently, see d6d317dbf.
Hi,
On Fri, Jan 14, 2022 at 11:43:10AM +0900, Kyotaro Horiguchi wrote:
> I found a bug.
>
> mdmarkexists() didn't close the tentatively opend fd. This is a silent
> leak on Linux and similars and it causes delete failure on Windows.
> It was the reason of the CI failure.
>
>
I found a bug.
mdmarkexists() didn't close the tentatively opend fd. This is a silent
leak on Linux and similars and it causes delete failure on Windows.
It was the reason of the CI failure.
027_persistence_change.pl uses interactive_psql() that doesn't work on
the Windos VM on the CI.
In this
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I've retested v15 of the patch with everything that came to my
At Thu, 06 Jan 2022 16:39:21 +0900 (JST), Kyotaro Horiguchi
wrote in
> Fantastic! I'll give it a try. Thanks!
I did that and found that the test stumbled on newlines.
Tests succeeded for other than Windows.
Windows version fails for a real known issue.
[7916][postmaster] LOG: received
At Wed, 05 Jan 2022 20:42:32 -0800, Andres Freund wrote in
> Hi,
>
> On January 5, 2022 8:30:17 PM PST, Kyotaro Horiguchi
> wrote:
> >I'm still not sure the reason the test item failed but I repost the
> >updated version then watch what the CI says.
>
> Fwiw, you can now test the same way
Hi,
On January 5, 2022 8:30:17 PM PST, Kyotaro Horiguchi
wrote:
>At Tue, 4 Jan 2022 16:05:08 -0800, Andres Freund wrote in
>> The tap tests seems to fail on all platforms. See
>> https://cirrus-ci.com/build/4911549314760704
>>
>> E.g. the linux failure is
>>
>> [16:45:15.569]
>>
At Tue, 4 Jan 2022 16:05:08 -0800, Andres Freund wrote in
> The tap tests seems to fail on all platforms. See
> https://cirrus-ci.com/build/4911549314760704
>
> E.g. the linux failure is
>
> [16:45:15.569]
> [16:45:15.569] # Failed test 'inserted'
> [16:45:15.569] # at
On 2021-12-23 15:33:35 +0900, Kyotaro Horiguchi wrote:
> At Thu, 23 Dec 2021 15:01:41 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I added TAP test to excecise the in-place persistence change.
>
> We don't need a base table for every index. TAP test revised.
The tap tests seems to fail on all
At Thu, 23 Dec 2021 15:01:41 +0900 (JST), Kyotaro Horiguchi
wrote in
> I added TAP test to excecise the in-place persistence change.
We don't need a base table for every index. TAP test revised.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From
At Wed, 22 Dec 2021 08:42:14 +, Jakub Wartak
wrote in
> I think there's slight omission:
...
> apparently reindex_index() params cannot be NULL - the same happens with
> switching persistent
Hmm. a3dc926009 has changed the interface. (But the name is also
changed after that.)
Hi Kyotaro,
> At Tue, 21 Dec 2021 13:07:28 +, Jakub Wartak
> wrote in
> > So what's suspicious is that 122880 -> 0 file size truncation. I've
> > investigated WAL and it seems to contain TRUNCATE records after logged
> FPI images, so when the crash recovery would kick in it probably clears
Hello, Jakub.
At Tue, 21 Dec 2021 13:07:28 +, Jakub Wartak
wrote in
> So what's suspicious is that 122880 -> 0 file size truncation. I've
> investigated WAL and it seems to contain TRUNCATE records
> after logged FPI images, so when the crash recovery would kick in it probably
> clears
Hi Kyotaro,
> I took a bit too long detour but the patch gets to pass make-world for me.
Good news, v10 passes all the tests for me (including TAP recover ones).
There's major problem I think:
drop table t6;
create unlogged table t6 (id bigint, t text);
create sequence s1;
insert into t6
At Tue, 21 Dec 2021 17:13:21 +0900 (JST), Kyotaro Horiguchi
wrote in
> Ugh! I completely forgot about TAP tests.. Thanks for the testing and
> sorry for the bugs.
>
> This is a bit big change so I need a bit of time before posting the
> next version.
I took a bit too long detour but the patch
Ugh! I completely forgot about TAP tests.. Thanks for the testing and
sorry for the bugs.
This is a bit big change so I need a bit of time before posting the
next version.
At Mon, 20 Dec 2021 13:38:35 +, Jakub Wartak
wrote in
> 1) check-worlds seems OK but make -C src/test/recovery check
Hi Kyotaro,
> At Mon, 20 Dec 2021 17:39:27 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Mon, 20 Dec 2021 07:59:29 +, Jakub Wartak
> > wrote in
> > > BTW fast feedback regarding that ALTER patch (there were 4 unlogged
> tables):
> > > # ALTER TABLE ALL IN TABLESPACE tbs1 set logged;
>
At Mon, 20 Dec 2021 17:39:27 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 20 Dec 2021 07:59:29 +, Jakub Wartak
> wrote in
> > BTW fast feedback regarding that ALTER patch (there were 4 unlogged
> > tables):
> > # ALTER TABLE ALL IN TABLESPACE tbs1 set logged;
> > WARNING:
At Mon, 20 Dec 2021 07:59:29 +, Jakub Wartak
wrote in
> Hi Kyotaro, I'm glad you are still into this
>
> > I didn't register for some reasons.
>
> Right now in v8 there's a typo in ./src/backend/catalog/storage.c :
>
> storage.c: In function 'RelationDropInitFork':
> storage.c:385:44:
Hi Kyotaro, I'm glad you are still into this
> I didn't register for some reasons.
Right now in v8 there's a typo in ./src/backend/catalog/storage.c :
storage.c: In function 'RelationDropInitFork':
storage.c:385:44: error: expected statement before ')' token
pending->unlink_forknum !=
At Mon, 20 Dec 2021 15:28:23 +0900 (JST), Kyotaro Horiguchi
wrote in
>
> 4. Including the reasons above, this is not fully functionally.
>For example, if we execute the following commands on primary,
>replica dones't work correctly. (boom!)
>
>=# CREATE UNLOGGED TABLE t (a int);
>
Hello, Jakub.
At Fri, 17 Dec 2021 09:10:30 +, Jakub Wartak
wrote in
> the patch didn't apply clean (it's from March; some hunks were failing), so
> I've fixed it and the combined git format-patch is attached. It did conflict
> with the following:
Thanks for looking this. Also thanks for
On Fri, Dec 17, 2021 at 02:33:25PM +, Jakub Wartak wrote:
> > Justin wrote:
> > On Fri, Dec 17, 2021 at 09:10:30AM +, Jakub Wartak wrote:
> > > As the thread didn't get a lot of traction, I've registered it into
> > > current
> > commitfest
> >
> Justin wrote:
> On Fri, Dec 17, 2021 at 09:10:30AM +, Jakub Wartak wrote:
> > As the thread didn't get a lot of traction, I've registered it into current
> commitfest
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommitf
>
On Fri, Dec 17, 2021 at 09:10:30AM +, Jakub Wartak wrote:
> I'm especially worried if I didn't screw up something/forgot something
> related to the last one (rd->rd_smgr changes), but I'm getting "All 210 tests
> passed".
> As the thread didn't get a lot of traction, I've registered it into
> Kyotaro wrote:
> > In this version, I got rid of the "CLEANUP FORK"s, and added a new
> > system "Smgr marks". The mark files have the name of the
> > corresponding fork file followed by ".u" (which means Uncommitted.).
> > "Uncommited"-marked main fork means the same as the
> CLEANUP2_FORKNUM
At Thu, 25 Mar 2021 14:08:05 +0900 (JST), Kyotaro Horiguchi
wrote in
> (I'm not sure when the subject was broken..)
>
> At Thu, 14 Jan 2021 17:32:17 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Commit bea449c635 conflicts with this on the change of the definition
> > of
(I'm not sure when the subject was broken..)
At Thu, 14 Jan 2021 17:32:17 +0900 (JST), Kyotaro Horiguchi
wrote in
> Commit bea449c635 conflicts with this on the change of the definition
> of DropRelFileNodeBuffers. The change simplified this patch by a bit:p
In this version, I got rid of the
At Tue, 12 Jan 2021 18:58:08 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 08 Jan 2021 17:52:21 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Fri, 08 Jan 2021 14:47:05 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> > > This version RelationChangePersistence() is changed not to
At Fri, 08 Jan 2021 17:52:21 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 08 Jan 2021 14:47:05 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > This version RelationChangePersistence() is changed not to choose
> > in-place method for indexes other than btree. It seems to be usable
> > with
At Fri, 08 Jan 2021 14:47:05 +0900 (JST), Kyotaro Horiguchi
wrote in
> This version RelationChangePersistence() is changed not to choose
> in-place method for indexes other than btree. It seems to be usable
> with all kind of indexes other than Gist, but at the mement it applies
> only to
At Fri, 25 Dec 2020 09:12:52 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hello.
>
> At Thu, 24 Dec 2020 17:02:20 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > The patch is attached to the next message.
>
> The reason for separating this message is that I modified this so that
> it could
Hello.
At Thu, 24 Dec 2020 17:02:20 +0900 (JST), Kyotaro Horiguchi
wrote in
> The patch is attached to the next message.
The reason for separating this message is that I modified this so that
it could solve another issue.
There's a complain about orphan files after crash. [1]
1:
Thanks for the comment! Sorry for the late reply.
At Fri, 4 Dec 2020 07:49:22 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Kyotaro Horiguchi
> > > No, not really. The issue is more around what happens if we crash
> > > part way through. At crash recovery time, the system catalogs
From: Kyotaro Horiguchi
> > No, not really. The issue is more around what happens if we crash
> > part way through. At crash recovery time, the system catalogs are not
> > available, because the database isn't consistent yet and, anyway, the
> > startup process can't be bound to a database, let
At Fri, 13 Nov 2020 07:15:41 +, "osumi.takami...@fujitsu.com"
wrote in
> Hello, Tsunakawa-San
>
Thanks for sharing it!
> > Do you know the reason why data copy was done before? And, it may be
> > odd for me to ask this, but I think I saw someone referred to the past
> > discussion that
At Fri, 13 Nov 2020 06:43:13 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> Hi Horiguchi-san,
>
>
> Thank you for making a patch so quickly. I've started looking at it.
>
> What makes you think this is a PoC? Documentation and test cases? If
> there's something you think that doesn't
Hello, Tsunakawa-San
> Do you know the reason why data copy was done before? And, it may be
> odd for me to ask this, but I think I saw someone referred to the past
> discussion that eliminating data copy is difficult due to some processing at
> commit. I can't find it.
I can share 2 sources
Hi Horiguchi-san,
Thank you for making a patch so quickly. I've started looking at it.
What makes you think this is a PoC? Documentation and test cases? If there's
something you think that doesn't work or are concerned about, can you share it?
Do you know the reason why data copy was done
Hello. Before posting the next version, I'd like to explain what this
patch is.
1. The Issue
Bulk data loading is a long-time taking, I/O consuming task. Many
DBAs want that task is faster, even at the cost of increasing risk of
data-loss. wal_level=minimal is an answer to such a
request.
At Wed, 11 Nov 2020 14:18:04 -0800, Andres Freund wrote in
> Hi,
>
> I suggest outlining what you are trying to achieve here. Starting a new
> thread and expecting people to dig through another thread to infer what
> you are actually trying to achive isn't great.
Agreed. I'll post that.
Hi,
I suggest outlining what you are trying to achieve here. Starting a new
thread and expecting people to dig through another thread to infer what
you are actually trying to achive isn't great.
FWIW, I'm *extremely* doubtful it's worth adding features that depend on
a PGC_POSTMASTER
Hello. This is a thread for an alternative solution to wal_level=none
[*1] for bulk data loading.
*1:
https://www.postgresql.org/message-id/TYAPR01MB29901EBE5A3ACCE55BA99186FE320%40TYAPR01MB2990.jpnprd01.prod.outlook.com
At Tue, 10 Nov 2020 09:33:12 -0500, Stephen Frost wrote in
> Greetings,
75 matches
Mail list logo
