On Mon, Sep 30, 2019 at 12:42 PM Michael Paquier wrote:
>
> On Mon, Sep 30, 2019 at 12:49:03AM +0900, Fujii Masao wrote:
> > Attached patch fixes this issue by making archive recovery always ignore
> > recovery_min_apply_delay. This change is OK because
> > recovery_min_ap
On Thu, Jul 5, 2018 at 5:15 PM Simon Riggs wrote:
>
> On 4 June 2018 at 17:46, Fujii Masao wrote:
> > Hi,
> >
> > My colleague encountered the problem that WAL replay took a long time
> > in the standby with large shared_buffers when he dropped the database
> &g
On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier wrote:
>
> On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> > TBH, I have no numbers measured by the test.
> > One question about your test is; how did you measure the *recovery time*
> > of DROP DATABA
On Fri, Sep 27, 2019 at 3:14 PM Michael Paquier wrote:
>
> On Thu, Sep 26, 2019 at 01:13:56AM +0900, Fujii Masao wrote:
> > On Tue, Sep 24, 2019 at 10:41 AM Michael Paquier
> > wrote:
> >> This also points out that there are other things to worry about than
> &g
On Thu, Oct 3, 2019 at 1:57 PM Michael Paquier wrote:
>
> On Thu, Oct 03, 2019 at 01:49:34PM +0900, Fujii Masao wrote:
> > But this can cause subsequent recovery to always fail with invalid-pages
> > error
> > and the server not to start up. This is bad. So, to allviat
On Mon, Sep 30, 2019 at 12:49 AM Fujii Masao wrote:
>
> Hi,
>
> I got the following assertion failure when I enabled recovery_min_apply_delay
> and started archive recovery (i.e., I put only recovery.signal not
> standby.signal).
>
> TRAP: FailedAssertion("latch-&
On Fri, Oct 4, 2019 at 6:09 PM Michael Paquier wrote:
>
> On Wed, Oct 02, 2019 at 03:30:38AM -0400, Stephen Frost wrote:
> > * David Steele (da...@pgmasters.net) wrote:
> >> On 9/28/19 1:26 PM, Fujii Masao wrote:
> >>> There might be some recovery parameters tha
On Fri, Oct 4, 2019 at 9:03 PM Fujii Masao wrote:
>
> On Mon, Sep 30, 2019 at 12:49 AM Fujii Masao wrote:
> >
> > Hi,
> >
> > I got the following assertion failure when I enabled
> > recovery_min_apply_delay
> > and started archive reco
On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote:
>
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Oct 7, 2019 at 9:14 AM Fujii Masao wrote:
> > > Agreed, too. Do you have any idea to implement that? I've not found out
On Wed, Oct 9, 2019 at 1:02 AM Stephen Frost wrote:
>
> Greetings,
>
> * Fujii Masao (masao.fu...@gmail.com) wrote:
> > On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote:
> > > Having these options end up set but then hacking all of the other code
> > >
On Thu, Oct 10, 2019 at 5:52 AM Peter Eisentraut
wrote:
>
> On 2019-09-30 03:48, Fujii Masao wrote:
> > Also we need to do the same thing for other recovery options like
> > restore_command. Attached is the patch which makes crash recovery
> > ignore restore_command
standby mode + recovery target setting for
the almost same purpose. In this configuration, if end-of-WAL is reached
before recovery target, the startup process keeps waiting for new WAL to
be available. Then, if recovery target is reached, the startup process works
as recovery_target_action indicates.
Regards,
--
Fujii Masao
Hi,
I found that the argument name of XLogFileInit() is wrong in its comment.
Attached is the patch that fixes that typo.
Regards,
--
Fujii Masao
fix_comment_in_xlogfileinit.patch
Description: Binary data
or not
at the beginning of pgbench, and report an error if it is. Otherwise,
if -I (dtgv) is specified, pgbench reports an error after time-consuming
data generation is performed, and of course that data generation is
rollbacked.
Regards,
--
Fujii Masao
On Mon, Oct 21, 2019 at 5:28 PM Amit Kapila wrote:
>
> On Mon, Oct 21, 2019 at 12:28 PM Fujii Masao wrote:
> >
> > I found that the argument name of XLogFileInit() is wrong in its comment.
> > Attached is the patch that fixes that typo.
> >
>
> LGTM.
Than
at it's better to check whehter "v" is enclosed with () or not
> > at the beginning of pgbench, and report an error if it is.
> >
> > Otherwise, if -I (dtgv) is specified, pgbench reports an error after
> > time-consuming data generation is performed, and o
On Wed, Feb 27, 2019 at 4:35 PM Laurenz Albe wrote:
>
> Fujii Masao wrote:
> > So, let me clarify the situations;
> >
> > (3) If backup_label.pending exists but recovery.signal doesn't, the server
> >ignores (or removes) backup_label.pending and do t
;t displayed in any of the 2PC message,
> that'd be useful to have it directly instead of looking for it in
> other messages for the same transaction.
dbid is not reported even in COMMIT message. So I don't like adding
dbid into only the PREPARE message.
Regards,
--
Fujii Masao
hor, no?
>
> Fujii,
>
> Are you in a position to submit an updated version of this patch?
Sorry for the long delay... Yes, I will update the patch if necessary.
Regards,
--
Fujii Masao
ber of block
to delete first is zero), can RelationTruncate() and smgr_redo() just
call smgrdounlinkall() like smgrDoPendingDeletes() does, instead of
calling MarkFreeSpaceMapTruncateRel(), visibilitymap_truncate_prepare()
and smgrtruncate()? ISTM that smgrdounlinkall() is faster and simpler.
Regards,
--
Fujii Masao
[ OR REPLACE ] LANGUAGE
> CREATE [ OR REPLACE ] RULE name AS ON event
> CREATE [ OR REPLACE ] VIEW AS SELECT
> CREATE [ OR REPLACE ] AGGREGATE
> CREATE [ OR REPLACE ] TRANSFORM
Thanks for the patch! The patch looks good to me.
Barring no objection, I will commit this.
Regards,
--
Fujii Masao
tWalRcvWriteRecPtr() to
get the last received TLI, like pg_last_wal_receive_lsn() does.
The timeline ID that this function returns is the same as
pg_stat_wal_receiver.received_tli while walreceiver is running.
But when walreceiver is not running, pg_stat_wal_receiver returns
no record, and pg_last_wal_received_tl() would be useful to
get the timeline only in this case. Is this my understanding right?
> Also, TimeLineID is declared as a uint32. So why do we use
> PG_RETURN_INT32/Int32GetDatum to return a timeline and not PG_RETURN_UINT32?
> See eg. in pg_stat_get_wal_receiver().
pg_stat_wal_receiver.received_tli is declared as integer.
Regards,
--
Fujii Masao
d be deleted in pg_basebackup.sgml.
* During recovery, since we don't use the end-of-backup WAL
* record and don't write the backup history file, the
This comment needs to be updated in xlog.c.
Regards,
--
Fujii Masao
ch_branches add primary key (bid)
alter table pgbench_tellers add primary key (tid)
alter table pgbench_accounts add primary key (aid)
--
Regards,
--
Fujii Masao
(!SHMQueueIsDetached(&(MyProc->syncRepLinks)))
{
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
if (!SHMQueueIsDetached(&(MyProc->syncRepLinks)))
SHMQueueDelete(&(MyProc->syncRepLinks));
LWLockRelease(SyncRepLock);
}
Regards,
--
Fujii Masao
;, \"G\", \"v\", \"p\", \"f\"\n"
- g (Generate data)
+ g or G
(Generate data, client or server side)
Isn't it better to explain a bit more what "client-side / server-side data
generation" is? For example, something like
When "g" (client-side data generation) is specified, data is generated
in pgbench client and sent to the server. When "G" (server-side data
generation) is specified, only queries are sent from pgbench client
and then data is generated in the server. If the network bandwidth is low
between pgbench and the server, using "G" might make the data
generation faster.
Regards,
--
Fujii Masao
e the attached patch that allows CREATE OR REPLACE VIEW
to rename the view columns. Thought?
Regards,
--
Fujii Masao
rename_view_column_v1.patch
Description: Binary data
On Thu, Oct 31, 2019 at 1:42 PM Tom Lane wrote:
>
> Fujii Masao writes:
> > Currently CREATE OR REPLACE VIEW command fails if the column names
> > are changed.
>
> That is, I believe, intentional. It's an effective aid to catching
> mistakes in view redefiniti
luster_name should be included in csvlog?
Regards,
--
Fujii Masao
On Thu, Oct 31, 2019 at 11:12 AM Michael Paquier wrote:
>
> On Wed, Oct 30, 2019 at 05:43:04PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 30 Oct 2019 17:21:17 +0900, Fujii Masao
> > wrote in
> >> This change causes every ending backends to always take the exclusive l
MN j TO x;
ALTER TABLE
Is this intentional? Or bug?
Regards,
--
Fujii Masao
On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed wrote:
>
>
>
> On Thu, Oct 31, 2019 at 12:32 PM Fujii Masao wrote:
>>
>> On Thu, Oct 31, 2019 at 1:42 PM Tom Lane wrote:
>> >
>> > Fujii Masao writes:
>> > > Currently CREATE OR REPLACE VIE
On Fri, Nov 1, 2019 at 6:34 AM Ibrar Ahmed wrote:
>
>
>
> On Thu, Oct 31, 2019 at 6:56 PM Tom Lane wrote:
>>
>> Fujii Masao writes:
>> > ... I found that the command tag of
>> > ALTER MATERIALIZED VIEW RENAME COLUMN is "ALTER TABLE", not "
On Thu, Oct 31, 2019 at 10:54 PM Tom Lane wrote:
>
> Fujii Masao writes:
> > On Thu, Oct 31, 2019 at 1:42 PM Tom Lane wrote:
> >> Fujii Masao writes:
> >>> Currently CREATE OR REPLACE VIEW command fails if the column names
> >>> are changed.
>
On Fri, Nov 1, 2019 at 9:41 PM Peter Eisentraut
wrote:
>
> On 2019-10-21 08:44, Fujii Masao wrote:
> > Probably we can use standby mode + recovery target setting for
> > the almost same purpose. In this configuration, if end-of-WAL is reached
> > before recovery target, t
nt trigger functions
using TG_TAG if we back-patch it. Or we should guarantee the compatibility of
command tag within the same major version?
Regards,
--
Fujii Masao
e
> signal handling. The first one does not look really better to me, and the
> second one belongs to a restructuring patch that I'll try to submit.
Thanks for updating the patch!
Attached is the slightly updated version of the patch. Based on your
patch, I added the descriptions about logging of "g" and "G" steps into
the doc, and did some cosmetic changes. Barrying any objections,
I'm thinking to commit this patch.
While reviewing the patch, I found that current code allows space
character to be specified in -I. That is, checkInitSteps() accepts
space character. Why should we do this? Probably I understand
why runInitSteps() needs to accept space character (because "v"
in the specified string with -I is replaced with a space character
when --no-vacuum option is given). But I'm not sure why that's also
necessary in checkInitSteps(). Instead, we should treat a space
character as invalid in checkInitSteps()?
Regards,
--
Fujii Masao
pgbench-init-extended-7_fujii.patch
Description: Binary data
it may break --no-vacuum, and I thought that there may be
> other option which remove things, eventually. Also, having a NO-OP looks
> ok to me.
As far as I read the code, checkInitSteps() checks the initialization
steps that users specified. The initialization steps string that
"v" was replaced with blank character is not given to checkInitSteps().
So ISTM that dropping the handling of blank character from
checkInitSteps() doesn't break --no-vacuum.
Regards,
--
Fujii Masao
On Tue, Nov 5, 2019 at 11:19 PM Tom Lane wrote:
>
> Fujii Masao writes:
> > I'm thinking to commit the patch. But I have one question; is it ok to
> > back-patch? Since the patch changes the command tags for some commands,
> > for example, which might break the exi
, I
> think, something like "end-of-available-WAL"/"all-WAL", "end-of-WAL" is
> a way to go.
What happens if this parameter is set to latest in the standby mode?
Or the combination of those settings should be prohibited?
Regards,
--
Fujii Masao
On Thu, Oct 31, 2019 at 9:34 PM Ibrar Ahmed wrote:
>
>
>
> On Thu, Oct 31, 2019 at 5:28 PM Ibrar Ahmed wrote:
>>
>>
>>
>> On Thu, Oct 31, 2019 at 5:11 PM Ibrar Ahmed wrote:
>>>
>>>
>>>
>>> On Thu, Oct 31, 2019 at 5:01 PM F
way.
Why is that regression, you think? I think that's an oversight.
If I'm missing something and accepting a blank character as no-op in
also checkInitSteps() is really necessary for some reasons,
which should be documented. But, if so, another question is;
why should only blank character be treated as no-op, in checkInitSteps()?
Regards,
--
Fujii Masao
zed character, runInitSteps() emits an error.
* (We could just leave it to runInitSteps() to fail if there are wrong
* characters, but since initialization can take awhile, it seems friendlier
* to check during option parsing.)
The above comment in checkInitSteps() seems to explain why
checkInitSteps() is called at the beginning of processing initialization
steps.
Regards,
--
Fujii Masao
On Fri, Nov 8, 2019 at 9:41 AM Michael Paquier wrote:
>
> On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
> > Sorry for the long delay... Yes, I will update the patch if necessary.
>
> Fujii-san, are you planning to update this patch then? I have
> switched it
ache 50 catcache 49
catcache 50 catcache 49 relcache 16386 relcache 16390 relcache 16390
relcache 16386 relcache 16386 relcache 16390 relcache 16390 relcache
16386
> By the way, in the patch xact_desc_prepare seems printing
> parseed.xact_time, which is not actually set by ParsePrepareRecord.
Thank
On Mon, Nov 11, 2019 at 4:16 PM Michael Paquier wrote:
>
> On Mon, Nov 11, 2019 at 01:21:28PM +0900, Fujii Masao wrote:
> > Thanks for the review! You are right.
> > I fixed this issue in the attached patch.
>
> The proposed format looks fine to me. I have just one comme
On Tue, Nov 12, 2019 at 6:03 PM Michael Paquier wrote:
>
> On Tue, Nov 12, 2019 at 05:53:02PM +0900, Fujii Masao wrote:
> > Thanks for the review! But probably I failed to understand your point...
> > Could you clarify what actual change is necessary? You are thinking tha
On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
wrote:
>
> On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrote:
> > On Tue, Jul 10, 2018 at 3:04 PM Michael Paquier wrote:
> > >
> > > On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> > > &
On Wed, Nov 13, 2019 at 3:53 PM Andrey Lepikhov
wrote:
>
>
>
> 12.11.2019 12:41, Fujii Masao пишет:
> > Ok, I changed the patch that way.
> > Attached is the latest version of the patch.
> >
> > Regards,
>
> I did not see any problems in this version of
On Wed, Nov 6, 2019 at 4:14 PM btfujiitkp wrote:
>
> 2019-10-31 21:01 に Fujii Masao さんは書きました:
> > On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed
> > wrote:
> >>
> >>
> >>
> >> On Thu, Oct 31, 2019 at 12:32 PM Fujii Masao
> >> wro
hich you don't have appropriate read or
> execute access).
>
> The problem is that because this happens in the startup process, the
> ERROR is turned into a FATAL and the whole instance shuts down. That
> seems like a harsh penalty. Would it be better to turn this ERROR into
> a WARNING?
+1
Regards,
--
Fujii Masao
eTriggerFile() at startup time then? I take it
> that the only thing we should not complain about is stat() returning
> ENOENT when looking at the promote file defined.
promote_trigger_file is declared as PGC_SIGHUP,
so such check would be necessary even while the standby is running.
Which can cause the server to fail after the startup.
Regards,
--
Fujii Masao
hes.
- Allow ALTER VIEW command to rename the column in the view.
- Improve tab-completion for ALTER MATERIALIZED VIEW.
Regards,
--
Fujii Masao
On Tue, Nov 19, 2019 at 3:39 PM k.jami...@fujitsu.com
wrote:
>
> On Wed, Nov 13, 2019 5:34PM (GMT+9), Fujii Masao wrote:
> > On Wed, Nov 13, 2019 at 3:57 PM k.jami...@fujitsu.com
> >
> > wrote:
> > >
> > > On Wed, Oct. 2, 2019 5:40 PM, Fujii Masao wrot
following messages.
FATAL: cannot wait on a latch owned by another process
LOG: startup process (PID 81007) exited with exit code 1
LOG: terminating any other active server processes
LOG: database system is shut down
Regards,
--
Fujii Masao
On Fri, Nov 29, 2019 at 11:39 AM Michael Paquier wrote:
>
> On Thu, Oct 03, 2019 at 05:54:40PM +0900, Fujii Masao wrote:
> > On Thu, Oct 3, 2019 at 1:57 PM Michael Paquier wrote:
> > >
> > > On Thu, Oct 03, 2019 at 01:49:34PM +0900, Fujii Masao wrote:
> &g
r commands that we may add in the future
can cause the same issue, so it's better to address the root cause rather
than working around by disallowing PREPARE.
Regards,
--
Fujii Masao
is not in progress, we can just use the global variable like
pg_abort_backup_registered to register the callback function only
on first call. In this way, cancel_before_shmem_exit() doesn't need to
search the array to get rid of the function.
Regards,
--
Fujii Masao
;m missing something... But since XLogWrite() seems to
call issue_xlog_fsync() before XLogArchiveNotifySeg(), ISTM that
this trouble shouldn't happen. No?
Regards,
--
Fujii Masao
partitioned table not.
Regards,
--
Fujii Masao
On Wed, Dec 25, 2019 at 1:56 PM Amit Langote wrote:
>
> Fujii-san,
>
> On Wed, Dec 25, 2019 at 12:19 PM Fujii Masao wrote:
> >
> > Hi,
> >
> > As the document explains, column defaults can be specified separately for
> > each partition. But I found tha
,
for durability. Thought?
Regards,
--
Fujii Masao
pg_file_sync_v1.patch
Description: Binary data
On Wed, Dec 25, 2019 at 5:47 PM Amit Langote wrote:
>
> On Wed, Dec 25, 2019 at 5:40 PM Fujii Masao wrote:
> > On Wed, Dec 25, 2019 at 1:56 PM Amit Langote
> > wrote:
> > > IIRC, there was some discussion about implementing a feature whereby
> > > partition&
yway
is it better to document that? For example,
Access privileges may be defined and removed separately for each partition.
But note that queries through a partitioned table ignore each partition's
SELECT, INSERT, UPDATE and DELETE privileges, and apply only TRUNCATE one.
Regards,
--
Fujii Masao
to cause a PANIC.
I updated the patch so that pg_file_sync() uses fsync_fname_ext()
instead of fsync_fname() as Arthur suggested.
It's one of ideas to make pg_file_sync() open the file and directly call
pg_fsync(). But fsync_fname_ext() has already such code and
I'd like to avoid the code duplic
On Wed, Dec 25, 2019 at 11:11 PM Julien Rouhaud wrote:
>
> On Wed, Dec 25, 2019 at 2:01 PM Fujii Masao wrote:
> >
> > Hi,
> >
> > I'd like to propose to add pg_file_sync() function into contrib/adminpack.
> > This function fsyncs the specified file or
On Tue, Jan 7, 2020 at 5:15 PM Amit Langote wrote:
>
> On Fri, Dec 27, 2019 at 4:26 AM Tom Lane wrote:
> > Fujii Masao writes:
> > > My customer reported me that the queries through a partitioned table
> > > ignore each partition's SELECT, INSERT, UPDATE,
On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote:
>
> On Thu, Jan 9, 2020 at 7:31 AM Fujii Masao wrote:
> >
> > On Mon, Jan 6, 2020 at 3:42 PM Michael Paquier wrote:
> > >
> > > On Mon, Jan 06, 2020 at 03:20:13PM +0900, Arthur Zakirov wrote:
> >
On Fri, Jan 10, 2020 at 8:16 PM Michael Paquier wrote:
>
> On Fri, Jan 10, 2020 at 06:50:12PM +0900, Fujii Masao wrote:
> > I changed the doc that way. Thanks for the review!
Thanks for the review!
> +
> + pg_file_sync fsyncs the specified file or directory
> + named
On Tue, Dec 17, 2019 at 2:19 PM Michael Paquier wrote:
>
> On Mon, Dec 16, 2019 at 12:22:18PM +0900, Fujii Masao wrote:
> > > +Detection of WAL records having references to invalid pages
> > > during
> > > +recovery causes PostgreSQL to report
consensus is to return void on success and throw an error
otherwise. Attached is the updated version of the patch.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
diff --git a/contrib/adminpack/Makefile b/contrib/adminpack/Makefil
On 2020/01/13 22:46, Michael Paquier wrote:
On Sat, Jan 11, 2020 at 02:12:15AM +0900, Fujii Masao wrote:
I'm not sure if returning false with WARNING only in some error cases
is really good idea or not. At least for me, it's more intuitive to
return true on success and emi
On Fri, Jan 17, 2020 at 1:47 PM Michael Paquier wrote:
>
> On Thu, Jan 16, 2020 at 11:17:36PM +0900, Fujii Masao wrote:
> > OK, I updated the patch that way.
> > Attached is the updated version of the patch.
>
> Thanks. I have few tweaks to propose to the docs.
>
>
the password specified in the prompt into 99B if its length is
more than 99B. I think that psql should emit a warning in this case
so that users can notice that.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
g from
320B position. Whether to enlarge the length of a line should be
a separate discussion, I think.
For (2), libpq should treat any lines beginning with # as comments.
I've not created the patch yet, but will do if we reach to
the consensus.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Adv
posal, i.e., holding the interrupts during
the truncation, is worth considering? It is not a perfect
solution but might improve the situation a bit.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/01/22 0:12, Bruce Momjian wrote:
On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote:
I have no strong opinion about the maximum length of password,
for now. But IMO it's worth committing that 0001 patch as the first step
for this problem.
Also IMO the more problematic
ut I like having the (reasonable) upper limit on that
rather than arbitrary size.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
On 2020/01/18 12:48, Michael Paquier wrote:
On Fri, Jan 17, 2020 at 07:36:51PM +0900, Fujii Masao wrote:
On Fri, Jan 17, 2020 at 1:47 PM Michael Paquier wrote:
Thanks. I have few tweaks to propose to the docs.
+raise a PANIC-level error, aborting the recovery. Setting
Instead of
On 2020/01/22 16:54, Amit Langote wrote:
Fujii-san,
Thanks for taking a look.
On Fri, Jan 10, 2020 at 10:29 AM Fujii Masao wrote:
On Tue, Jan 7, 2020 at 5:15 PM Amit Langote wrote:
I tend to agree that TRUNCATE's permission model for inheritance
should be consistent with that fo
dded the following note to the doc.
Note that
has no effect on this function,
and therefore a PANIC-level error will not be raised even on failure to
flush database files.
----
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Grou
On 2020/01/24 16:56, Julien Rouhaud wrote:
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao wrote:
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There
On 2020/01/24 17:08, Fujii Masao wrote:
On 2020/01/24 16:56, Julien Rouhaud wrote:
On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao
wrote:
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote
On 2020/01/23 22:14, Fujii Masao wrote:
On 2020/01/22 16:54, Amit Langote wrote:
Fujii-san,
Thanks for taking a look.
On Fri, Jan 10, 2020 at 10:29 AM Fujii Masao
wrote:
On Tue, Jan 7, 2020 at 5:15 PM Amit Langote
wrote:
I tend to agree that TRUNCATE's permission mode
rgument should be set to the actual path instead of an empty
string. Otherwise XLogForgetMissingDir() may emit a confusing DEBUG2
message. Or the third argument of XLogForgetMissingDir() should be removed
and the path in the DEBUG2 message should be calculated from the spcNode
and dbNode in the hash entry in X
;t
apply the following change.
- if (xid > state->last_xid &&
- TransactionIdPrecedes(xid, state->last_xid))
+ if (xid > next_xid)
epoch--;
- else if (xid < state->last_xid &&
-TransactionIdFollows(xid, state->last_xid))
- epoch++;
Does anyone want to object to the txid/xid8 type punning scheme or
long term txid-sunsetting plan?
No. +1 to retire txid someday.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
27;d like the
> committer to choose what he thinks better.
+ This parameter cannot be set for TOAST tables.
reloption for TOAST is also required?
Regards,
--
Fujii Masao
the master. I'm thinking to commit this patch at first.
We can change the term and add the support of "TRUNCATE" option
for VACUUM command later.
Regards,
--
Fujii Masao
disable-vacuum-truncation_v7.patch
Description: Binary data
2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> > "vacuum_truncate" gets my vote too.
>
> +1
>
+1
ISTM that we have small consensus to
use "vacuum_truncate".
regards,
On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote:
> >
> > 2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
> >>
> >> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> >> > "vacuum_tr
On Mon, Apr 8, 2019 at 5:20 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 10:15 AM Fujii Masao wrote:
> >
> > OK, so I pushed the "vacuum_truncate" version of the patch.
>
> Thanks!
>
> > But it has not been actually pushed into the community&#x
On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
> > >
> > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote:
> > > >
On Tue, Apr 9, 2019 at 1:07 PM Kyotaro HORIGUCHI
wrote:
>
> Hello.
>
> At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao wrote
> in
> > > "TRUNCATE" option for vacuum command should be added to the open items?
> >
> > Yes, I think.
> > Attached
On Tue, Apr 16, 2019 at 10:48 AM Jamison, Kirk wrote:
>
> Hello Fujii-san,
>
> On April 18, 2018, Fujii Masao wrote:
>
> > On Fri, Mar 30, 2018 at 12:18 PM, Tsunakawa, Takayuki
> > wrote:
> >> Furthermore, TRUNCATE has a similar and worse issue. While DROP
illegal option.
This is not the problem only for pg_test_timing. If you want to
address this, the patch needs to cover all the client commands
like psql, createuser. I'm not sure if it's worth doing that.
Regards,
--
Fujii Masao
user. For example,
replication role can execute pg_create_physical_replication_slot().
So I think that the patch should fix also the description for those
replication functions. Thought?
Regards,
--
Fujii Masao
aving
EXECUTE privilege on pg_logical_emit_message function?
I don't think that this description only for pg_logical_emit_message
is necessary.
Regards,
--
Fujii Masao
On Thu, Apr 25, 2019 at 6:51 PM Kyotaro HORIGUCHI
wrote:
>
> Hello.
>
> I happened to find that several symbols renamed in 3eb77eba5a are
> left in comments. Please find the attached.
Thanks for the patch! Committed.
Regards,
--
Fujii Masao
00060, desc: PREPARE gid abc: 2004-06-17
05:26:27.500240 JST
I will add this to next CommitFest page.
Regards,
--
Fujii Masao
prepare-xact-desc.patch
Description: Binary data
On Fri, Apr 26, 2019 at 1:04 AM Alvaro Herrera wrote:
>
> On 2019-Apr-26, Fujii Masao wrote:
>
> > Hi,
> >
> > pg_waldump report no detail information about PREPARE TRANSACTION record,
> > as follows.
> >
> > rmgr: Transaction len (rec/tot):25
601 - 700 of 1911 matches
Mail list logo
