actness of objects.
>>> The callers of SyncRepGetSyncStandbysUsingPriority() need to care
>>> the inside of SyncGroupNode but what the function should just
>>> return seems to be the list of wansnds element. Element number is
>>> useless when the SyncGroupNode nests.
>>> > int
>>> > SyncRepGetSyncStandbysUsingPriority(SyncGroupNode *group, volatile WalSnd
>>> > **sync_list)
>>> This might need to expose 'volatile WalSnd*' (only pointer type)
>>> outside of walsender.
>>> Or it should return the list of index number of
>>> *WalSndCtl->walsnds*.
>>
>> SyncRepGetSyncStandbysUsingPriority() already returns the list of
>> index number of "WalSndCtl->walsnd" as sync_list, no?
>> As I mentioned above, SyncRepGetSyncStandbysFn() doesn't need care the
>> inside of SyncGroupNode in my design.
>> Selecting sync nodes from its group doesn't depend on the type of node.
>> What SyncRepGetSyncStandbyFn() should do is to select sync node from
>> *its* group.
>>
>
> Previous patch has bug around GUC parameter handling.
> Attached updated version.
Thanks for updating the patch!
Now I'm fixing some problems (e.g., current patch doesn't work
with EXEC_BACKEND environment) and revising the patch.
I will post the revised version this weekend or the first half
of next week.
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 10, 2016 at 7:21 PM, Fujii Masao wrote:
> On Fri, Mar 4, 2016 at 3:40 AM, Masahiko Sawada wrote:
>> On Thu, Mar 3, 2016 at 11:30 PM, Masahiko Sawada
>> wrote:
>>> Hi,
>>>
>>> Thank you so much for reviewing this patch!
>>>
>>
On Tue, Mar 22, 2016 at 3:11 PM, Jeff Janes wrote:
> "skipped blocks are included this total"
>
> The word "in" is missing
Pushed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
the same regardless of which index
column(s) the query conditions use.
---
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
), or it should
be constructed during walsender startup (like latest version of the patch
does). IMO the latter is simpler.
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 23, 2016 at 2:28 AM, Masahiko Sawada wrote:
> On Tue, Mar 22, 2016 at 11:08 PM, Fujii Masao wrote:
>> On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI
>> wrote:
>>> Thank you for the revised patch.
>>
>> Thanks for reviewing the patch!
>
On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 22 Mar 2016 23:08:36 +0900, Fujii Masao wrote
> in
>> On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Thank you for the revised patch.
>>
>> Thanks
On Thu, Mar 24, 2016 at 2:26 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 24 Mar 2016 13:04:49 +0900, Masahiko Sawada
> wrote in
>> On Thu, Mar 24, 2016 at 11:34 AM, Fujii Masao wrote:
>> > On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI
>> >
idea do), this might cause more
serious problem. Please imagine the case where one walsender gets the fatal
error (e.g., because of OOM), abandon new setting value of
synchronous_standby_names, and keep running with the previous setting value.
OTOH, the other walsender processes successfu
ding_list() check whether the target index
is temporary index of other sessions or not, like pgstatginindex() does.
+RelationindexRel = index_open(indexoid, AccessShareLock);
ISTM that AccessShareLock is not safe when updating the pending list and
GIN index main structure. Probaby we should use RowExclusiveLock?
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,
I found the unused argument "vac_delay" in ginInsertCleanup().
I think that we should remove it. Patch attached.
Regards,
--
Fujii Masao
*** a/src/backend/access/gin/ginfast.c
--- b/src/backend/access/gin/ginfast.c
***
*** 434,440 ginHeapTupleFastInsert(GinState
On Thu, Jan 21, 2016 at 9:15 AM, Michael Paquier
wrote:
> On Wed, Jan 20, 2016 at 11:32 PM, Fujii Masao wrote:
>> I found the unused argument "vac_delay" in ginInsertCleanup().
>> I think that we should remove it. Patch attached.
>
> Visibly an oversight of dc943ad
ERIALIZED VIEW doesn't list the materialized views.
I added the following change to the patch to fix that problem. Patch attached.
- {"MATERIALIZED VIEW", NULL, NULL},
+ {"MATERIALIZED VIEW", NULL, &Query_for_list_of_matviews},
Regards,
--
Fujii Masao
On Tue, Jan 26, 2016 at 11:08 PM, Fujii Masao wrote:
> On Tue, Jan 26, 2016 at 10:25 PM, Michael Paquier
> wrote:
>> On Tue, Jan 26, 2016 at 9:52 PM, Masahiko Sawada
>> wrote:
>>> Tab completion for REFRESH command is oddly with following scenario.
>>&
> function. It is copy/paste bug - I used pg_size_pretty definition, so
>> > the
>> > question is: why pg_size_pretty is volatile? It should be immutable too.
>>
>> +1. This function relies only on the input of its argument to generate a
>> result.
>
>
>
uot;.
Probably we should improve that mechanism so that even multiple words can be
handled. Or we should just add something like the following.
/* Complete CREATE MATERIALIZED VIEW with */
+ else if (Matches3("CREATE", "MATERIALIZED", "VIEW"))
+
checks. Also, I think we should document that
index maintenance functions cannot be executed during recovery.
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
call.
> Including from within the checkpointer, when flushing WAL to be able to write
> out a page.
IMO it's more helpful to display such information in something like
pg_stat_walwriter view rather than checkpoint log message.
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
tely just after calling index_close(). No?
+/* Must have at least one unique index */
+Assert(foundUniqueIndex);
Can we guarantee that there is at least one valid unique index here?
If yes, it's better to write the comment about that.
Regards,
--
Fujii Masao
--
Sent via pg
On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes wrote:
> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao wrote:
>> On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud
>> wrote:
>>> On 15/01/2016 22:59, Jeff Janes wrote:
>>>> On Sun, Jan 10, 2016 at 4:24 AM, Julien Ro
On Thu, Jan 28, 2016 at 5:54 AM, Julien Rouhaud
wrote:
> On 27/01/2016 10:27, Fujii Masao wrote:
>> On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes
>> wrote:
>>> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao
>>> wrote:
>>>> On Sat, Jan 16, 2016 at 7:42 A
ICAL
options
+ START_REPLICATION SLOT
slot_name LOGICAL
XXX/XXX
(options)
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
uncomment it and set it to a value.
>>
>
> Thank you for having a look it.
>
> Yeah, synchronous_standby_num should not exists in postgresql.conf.
> Please test for multiple sync replication with latest patch.
In synchronous_replication_method = 'priority' case, when I set
synchronous_standby_names to invalid value like 'hoge,foo' and
reloaded the configuration file, the server crashed with
the following error. This crash should not happen.
FATAL: invalid input syntax for integer: "hoge"
+/*
+ * After read all synchronous replication configuration parameter, we apply
+ * settings according to replication method.
+ */
+ProcessSynchronousReplicationConfig();
Why does the above function need to be called in ProcessConfigFile(), i.e.,
by every postgres processes? I was thinking that only walsender should
call that to check which walsender is synchronous according to the setting.
When synchronous_replication_method = '1-priority' and
synchronous_standby_names = '*', I started one synchronous standby.
Then, when I ran "SELECT * FROM pg_stat_replication", I got the
following WARNING message.
WARNING: detected write past chunk end in ExprContext 0x2acb3c0
I don't think that it's good design to specify the number of sync replicas
to wait for, in synchronous_standby_names. It's confusing for the users.
It's better to add separate parameter (synchronous_standby_num) for
specifying that number. Which increases the number of GUC parameters,
though.
Are we really planning to implement synchronous_replication_method=quorum
at the first version? If not, I'd like to remove s_r_method parameter
because it's meaningless. We can add it later when we implement "quorum".
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
style TO lists nothing.
Attached patch fixes those problems.
Regards,
--
Fujii Masao
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***
*** 1553,1559 psql_completion(const char *text, int start, int end)
else if (Matches2("ALTER
On Thu, Jan 28, 2016 at 10:15 PM, Michael Paquier
wrote:
> On Thu, Jan 28, 2016 at 9:32 PM, Fujii Masao wrote:
>> I found that the following tab-completions for SET/RESET which
>> worked properly before doesn't work properly now in the master.
>>
>> 1. ALTER SYSTE
On Thu, Jan 28, 2016 at 10:50 PM, Masahiko Sawada wrote:
> On Thu, Jan 28, 2016 at 10:15 PM, Michael Paquier
> wrote:
>> On Thu, Jan 28, 2016 at 9:32 PM, Fujii Masao wrote:
>>> I found that the following tab-completions for SET/RESET which
>>> worked properly befor
On Thu, Jan 28, 2016 at 6:08 PM, Shulgin, Oleksandr
wrote:
> On Thu, Jan 28, 2016 at 9:42 AM, Craig Ringer wrote:
>>
>>
>> On 28 January 2016 at 16:36, Shulgin, Oleksandr
>> wrote:
>>>
>>> On Thu, Jan 28, 2016 at 5:55 AM, Fujii Masao
&g
On Fri, Jan 29, 2016 at 1:02 PM, Michael Paquier
wrote:
> On Fri, Jan 29, 2016 at 11:53 AM, Fujii Masao wrote:
>> I removed the above and added the following for that case.
>>
>> +/* Complete ALTER DATABASE|FUNCTION|ROLE|USER ... SET */
>> +else if (Matches2(
On Mon, Feb 1, 2016 at 3:14 PM, Michael Paquier
wrote:
> On Mon, Feb 1, 2016 at 1:21 PM, Fujii Masao wrote:
>> On Fri, Jan 29, 2016 at 1:02 PM, Michael Paquier
>> wrote:
>>> On Fri, Jan 29, 2016 at 11:53 AM, Fujii Masao wrote:
>>>> I removed the above a
gbench.sgml. skipped_transactions is
documented as the last field of the plain log, but the format of the log
doesn't include that as follows.
client_id transaction_no time file_no time_epoch time_us [schedule_lag]
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing l
On Mon, Feb 1, 2016 at 9:23 PM, Michael Paquier
wrote:
> On Mon, Feb 1, 2016 at 9:15 PM, Fujii Masao wrote:
>> If we do that, we also should change the tab-completion for SET command
>> so that "=" is suggested. But I'm afraid that which might decrease that
>&g
es listed in s_s_names".
Or
Add something like quorum_replication_num and quorum_standby_names, i.e.,
the master must wait for at least q_r_num standbys from ones listed in
q_s_names before marking sync replication as completed. Also the master
must wait for sync replication according to s_s_
On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote:
> On Mon, Feb 1, 2016 at 9:28 AM, Fujii Masao wrote:
>> So what about the following plan?
>>
>> [first version]
>> Add only synchronous_standby_num which specifies the number of standbys
>> that the master
al formula is
>
> ceil((max_connections + autovacuum_max_workers + 5) / 16)
>
>
> In 9.1, NUM_AUXILIARY_PROCS is 3 so the documentations is correct.
>
>
> I attached two patches for 9.2-9.3 and 9.4-9.6dev
> respectively. patch command complains a bit on applying it on
roken
> client.
+1
But, IIRC, one of the problems that prevent the adoption of this feature is
the addition of gettimeofday() call after every SQL command receipt.
Have you already resolved that problem? Or we don't need to care about
it because it's almost harmless?
Regards,
--
On Wed, Feb 3, 2016 at 11:00 AM, Robert Haas wrote:
> On Tue, Feb 2, 2016 at 8:48 PM, Fujii Masao wrote:
>> So you disagree with only third version that I proposed, i.e.,
>> adding some hooks for sync replication? If yes and you're OK
>> with the first and second ver
On Mon, Feb 8, 2016 at 9:53 AM, Jeff Janes wrote:
> On Wed, Jan 27, 2016 at 12:54 PM, Julien Rouhaud
> wrote:
>> On 27/01/2016 10:27, Fujii Masao wrote:
>>>
>>> Thanks for updating the patch! It looks good to me.
>>>
>>> Based on your patch, I jus
the node/group statuses, I guess that we
> would be in good shape for this patch.
>
> Anyway that's not a small project, and perhaps I am over-complicating
> the whole thing.
>
> Thoughts?
I agree that we would need something like such new view in the future,
however it see
On Thu, Jan 28, 2016 at 1:01 AM, Masahiko Sawada wrote:
> On Wed, Jan 27, 2016 at 4:42 PM, Fujii Masao wrote:
>> On Tue, Jan 26, 2016 at 9:33 PM, Masahiko Sawada
>> wrote:
>>> Hi all,
>>>
>>> In concurrently refreshing materialized view, we check wheth
On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
wrote:
> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
>> Thanks for updating the patch!
>> Attached is the updated version of the patch.
>> I removed unnecessary assertion check and change of source code
>> that
On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote:
> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
> wrote:
>> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
>>> Thanks for updating the patch!
>>> Attached is the updated version of the patch.
>>> I
Thanks for the patch! Will review it.
I think that it's time to write the documentation patch.
Though I've not read the patch yet, I found that your patch
changed s_s_names so that it rejects non-alphabet character
like *, according to my simple test. It should accept any
application_name which we can use.
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 5, 2016 at 2:17 PM, Kyotaro HORIGUCHI
wrote:
> At Thu, 4 Feb 2016 21:43:04 +0900, Fujii Masao wrote
> in
>> On Wed, Feb 3, 2016 at 12:51 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, I found that the formulas to calculate SEMMNI and SEMMNS
>>
On Mon, Feb 15, 2016 at 2:31 PM, Kyotaro HORIGUCHI
wrote:
> Thanks for looking at this.
>
> At Fri, 12 Feb 2016 23:19:45 +0900, Fujii Masao wrote
> in
>> >> ISTM that you also need to change the descriptions about SEMMNI and SEMMNS
>> >> under the Table
On Wed, Feb 10, 2016 at 10:35 AM, Michael Paquier
wrote:
> On Wed, Feb 10, 2016 at 2:23 AM, Fujii Masao wrote:
>> On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote:
>>> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
>>> wrote:
>>>> On Tue, Feb
On Fri, Feb 12, 2016 at 11:19 PM, Fujii Masao wrote:
> On Fri, Feb 5, 2016 at 2:17 PM, Kyotaro HORIGUCHI
> wrote:
>> At Thu, 4 Feb 2016 21:43:04 +0900, Fujii Masao wrote
>> in
>>> On Wed, Feb 3, 2016 at 12:51 PM, Kyotaro HORIGUCHI
>>> wrote:
>&
s changed to DB_IN_PRODUCTION and before the server is able to
start accepting normal (not read-only) connections. So if users try to
start write transaction just after pg_ctl promote -w ends, they might
get an error because the server is still in recovery, i.e., the startup
process is ru
Thanks for updating the patch!
When I changed s_s_names to 'hoge*' and reloaded the configuration file,
the server crashed unexpectedly with the following error message.
This is obviously a bug.
FATAL: syntax error
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing l
Hi,
Attached patch implements the tab-completion for CREATE USER MAPPING command.
Comments?
Regards,
--
Fujii Masao
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***
*** 656,661 static const SchemaQuery Query_for_list_of_matviews = {
--- 656,667
mlink approach not to break many existing tools
and scripts.
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
d be declared
>> inside directly the new while loop.
>
>
> Thanks Michael for reviewing the patch. I've fixed these issues and new
> version is attached.
The patch looks good to me. Barring any objections,
I'll push this and back-patch to 9.3 where pg_xlogdump was added.
Rega
/tot): 0/88, tx: 0, lsn:
0/04A4B7B0, prev 0/04A4B760, desc: VACUUM_DATA_LEAF_PAGE 1663
segments: 0 unknown action 0 ???, blkref #0: rel 1663/13286/16455 blk
21
rmgr: Gin len (rec/tot): 0/78, tx: 0, lsn:
0/04A4B808, prev 0/04A4B7B0, desc: VACUUM_DAT
On Fri, Aug 26, 2016 at 10:03 PM, Fujii Masao wrote:
> On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee
> wrote:
>>
>>
>> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier
>> wrote:
>>>
>>>
>>> + /*
>>> +
On Fri, Aug 26, 2016 at 11:35 PM, Fujii Masao wrote:
> On Tue, May 10, 2016 at 9:57 PM, Alexander Korotkov
> wrote:
>> Hi!
>>
>> On Mon, May 9, 2016 at 10:46 PM, Andres Freund wrote:
>>>
>>> trying to debug something I saw the following in pg_xlogdump
snupw+bdk5dctu7gwpnap-+-zwvk...@mail.gmail.com
---
* first k (n1, n2, n3) – does the same as k (n1, n2, n3) does now
* any k (n1, n2, n3) – would release waiters as soon as we have the
responses from k out of N standbys. “any k” would be faster, so is
desirable for performance and resilience
---
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 pg_stop_backup is running?
As far as I read the current code, ISTM that there is no need to do that,
but it's better to do the double check.
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
n (perhaps do nothing?)
> - Do nothing: Simon (add a README), Tom, Peter E
I vote for "do nothing".
First of all, I can't have much hope for that renaming the directories really
prevents "careless" users from wrongly deleting the important files.
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, Aug 30, 2016 at 1:32 PM, Michael Paquier
wrote:
> On Mon, Aug 29, 2016 at 11:16 PM, Fujii Masao wrote:
>> You seem to add another entry for this patch into CommitFest.
>> Either of them needs to be removed.
>> https://commitfest.postgresql.org/10/698/
>
> Inde
On Tue, Aug 30, 2016 at 3:39 AM, Tom Lane wrote:
> Fujii Masao writes:
>> ISTM that the cause of this issue is that gin_desc() uses XLogRecGetData() to
>> extract ginxlogVacuumDataLeafPage data from XLOG_GIN_VACUUM_DATA_LEAF_PAGE
>> record. Since it's registered b
On Tue, Aug 30, 2016 at 3:13 PM, Fujii Masao wrote:
> On Tue, Aug 30, 2016 at 3:39 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> ISTM that the cause of this issue is that gin_desc() uses XLogRecGetData()
>>> to
>>> extract ginxlogVacuumDataLeafPage data
On Wed, Aug 31, 2016 at 12:10 AM, Tom Lane wrote:
> Fujii Masao writes:
>> I found that pg_xlogdump code for XLOG_GIN_INSERT record with
>> GIN_INSERT_ISLEAF flag has the same issue, i.e.,
>> "unknown action 0" error is thrown for that record.
>> The latest
On Wed, Aug 31, 2016 at 8:32 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Wed, Aug 31, 2016 at 12:10 AM, Tom Lane wrote:
>>> Hmm, comparing gin_desc() to ginRedoInsert() makes me think there are more
>>> problems there than that one. Aren't the references to
On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs wrote:
> Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL
>
> lazy_truncate_heap() was waiting for
> VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds
> not milliseconds as originally intended.
Don't we need to back-patch this?
Regar
t | (null)
state_change | 2016-09-10 02:41:24.570135+09
wait_event_type | (null)
wait_event | (null)
state| idle
backend_xid | (null)
backend_xmin | (null)
query|
I think that this information is confusing and should not exist in
pg_stat_activity.
Reg
> 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
uld as well mention it directly
> in the page of pg_stat_replication but this information seems more
> suited if located in the HA section.
Yeah, I think it's better to mention them even in pg_stat_replication page.
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 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 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 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/
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
&
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
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
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 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
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
> 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
n log replication commands. Thought?
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 we know performs well and relying
> on it makes the life of user and developer easier.
IIUC even when we adopt only one algorithm, additional at least one bit is
necessary to see whether this backup block is compressed or not.
This flag is necessary only for backup block, so there is no n
ation slot is not used, thanks to this feature, pg_receivexlog
can flush WAL more proactively and which may improve the durability of WAL
which pg_receivexlog writes.
+printf(_(" -m, --sync-mode synchronous mode\n"));
I think that calling this feature "synchronous mode"
ch adds log_replication_command
parameter which causes replication commands to be logged. I added this to
next CF.
Regards,
--
Fujii Masao
From 9874e36a8f65667d1f4d3a9a8d1d87d2d20f5188 Mon Sep 17 00:00:00 2001
From: MasaoFujii
Date: Thu, 12 Jun 2014 19:32:00 +0900
Subject: [PATCH] Add log_replic
when the
system admin
enables it in postgresql.conf. Isn't this problematic for audit?
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
are not allowed to be set by
ALTER SYSTEM SET?
data_directory was displayed when I typed "TAB" just after ALTER SYSTEM SET.
Probably tab-completion for ALTER SYSTEM SET needs to be changed.
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
ough the WAL record which indicates the end of backup won't
> come. This option could be used to forcibly finish the blocked
> recovery procedure.
The document about pg_resetxlog needs to be updated.
I think that pg_resetxlog should reset backup locations by default
since they are use
ange anyway. IMHO it was always a bit strange that rm_desc was
>> passed the info field and record payload separately.
+1, too.
-/* #define WAL_DEBUG */
+#define WAL_DEBUG
ISTM you just forgot to exclude this change from the patch.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers
On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao wrote:
> Hi,
>
> Some users enable log_disconnections in postgresql.conf to audit all logouts.
> But since log_disconnections is defined with PGC_BACKEND, it can be changed
> at connection start. This means that any client (even no
ry
> will become clumsy, another could be to have another column in pg_settings.
> Do you think of any other way?
I like the latter idea, i.e., exposing the flags of GUC parameters in
pg_settings,
but it seems overkill just for tab-completion purpose. I'd withdraw my comment.
Regar
t actually the description made me confused a bit.
Could you check 8dc90b9c4c45fa30a8f59313e21d294529ef7182 in REL9_3_STABLE
branch? You can see that I added the description of pg_stat directory
into the document
in 9.3.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql
t; Fujji-san.
>
> Yes, what you've done in v3 of the patch is what I meant. I've marked
> this as ready for committer now.
Barring objections, I will commit this patch.
Also I'm thinking to backpatch this to 9.4 because this is a bugfix rather
than new feature.
Regards,
-
age:
>
> http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html
ISTM that this patch has already been committed by Bruce. Please see
the commit 72590b3a69baaf24d1090a2c2ceb9181be34043e
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On Wed, Jun 18, 2014 at 1:07 PM, Abhijit Menon-Sen wrote:
> At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote:
>>
>> Also I'm thinking to backpatch this to 9.4 because this is a bugfix
>> rather than new feature.
>
> That sounds reasonable, thanks.
Commi
f status interval timeout has not been passed yet. If you
want to send the feedback as soon as WAL is written or flushed, like
walreceiver does, you need to extend --status-interval option, for example,
so that it accepts the value "-1" which means enabling that behavior.
Including th
c: In function 'heap_endscan':
heapam.c:1808: error: 'struct HeapScanDescData' has no member named
'rs_Unread_Pfetched_base'
heapam.c:1809: error: 'struct HeapScanDescData' has no member named
'rs_Unread_Pfetched_base'
make[4]: *** [heapam.o] E
. Thanks to the patch, log_statement can be set
to "none",
"ddl", "mod", "dml", "all", and any combinations of them. The meanings of
"none", "ddl", "mod" and "all" are the same as they are now. New setting value
"
On Fri, Jun 13, 2014 at 11:29 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao wrote:
>>> Some users enable log_disconnections in postgresql.conf to audit all
>>> logouts.
>>> But since log_disconnections is defined
On Sun, Jun 22, 2014 at 8:54 PM, Simon Riggs wrote:
> On 13 June 2014 12:27, Fujii Masao wrote:
>
>> I think that pg_resetxlog should reset backup locations by default
>> since they are useless (rather harmful) after pg_resetxlog. Thought?
>
> +1
>
> Do we regard t
possibility to set password (not
recommended)\n"));
+ printf(_(" PGPASSFILE password file (default ~/.pgpass)\n"));
I don't think that psql needs to display the help messages of even environment
variables supported by libpq.
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, Jun 23, 2014 at 3:49 PM, Kyotaro HORIGUCHI
wrote:
> Hello, thank you for the comments.
>
>> On Sun, Jun 22, 2014 at 8:54 PM, Simon Riggs wrote:
>> > On 13 June 2014 12:27, Fujii Masao wrote:
>> >
>> >> I think that pg_resetxlog should reset ba
On Sat, Jun 21, 2014 at 12:59 PM, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/13/2014 07:29 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> On Thu, Jun 12, 2014 at 8:51 PM, Fujii Masao
>>> wrote:
>>>> Some users
On Mon, Jun 23, 2014 at 5:10 PM, Pavel Stehule wrote:
> Hello
>
>
> 2014-06-23 10:02 GMT+02:00 Fujii Masao :
>
>> On Mon, Jun 23, 2014 at 12:04 AM, Pavel Stehule
>> wrote:
>> > Hello
>> >
>> > third version with Erik's update
>>
load this file. \quit
The message should be something like "ALTER EXTENSION pg_buffercache
UPDATE TO '1.1'".
+/* might not be used, but the array is long enough */
+values[8] = Int32GetDatum(fctx->record[i].pinning_backends);
+ nulls[8] = false
1 - 100 of 2773 matches
Mail list logo
