> uncomfortable. If the list explicitly stats that we do not guarantee
> that the order of the last names and the first names are correct, then
> that kind of misunderstanding could be avoided.
Yeah, your concern might be right, but I prefer Fujii Masao,
i.e., family-name-first style, so
On Thu, Apr 27, 2017 at 6:32 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 27 Apr 2017 00:51:03 +0900, Fujii Masao wrote
> in
>> On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
>> wrote:
>> > At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
>> > wro
On Thu, Apr 27, 2017 at 5:37 PM, Petr Jelinek
wrote:
> On 26/04/17 18:36, Fujii Masao wrote:
>> On Thu, Apr 27, 2017 at 1:28 AM, Fujii Masao wrote:
>>> On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
>>> wrote:
>>>> At Wed, 26 Apr 2017 14:31:12
On Thu, Apr 27, 2017 at 1:28 AM, Fujii Masao wrote:
> On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
> wrote:
>> At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada
>> wrote in
>>
>>> On Wed, Apr 26, 2017 at 12:35 PM, Petr Jelinek
>>> wrote:
On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
wrote:
> At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada
> wrote in
>
>> On Wed, Apr 26, 2017 at 12:35 PM, Petr Jelinek
>> wrote:
>> > On 26/04/17 01:01, Fujii Masao wrote:
>> >>>> However
uncher only when ENABLE is specified. Patch attached. Thought?
Regards,
--
Fujii Masao
wakeup_launcher_when_enabled.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 26, 2017 at 3:07 PM, Masahiko Sawada wrote:
> Hi,
>
> Attached patch for $subject.
>
> s/accomodate/accommodate/
Pushed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
ue.
>
> I agree this as a whole. But I think that the main issue here is
> not false wakeups, but 'possible delay of launching new workers
> by 3 minutes at most' (this is centainly a kind of false wakeups,
> though). We can live with this failure when using two-paase
> com
of this message. Include a date for your
>> >> subsequent status update.
>> >
>> > Okay, so our consensus is to always set the priorities of sync standbys
>> > to 1 in quorum-based syncrep case. Attached patch does this change.
>> > Barrying any objecti
replication is still useful even without
initial table sync feature. So reverting the table sync patch seems
possible idea.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
atch gets rid of them.
Pushed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
While quorum-based
>> replication master waits only for a specified number of fastest
>> standbys, priority-based replicatoin master must wait for
>> standbys at the top of the list, which may be slower than the
>> rest.
>
> This description looks good to me. I've updated the patch based on
> this description and attached it.
But I still think that the original description that I used in my patch is
better than this
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
at 01:52:53PM +0900, Masahiko Sawada wrote:
>> > >> On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch wrote:
>> > >> > On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote:
>> > >> >> As I told firstly this is not a bug. The
On Fri, Apr 21, 2017 at 4:02 PM, Masahiko Sawada wrote:
> On Fri, Apr 21, 2017 at 1:19 AM, Fujii Masao wrote:
>> On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada
>> wrote:
>>> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUCHI
>>> wrote:
>>>> Hi
On Thu, Apr 20, 2017 at 12:05 PM, Noah Misch wrote:
> On Sun, Apr 16, 2017 at 06:14:49AM +, Noah Misch wrote:
>> On Fri, Apr 14, 2017 at 04:47:12AM +0900, Fujii Masao wrote:
>> > Though I've read only a part of the logical rep code yet, I'd like to
>> >
t; On Mon, Apr 17, 2017 at 9:13 PM, Masahiko Sawada
>>> wrote:
>>> > On Mon, Apr 17, 2017 at 7:39 PM, Kyotaro HORIGUCHI
>>> > wrote:
>>> >> At Mon, 17 Apr 2017 18:02:57 +0900, Masahiko Sawada
>>> >> wrote in
>>>
On Tue, Apr 18, 2017 at 7:02 PM, Masahiko Sawada wrote:
> On Tue, Apr 18, 2017 at 6:40 PM, Kyotaro HORIGUCHI
> wrote:
>> At Tue, 18 Apr 2017 14:58:50 +0900, Masahiko Sawada
>> wrote in
>>> On Tue, Apr 18, 2017 at 3:04 AM, Fujii Masao wrote:
>>> > On
merge
> conflict being solved wrongly. Maybe your patch could fix that too?
>
>>>>>
>>>>>>> 10.
>>>>>>>>
>>>>>>>> SpinLockAcquire(&MyLogicalRepWorker->relmutex);
>>>>>>>>
On Wed, Apr 12, 2017 at 2:36 AM, Masahiko Sawada wrote:
> On Thu, Apr 6, 2017 at 4:17 PM, Masahiko Sawada wrote:
>> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote:
>>> On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>>>> On Wed, Apr 5, 2017
On Sun, Apr 16, 2017 at 1:19 PM, Noah Misch wrote:
> On Fri, Apr 14, 2017 at 11:58:23PM -0400, Noah Misch wrote:
>> On Wed, Apr 05, 2017 at 09:51:02PM -0400, Noah Misch wrote:
>> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>>
>> > > > O
On Fri, Apr 14, 2017 at 10:33 PM, Petr Jelinek
wrote:
> On 12/04/17 15:55, Fujii Masao wrote:
>> Hi,
>>
>> When I shut down the publisher while I repeated creating and dropping
>> the subscription in the subscriber, the publisher emitted the following
>> PANIC
alRepWorker->subid,
MyLogicalRepWorker->relid,
&MyLogicalRepWorker->relstate_lsn,
false);
SpinLockRelease(&MyLogicalRepWorker->relmutex);
Non-"short-term" function like GetSubscriptionRelState() should not
be called while spinl
On Thu, Apr 13, 2017 at 12:36 PM, Michael Paquier
wrote:
> On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote:
>> On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
>> wrote:
>>> On 4/12/17 09:55, Fujii Masao wrote:
>>>> To fix this issue, we should termina
gt;>> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>>> >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote:
>>> >> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
>>> >> >> Regarding
On Fri, Apr 14, 2017 at 1:28 AM, Peter Eisentraut
wrote:
> On 4/10/17 13:28, Fujii Masao wrote:
>> src/backend/replication/logical/launcher.c
>> * Worker started and attached to our shmem. This check is safe
>> * because only launcher ever starts t
On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut
wrote:
> On 4/12/17 09:55, Fujii Masao wrote:
>> To fix this issue, we should terminate walsender for logical replication
>> before shutdown checkpoint starts. Of course walsender for physical
>> replication still needs
On Wed, Apr 12, 2017 at 10:32 AM, Amit Langote
wrote:
> On 2017/04/12 0:22, Fujii Masao wrote:
>> On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote
>> wrote:
>>> On 2017/04/07 0:56, Fujii Masao wrote:
>>>> On Tue, Apr 4, 2017 at 10:19 AM, Amit
On Thu, Apr 13, 2017 at 11:05 AM, Masahiko Sawada wrote:
> On Wed, Apr 12, 2017 at 11:48 PM, Fujii Masao wrote:
>> On Wed, Apr 12, 2017 at 5:12 PM, Masahiko Sawada
>> wrote:
>>> Hi,
>>>
>>> I've attached a patch for $subject. Please check it.
ation. ALTER PUBLICATION has the same issue, too.
So I think that we need to apply the attached patch which improves the
documentation
for ALTER PUBLICATION and SUBSCRIPTION.
Regards,
--
Fujii Masao
bugfix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 12, 2017 at 2:40 AM, Masahiko Sawada wrote:
> On Wed, Apr 12, 2017 at 2:05 AM, Fujii Masao wrote:
>> Hi,
>>
>> I observed $subject when I ran the following steps.
>>
>> 1. start the publisher server
>> 2. start the subscriber server
>> 3.
.
To fix this issue, we should terminate walsender for logical replication
before shutdown checkpoint starts. Of course walsender for physical
replication still needs to keep running until shutdown checkpoint ends,
though.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql
and it also exits immediately because of primary key violation.
This sequence repeats very fast...
Attached is the script that I used to reproduce the issue.
Regards,
--
Fujii Masao
test.sh
Description: Bourne shell script
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote
wrote:
> On 2017/04/07 0:56, Fujii Masao wrote:
>> On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote
>> wrote:
>>> It seems pg_stat_progress_vacuum is not supposed to appear in the table
>>> titled "Collected Statist
On Tue, Apr 11, 2017 at 4:50 PM, Masahiko Sawada wrote:
> On Tue, Apr 11, 2017 at 1:39 AM, Fujii Masao wrote:
>> On Mon, Apr 10, 2017 at 9:39 PM, Masahiko Sawada
>> wrote:
>>> On Mon, Apr 10, 2017 at 9:32 PM, Petr Jelinek
>>> wrote:
>>>> On 10/04/
worker.
So the above assumption is not valid for now.
This issue seems to cause the corner case where the launcher picks up
the same worker slot that previously-started worker has already picked
up to start another worker.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql
N_SUBSCRIBERS into config_group
- mark max_logical_replication_workers and max_sync_workers_per_subscription
as REPLICATION_SUBSCRIBERS parameters, in guc.c
- move those parameters into "Subscribers" section in postgresql.conf.sample
The attached patch does these.
Regards,
--
Dynamic Statistics Views"
because it reports dynamic info, i.e., progress, about VACUUM activity?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
}
>
> I'm *very* doubtful about this, but even if we do it, this needs careful
> benchmarking.
>
>> /* signal that we need to wakeup walsenders later */
>> @@ -3043,6 +3157,9 @@ XLogBackgroundFlush(void)
>> {
>> XLogWrite(WriteRqst, flexible);
>> }
>> +
>> + /* Collect all the wal write shared counters into local, and report it
>> to stats collector */
>> + memcpy(&LocalWalWritesStats.stats, &XLogCtl->stats,
>> sizeof(PgStat_WalWritesCounts));
>> LWLockRelease(WALWriteLock);
>
> Hm. I think in a good number of workloads hti sis never reached, because
> we return early.
>
>
> I think this is an interesting feature, but I don't think it's ready,
> and it was submitted very late in the v10 release cycle. Therefore I
> think this should be moved to the next CF.
+1
I think that there is no consensus yet about what values should be exposed.
For example, with the patch, WAL writing activity by backends is reported
separately from that by the other processes. But I'm not sure if this grouping
is good. It seems better to report walwriter activity separately from
the others, for tuning of walwriter.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
Both launcher and worker don't handle SIGHUP signal and cannot
reload the configuration. I think that this is a bug. Will add this as
an open item barring objection.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote:
> On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
>> Regarding this feature, there are some loose ends. We should work on
>> and complete them until the release.
>>
>> (1)
>> Which synchronous repli
sage style in docs.
Also It seems a bit unclear to me. So what about replacing it with
something like the following?
ERROR: must connect to database to execute command \"%s\"
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, Mar 29, 2017 at 3:31 PM, Masahiko Sawada wrote:
> On Wed, Mar 29, 2017 at 1:32 AM, Fujii Masao wrote:
>> On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada
>> wrote:
>>> On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada
>>> wrote:
>>>> On Sun
t;>
>> However, I don't think it is very obvious to users (or at least it is
>> not to me) how to get at this from psql, if you want to script it. If I
I don't think that using psql to run BASE_BACKUP command is good
approach. Instead, IMO you basically should implement th
hen WAL files are included in the backup.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 28, 2017 at 1:40 PM, Haribabu Kommi
wrote:
>
>
> On Mon, Mar 27, 2017 at 1:27 PM, Haribabu Kommi
> wrote:
>>
>>
>>
>> On Sat, Mar 25, 2017 at 6:40 AM, Fujii Masao
>> wrote:
>>>
>>> On Wed, Feb 15, 2017 at 12:53 PM, Haribab
On Wed, Mar 29, 2017 at 1:32 AM, Fujii Masao wrote:
> On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada
> wrote:
>> On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada
>> wrote:
>>> On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao wrote:
>>>> On Mon,
On Tue, Mar 28, 2017 at 1:06 AM, Masahiko Sawada wrote:
> On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada
> wrote:
>> On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao wrote:
>>> On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada
>>> wrote:
>>>> On Fri, M
Hi,
Logical replication worker should call pgstat_report_stat()?
Currently it doesn't seem to do that and no statistics about
table accesses by logical replication workers are collected.
For example, this can prevent autovacuum from working on
those tables properly.
Regards,
--
Fujii
les
>> --
>> src/backend/commands/vacuumlazy.c | 9 +
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>>
>
> Should we change the example in vacuum.sgml file as well? Attached patch.
"tuples" in the above should be "row versions&q
rocess (e.g., end-of-
recovery checkpoint) and logical replication worker (Not sure if it always
works with synchronous_commit=off, though). There might be other processes
which can write WAL.
Why didn't you separate "write_blocks", "write_time" and "sync_time"
On Thu, Mar 23, 2017 at 4:28 AM, Fujii Masao wrote:
> On Wed, Mar 15, 2017 at 7:51 PM, Masahiko Sawada
> wrote:
>> On Wed, Mar 15, 2017 at 1:09 PM, Yugo Nagata wrote:
>>> On Fri, 10 Mar 2017 20:08:42 +0900
>>> Masahiko Sawada wrote:
>>>
>>>>
ttext("%u frozen page.\n", "%u frozen
>> pages.\n",
>> vacrelstats->frozenskipped_pages),
>> vacrelstats->frozenskipped_pages);
>>
>
> Yeah, you're right. I've attached the updated version patch
> incorporated your comment and fixing documentation.
The patch looks very simple and good to me.
Barring objection, I will commit this.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 23, 2017 at 12:37 AM, Stephen Frost wrote:
> David, all,
>
> * David Steele (da...@pgmasters.net) wrote:
>> On 3/21/17 2:34 PM, Fujii Masao wrote:
>> >The patch basically looks good to me, but one comment is;
>> >backup.sgml (at least the descri
and worked as
> expected.
The patch basically looks good to me, but one comment is;
backup.sgml (at least the description for "Making a non-exclusive
low level backup) seems to need to be updated.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hacke
> invalidating what users and DBAs think they know about how PostgreSQL
>> works is a good thing, too; there are a lot more people who know
>> something about the directory layout than will read this thread.
>
> I'm cool with that, thanks for the commit.
monitoring.sgml
and
back-patch. Or we should fix this only in HEAD? Anyway I'd like to hear
more opinions about this.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 8, 2017 at 9:05 PM, Masahiko Sawada wrote:
> On Wed, Feb 8, 2017 at 12:04 AM, Fujii Masao wrote:
>> On Tue, Feb 7, 2017 at 2:13 AM, Petr Jelinek
>> wrote:
>>> On 06/02/17 17:33, Fujii Masao wrote:
>>>> On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
RENAME TO hoge;
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Feb 20, 2017 at 7:34 AM, neha khatri wrote:
> Hi,
>
> Attached is a patch that fixes a comment typo in varlena.c
Thanks! Pushed.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
07b34e0 in BackendRun (port=0x268f4b0) at postmaster.c:4310
> #11 0x007b2c60 in BackendStartup (port=0x268f4b0) at postmaster.c:3982
> #12 0x0000007af2e0 in ServerLoop () at postmaster.c:1722
> #13 0x007ae9a4 in PostmasterMain (argc=5, argv=0x266c020) at
> postmaster.c:13
sterMain(argc=3,
> argv=0x7fbcabc02b90) + 5397 at postmaster.c:1330
> frame #14: 0x00010e76371f postgres`main(argc=3,
> argv=0x7fbcabc02b90) + 751 at main.c:228
> frame #15: 0x7fffa951c255 libdyld.dylib`start + 1
> frame #16: 0x7fffa951c255 libdyld.dylib`start + 1
&
On Tue, Feb 21, 2017 at 7:52 PM, Masahiko Sawada wrote:
> On Tue, Feb 21, 2017 at 3:42 AM, Fujii Masao wrote:
>> On Thu, Feb 16, 2017 at 11:40 AM, Masahiko Sawada
>> wrote:
>>> On Thu, Feb 16, 2017 at 7:52 AM, Petr Jelinek
>>> wrote:
>>>> On 15/02/
On Thu, Feb 16, 2017 at 11:40 AM, Masahiko Sawada wrote:
> On Thu, Feb 16, 2017 at 7:52 AM, Petr Jelinek
> wrote:
>> On 15/02/17 06:43, Masahiko Sawada wrote:
>>> On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote:
>>>> On Mon, Feb 13, 2017 at 4:05 PM, Masahiko
On Fri, Feb 17, 2017 at 11:17 PM, Peter Eisentraut
wrote:
> On 2/13/17 12:07, Fujii Masao wrote:
>> Anyway IMO that we can expose all the
>> columns except the sensitive information (i.e., subconninfo field)
>> in pg_subscription to even non-superusers.
>
> You mean w
On Tue, Feb 14, 2017 at 2:06 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote:
>> On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote:
>>> Remove all references to "xlog" from SQL-callable functions in pg_proc.
>>>
>>> C
On Fri, Feb 10, 2017 at 1:52 PM, Michael Paquier
wrote:
> On Tue, Feb 7, 2017 at 6:35 AM, Peter Eisentraut
> wrote:
>> On 2/6/17 10:54 AM, Fujii Masao wrote:
>>> Yes, that's an option. And, if we add dbid to pg_stat_subscription,
>>> I'm tempted to add
are still some mentions to "xlog" in the doc. Maybe we should replace
them with "wal" as the attached patch does.
Regards,
--
Fujii Masao
xlog2wal.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sawada wrote:
>>>>> On Wed, Feb 8, 2017 at 9:01 AM, Michael Paquier
>>>>> wrote:
>>>>>> On Wed, Feb 8, 2017 at 1:30 AM, Fujii Masao
>>>>>> wrote:
>>>>>>> On Wed, Feb 8, 2017 at 12:26 AM, Petr Jelinek
>>&
he subscription is no longer there?
Another idea is to treat DROP SUBSCRIPTION in the same way as VACUUM, i.e.,
make it emit an error if it's executed within user's transaction block.
Also DROP SUBSCRIPTION should call CommitTransactionCommand() just
after removing the entry from pg_su
On Tue, Feb 7, 2017 at 2:13 AM, Petr Jelinek
wrote:
> On 06/02/17 17:33, Fujii Masao wrote:
>> On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
>> wrote:
>>> On 03/02/17 19:38, Fujii Masao wrote:
>>>> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao wrote:
>>&g
o true even if the transaction
is rollbacked. This would cause the same problem that you're trying to fix.
I think that we should make the launcher periodically checks pg_subscription
and stop the worker if there is no its corresponding subscription. Then,
if necessary, the worker should remove it
On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
wrote:
> On 03/02/17 19:38, Fujii Masao wrote:
>> On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao wrote:
>>> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
>>> wrote:
>>>> At Fri, 3 Feb 2017 01:0
On Tue, Feb 7, 2017 at 12:36 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki
>> wrote:
>>> I don't have a strong opinion on that, but I think a bit that it would be
>>> better to reflect the effective set
On Mon, Feb 6, 2017 at 1:52 PM, Michael Paquier
wrote:
> On Sun, Feb 5, 2017 at 5:04 AM, Fujii Masao wrote:
>> With this patch, when normal users type TAB after SUBSCRIPTION,
>> they got "permission denied" error. I don't think that's accept
t have a strong opinion on that, but I think a bit that it would be
> better to reflect the effective setting, i.e. SHOW displays huge_pages as
> off, not try.
Not sure if this is best way to do that, but I agree that it's helpful if
we can see whether the server actually uses
it has
many files and it occupies large amount of disk space) even after renaming
to pg_wal. The crazy idea, making initdb create the empty file with the name
"DONT_REMOVE_pg_xlog_IF_YOU_DONT_WANT_TO_LOSE_YOUR_IMPORTANT_DATA"
in $PGDATA seems more helpful. Anyway I'm afraid that the renaming would
cause more pain than gain.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ould be
specified. But, with this patch, the tab-completion for PUBLICATION shows
the publications defined in local server (ie, subscriber side in those cases).
This might be confusing.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Feb 3, 2017 at 3:55 AM, Peter Eisentraut
wrote:
> On 2/2/17 12:48 PM, Fujii Masao wrote:
>> +#define Query_for_list_of_subscriptions \
>> +" SELECT pg_catalog.quote_ident(subname) "\
>> +" FROM pg_catalog.pg_subscription "\
>> +"
On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao wrote:
> On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
> wrote:
>> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao wrote
>> in
>>> On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
>>> wrote:
>>> >
On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI
wrote:
> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao wrote
> in
>> On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
>> wrote:
>> > On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote:
>> >> Kyotaro HORIGUC
ist_of_subscriptions \
+" SELECT pg_catalog.quote_ident(subname) "\
+" FROM pg_catalog.pg_subscription "\
+" WHERE substring(pg_catalog.quote_ident(subname),1,%d)='%s'"
Since non-superuser is not allowed to access to pg_subscription,
pg_stat_subscription should be
ot; of the worker to kill, but its "proc" has not been set yet.
Without LogicalRepLauncherLock, this situation can happen after "subid"
is set by the launcher and before "proc" is set by the worker. But
LogicalRepLauncherLock protects those operations, so logicalrep_
e some functions can throw
> exceptions.
The lwlock would be released when an exception occurs, so I don't think
that TRY-CATCH is necessary here. Or it's necessary for another reason?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t page in the next segment has not been replicated), it
> becomes to happen on every page boundary until non-continuation
> page comes.
I'm afraid that many WAL segments would start with a continuation record
when there are the workload of short transactions (e.g., by pgbench
s okay?
>>
>> Thank you, I'm happy with your comment.
>>
>
> Okay, I have marked the patch as 'Ready for Committer'.
Pushed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 24, 2017 at 7:17 AM, Craig Ringer wrote:
> src/test/README wasn't updated for the new src/test/subscription entry.
>
> Patch attached.
Thanks! Pushed.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Sat, Jan 21, 2017 at 1:39 AM, Petr Jelinek
wrote:
> On 20/01/17 17:33, Jaime Casanova wrote:
>> On 20 January 2017 at 11:25, Petr Jelinek
>> wrote:
>>> On 20/01/17 17:05, Fujii Masao wrote:
>>>> On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut
>>
f
> produced WAL (=network traffic) given that it turns on logging of hint bits.
+1
If the performance overhead by the checksums is really negligible,
we may be able to get rid of wal_log_hints parameter, as well.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-ha
shii
>
> 2017-01-19 15:56 GMT+09:00 Ishii Ayumi :
>> Hi,
>>
>> Here is a patch that adds temporary column's description to
>> pg_replication_slots document.
This is the oversight of commit a924c32. Thanks for the patch! Pushed.
Regards,
--
Fujii Masao
--
Sent v
need to start up by default?
$ initdb -D data
$ pg_ctl -D data start
When I ran the above commands, I got the following message and
found that the bgworker for logical replicatdion launcher was running.
LOG: logical replication launcher started
Regards,
--
Fujii Masao
--
On Tue, Jan 17, 2017 at 10:37 PM, Michael Paquier
wrote:
> On Tue, Jan 17, 2017 at 5:40 PM, Fujii Masao wrote:
>> Fix an assertion failure related to an exclusive backup.
>>
>> Previously multiple sessions could execute pg_start_backup() and
>> pg_stop_backup() to
On Thu, Dec 22, 2016 at 6:14 AM, Thomas Munro
wrote:
> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao wrote:
>> I agree that the capability to measure the remote_apply lag is very useful.
>> Also I want to measure the remote_write and remote_flush lags, for example,
>> in
the functions like xlog_position in pg_create_physical_replication_slot, etc.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>
> Thanks for the review and the top-up patch. I've applied it and pushed.
- if (replication_slot && includewal != STREAM_WAL)
+ if ((replication_slot || no_slot) && includewal != STREAM_WAL)
Why do we need to check "no_slot" here? Since no_slot=true means that
no tem
On Mon, Jan 16, 2017 at 6:34 PM, Masahiko Sawada wrote:
> On Mon, Jan 16, 2017 at 6:27 PM, Fujii Masao wrote:
>> On Mon, Jan 16, 2017 at 5:42 PM, Masahiko Sawada
>> wrote:
>>> Hi,
>>>
>>> Attached patch fixes comment typos in condition_variable.
On Mon, Jan 16, 2017 at 5:42 PM, Masahiko Sawada wrote:
> Hi,
>
> Attached patch fixes comment typos in condition_variable.c
Seems the patch still has the typo. "initiailly" should be "initially"?
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list
think that -W is better as the default of at least "pg_ctl start".
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jan 12, 2017 at 6:46 PM, Simon Riggs wrote:
> On 12 January 2017 at 05:49, Fujii Masao wrote:
>> On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote:
>>> On 11 January 2017 at 09:51, Fujii Masao wrote:
>>>
>>>>> 5. recovery.conf parameters ar
please feel free to speak up.
To be pricise, I'd like to avoid the renaming of the functions at all rather
than using aliases.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote:
> On 11 January 2017 at 09:51, Fujii Masao wrote:
>
>>> 5. recovery.conf parameters are all moved to postgresql.conf, with these
>>> changes
>>
>> In current design of the patch, when recovery parame
1 - 100 of 2773 matches
Mail list logo
