On Tue, Jul 21, 2015 at 3:50 PM, Michael Paquier
wrote:
> On Mon, Jul 20, 2015 at 9:59 PM, Beena Emerson
> wrote:
>> Simon Riggs wrote:
>>
>>> The choice between formats is not
>>> solely predicated on whether we have multi-line support.
>>
>>> I still think writing down some actual use cases wo
On Wed, Jul 15, 2015 at 3:07 AM, Sawada Masahiko wrote:
> On Wed, Jul 15, 2015 at 12:55 AM, Simon Riggs wrote:
>> On 10 July 2015 at 15:11, Sawada Masahiko wrote:
>>>
>>>
>>> Oops, I had forgotten to add new file heapfuncs.c.
>>> Latest patch is att
On Wed, Jul 15, 2015 at 12:55 AM, Simon Riggs wrote:
> On 10 July 2015 at 15:11, Sawada Masahiko wrote:
>>
>>
>> Oops, I had forgotten to add new file heapfuncs.c.
>> Latest patch is attached.
>
>
> I think we've established the approach is desirable an
On Mon, Jul 13, 2015 at 9:22 PM, Andres Freund wrote:
> On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote:
>> Even If we implement rewriting tool for vm into pg_upgrade, it will
>> take time as much as revacuum because it need whole scanning table.
>
> Why would it? S
On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote:
> Hello,
>
> Tue, Jul 7, 2015 at 02:56 AM, Josh Berkus wrote:
>> pro-JSON:
>>
>> * standard syntax which is recognizable to sysadmins and devops.
>> * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make
>> additions/deletions fro
On Mon, Jul 13, 2015 at 7:46 PM, Amit Kapila wrote:
> On Mon, Jul 13, 2015 at 3:39 PM, Sawada Masahiko
> wrote:
>>
>> On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs wrote:
>> > On 6 July 2015 at 17:28, Simon Riggs wrote:
>> >
>> >> I think we need
On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs wrote:
> On 6 July 2015 at 17:28, Simon Riggs wrote:
>
>> I think we need something for pg_upgrade to rewrite existing VMs.
>> Otherwise a large read only database would suddenly require a massive
>> revacuum after upgrade, which seems bad. That can wai
On Fri, Jul 10, 2015 at 10:43 PM, Fujii Masao wrote:
> On Fri, Jul 10, 2015 at 2:41 PM, Sawada Masahiko
> wrote:
>> On Fri, Jul 10, 2015 at 3:05 AM, Sawada Masahiko
>> wrote:
>>>
>>> Also something for pg_upgrade is also not yet.
>>>
>>>
On Fri, Jul 10, 2015 at 3:42 AM, Jeff Janes wrote:
> On Wed, Jul 8, 2015 at 10:10 PM, Sawada Masahiko
> wrote:
>>
>> On Thu, Jul 9, 2015 at 4:31 AM, Jeff Janes wrote:
>> > On Fri, Jul 3, 2015 at 1:25 AM, Sawada Masahiko
>> > wrote:
>> >>
>>
On Fri, Jul 10, 2015 at 3:05 AM, Sawada Masahiko wrote:
>
> Also something for pg_upgrade is also not yet.
>
> TODO
> - Test case for this feature
> - pg_upgrade support.
>
I had forgotten to change the fork name of visibility map to "vfm".
Attached latest v7 pa
On Tue, Jul 7, 2015 at 8:49 PM, Amit Kapila wrote:
> On Thu, Jul 2, 2015 at 9:00 PM, Sawada Masahiko
> wrote:
>>
>>
>> Thank you for bug report, and comments.
>>
>> Fixed version is attached, and source code comment is also updated.
>> Please review i
On Thu, Jul 9, 2015 at 4:31 AM, Jeff Janes wrote:
> On Fri, Jul 3, 2015 at 1:25 AM, Sawada Masahiko
> wrote:
>>
>> On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs wrote:
>> > On 2 July 2015 at 16:30, Sawada Masahiko wrote:
>> >
>> >>
>> &g
o find in all the log
> messages.
> Having control of separate logging for background tasks will serve such
> a purpose.
>
+1
I sometime want to set log_min_messages per process, especially when
less than DEBUG level log is needed.
It's not easy to set log level to particular process from immediately
after beginning of launch today.
Regards,
--
Sawada Masahiko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e in some cases user
> might want to see the messages by all bgworkers and in some cases one
> might want to see just messages by AutoVacuum and it's workers.
>
> I think here designing User Interface is an important work if others also
> agree
> that such an option is useful, could you pl
gt; core at some point, but that's probably a separate discussion.
>
I understood.
So I will place bunch of test like src/test/module/visibilitymap_test,
which contains some tests regarding this feature,
and gather them into one patch.
Regards,
--
Sawada Masahiko
--
Sent via pgsql-ha
it helps for testing this feature.
> I think we need something for pg_upgrade to rewrite existing VMs.
> Otherwise a large read only database would suddenly require a massive
> revacuum after upgrade, which seems bad. That can wait for now until we all
> agree this patch is sound.
Yeah,
; grammer.
>
If we set the remote disaster recovery site up as synch replica, we
would get some big latencies even though we use quorum commit.
So I think this case Fujii-san suggested is a good configuration, and
many users would want to use it.
I tend to agree with combine quorum and priori
On Fri, Jul 3, 2015 at 5:25 PM, Sawada Masahiko wrote:
> On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs wrote:
>> On 2 July 2015 at 16:30, Sawada Masahiko wrote:
>>
>>>
>>> Also, the flags of each heap page header might be set PD_ALL_FROZEN,
>>> as well
On Fri, Jul 3, 2015 at 6:23 PM, Fujii Masao wrote:
> On Fri, Jul 3, 2015 at 5:59 PM, Sawada Masahiko wrote:
>> Yeah, quorum commit is helpful for minimizing data loss in comparison
>> with today replication.
>> But in this your case, how can we know which server we shou
um commit, we can guarantee that either london_server
> or nyc_server has all the data which have been committed in the master.
>
> So I think that quorum commit is helpful for minimizing the data loss.
>
Yeah, quorum commit is helpful for minimizing data loss in comparison
with today replication.
But in this your case, how can we know which server we should use as
the next master server, after local data center got down?
If we choose a wrong one, we would get the data loss.
Regards,
--
Sawada Masahiko
--
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, Jul 3, 2015 at 1:23 AM, Simon Riggs wrote:
> On 2 July 2015 at 16:30, Sawada Masahiko wrote:
>
>>
>> Also, the flags of each heap page header might be set PD_ALL_FROZEN,
>> as well as all-visible
>
>
> Is it possible to have VM bits set to frozen but
On Thu, Jul 2, 2015 at 1:06 AM, Fujii Masao wrote:
> On Thu, Jul 2, 2015 at 12:13 AM, Sawada Masahiko
> wrote:
>> On Thu, May 28, 2015 at 11:34 AM, Sawada Masahiko
>> wrote:
>>> On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko
>>> wrote:
>>&
On Thu, May 28, 2015 at 11:34 AM, Sawada Masahiko wrote:
> On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko
> wrote:
>> On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko
>> wrote:
>>> On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby wrote:
>>>>
what happens *today* if we have two different synch rep
> strings in two different *.conf files? I wouldn't assume that anyone
> has tested this ...
We use last defied parameter even if sync rep strings in several file, right?
Regards,
--
Sawada Masahiko
--
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 29, 2015 at 11:42 PM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane wrote:
>>> So let me make a radical proposal that both gets rid of the portability
>>> problem and, arguably, makes the view more useful than
successfully or not, right?
The such a feature would be also good, but the main purpose of
pg_file_settings was to resolve where each GUC parameter came from,
especially in case of using ALTER SYSTEM command.
I'm not sure that it would be adequate for our originally purpose.
Regards,
--
Sawada Masahiko
--
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 29, 2015 at 12:01 AM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane wrote:
>>> However there's a further tweak to the view that I'd like to think about
>>> making. Once this is in and we make the origin
ization set (if rep1
> fails, try rep2). I can imagine use cases for either mode, but not one
> which would involve doing both together.
>
Yep, separating the GUC parameter between prioritization and quorum
could be also good idea.
Also I think that we must enable us to decide which serve
set to return true.
>
> When k is not defined for a group, k = 1. Using only elements
> separated by commas for the upper group means that we wait for the
> first element in the set (for backward compatibility), hence:
> 1(elt1,elt2,eltN) <=> elt1,elt2,eltN
>
I think that
's default value if pg_file_settings does not have that entry.
Because of above reason, I think it's enough to mark which entry was
not applied due to contain error in its config file rather than
marking which entry was applied.
For example, the 'ignored' column of the ignored p
earlier, and some other things I've found while hacking
> on the view patch) that we would have to deal with in some other
> way if we revert now. I'd just as soon not detangle that.
>
Thank you for bug report.
I have not came up with portable idea yet, but I will deal wi
27; and 'c' are potential sync node, and the quorum commit is
enable only between 'a' and 'b'.
- s_s_name = 'a, 1(b,c), d'
priority of 'a' is 1, 'b' and 'c' are 2, 'd' is 3.
So the quorum commit with 'b' and 'c' will be enabled after 'a' down.
With this idea, I think that we could use conventional syntax as in the past.
Though?
Regards,
--
Sawada Masahiko
--
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, Jun 17, 2015 at 4:11 PM, Jim Nasby wrote:
> On 6/16/15 8:26 AM, Sawada Masahiko wrote:
>>
>> I noticed while using gin function of pageinspect that there are some
>> inconsistency data types.
>> For example, data type of GinMetaPageData.head, and tail is
_tail from
gin_metapage_info(get_raw_page('trgm_idx'::text, 0));
pending_head | pending_tail
+--
-1 | -1
There are some similar cases except above, so the fixing patch around
ginfunc.c is attached.
Regards,
---
On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko wrote:
> On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko
> wrote:
>> On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby wrote:
>>> On 4/23/15 11:06 AM, Petr Jelinek wrote:
>>>>
>>>> On 23/04/15 17:45, Br
cated extensible feature could be extension module,
i.g. contrib. And we could implement more simpler feature into
PostgreSQL core with some restriction.
Regards,
---
Sawada Masahiko
--
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, May 14, 2015 at 9:58 AM, Robert Haas wrote:
> On Wed, May 13, 2015 at 8:25 PM, Sawada Masahiko
> wrote:
>> The v15 patch emits a line for each table when reindexing multiple
>> tables, and emits a line for each index when reindexing single table.
>> But v14 pat
and emits a line for each index when reindexing single table.
But v14 patch emits a line for each index, regardless of reindex target.
Should I change back to v14 patch?
Regards,
---
Sawada Masahiko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for each
> index in the single-table mode, it seems more sensible to do the same
> for the multi-table forms also.
>
I agree that we emit lines for each table when we do reindex multiple tables.
The latest patch is attached.
Regards,
---
Sawada Masahiko
000_reindex_verbose_v15.p
On Thu, May 14, 2015 at 12:28 AM, Robert Haas wrote:
> On Thu, May 7, 2015 at 6:55 PM, Sawada Masahiko wrote:
>> Sorry, I forgot attach files.
>
> Review comments:
>
> - Customarily we use int, rather than uint8, for flags variables. I
> think we should do that here a
Hi all,
Attached patch fixes the typo is in reindexdb documentation regarding
REINDEX SCHEMA.
Regards,
---
Sawada Masahiko
diff --git a/doc/src/sgml/ref/reindexdb.sgml b/doc/src/sgml/ref/reindexdb.sgml
index b5b449c..a745f6c 100644
--- a/doc/src/sgml/ref/reindexdb.sgml
+++ b/doc/src/sgml
On Sun, May 10, 2015 at 2:23 AM, Sawada Masahiko wrote:
> On Sat, May 9, 2015 at 4:26 AM, Fabrízio de Royes Mello
> wrote:
>>
>>
>> On Fri, May 8, 2015 at 4:23 PM, Fabrízio de Royes Mello
>> wrote:
>>>
>>>
>>> On Thu, May 7, 2015 at 7
On Sat, May 9, 2015 at 4:26 AM, Fabrízio de Royes Mello
wrote:
>
>
> On Fri, May 8, 2015 at 4:23 PM, Fabrízio de Royes Mello
> wrote:
>>
>>
>> On Thu, May 7, 2015 at 7:55 PM, Sawada Masahiko
>> wrote:
>> >
>> > On 5/7/15, Sawada Masahiko
On 5/7/15, Sawada Masahiko wrote:
> On Wed, May 6, 2015 at 5:42 AM, Robert Haas > wrote:
>> On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko > wrote:
>>> On Fri, May 1, 2015 at 9:04 PM, Robert Haas > wrote:
>>>> On Thu, Apr 30, 2015 at 11:05 PM, Sawada M
On Wed, May 6, 2015 at 5:42 AM, Robert Haas > wrote:
> On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko > wrote:
>> On Fri, May 1, 2015 at 9:04 PM, Robert Haas > wrote:
>>> On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko > wrote:
>>>> VACUUM has
On Fri, May 1, 2015 at 9:04 PM, Robert Haas wrote:
> On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko
> wrote:
>> VACUUM has both syntax: with parentheses and without parentheses.
>> I think we should have both syntax for REINDEX like VACUUM does
>> because it would be
On Fri, May 1, 2015 at 6:24 AM, David Steele wrote:
> On 4/30/15 6:05 AM, Fujii Masao wrote:
>> On Thu, Apr 30, 2015 at 12:57 PM, Sawada Masahiko
>> wrote:
>>>
>>> I have changed the status this to "Ready for Committer".
>>
>> The spe
On Fri, May 1, 2015 at 1:38 AM, Robert Haas wrote:
> On Thu, Apr 30, 2015 at 9:15 AM, Sawada Masahiko
> wrote:
>> On Thu, Apr 30, 2015 at 8:39 PM, Robert Haas wrote:
>>> On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko
>>> wrote:
>>>> Attached v
On Thu, Apr 30, 2015 at 8:39 PM, Robert Haas wrote:
> On Thu, Apr 30, 2015 at 6:37 AM, Sawada Masahiko
> wrote:
>> Attached v10 patch is latest version patch.
>> The syntax is,
>> REINDEX { INDEX | ... } name [ WITH ] [ VERBOSE ]
>>
>> That is, WITH clause
On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko wrote:
> On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby wrote:
>> On 4/23/15 11:06 AM, Petr Jelinek wrote:
>>>
>>> On 23/04/15 17:45, Bruce Momjian wrote:
>>>>
>>>> On Thu, Apr 23, 2015 at 09:45:3
On Fri, Apr 10, 2015 at 2:52 AM, Sawada Masahiko wrote:
> On Thu, Apr 9, 2015 at 1:14 PM, Fujii Masao wrote:
>> On Wed, Apr 8, 2015 at 10:53 PM, Sawada Masahiko
>> wrote:
>>> On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao wrote:
>>>> On Wed, Apr 8, 2015 at 1
On Wed, Apr 29, 2015 at 12:17 AM, David Steele wrote:
> On 4/28/15 2:14 AM, Sawada Masahiko wrote:
>> On Fri, Apr 24, 2015 at 3:23 AM, David Steele wrote:
>>> I've also added some checking to make sure that if anything looks funny
>>> on the stack an error will
onfiguration files".
>
> The view does give information about all configuration files regardless
> of how they were created.
>
> That's what I intended the text to say but I think your phrasing is clearer.
>
Thank you for reviewing.
I agree with this.
Attached pat
On Wed, Apr 29, 2015 at 12:20 AM, David Steele wrote:
> On 4/27/15 10:37 PM, Sawada Masahiko wrote:
>>
>> Thank you for your reviewing.
>> Attached v8 patch is latest version.
>
> I posted a review through the CF app but it only went to the list
> instead of re
On Fri, Apr 24, 2015 at 3:23 AM, David Steele wrote:
> On 4/23/15 5:49 AM, Sawada Masahiko wrote:
>>
>> I'm concerned that behaviour of pg_audit has been changed at a few
>> times as far as I remember. Did we achieve consensus on this design?
>
> The original auth
On Tue, Apr 28, 2015 at 3:22 AM, David Steele wrote:
> On 4/27/15 10:31 AM, Sawada Masahiko wrote:
>> Thank you for your review comment!
>> The latest patch is attached.
>
> Looks good overall - a few more comments below:
Thank you for your reviewing.
Attached v8 patch is la
On Mon, Apr 27, 2015 at 11:31 PM, Sawada Masahiko wrote:
> On Sat, Apr 25, 2015 at 3:40 AM, David Steele wrote:
>> On 4/4/15 9:21 AM, Sawada Masahiko wrote:
>>> I added documentation changes to patch is attached.
>>> Also I tried to use memory context for allocation
On Sat, Apr 25, 2015 at 3:40 AM, David Steele wrote:
> On 4/4/15 9:21 AM, Sawada Masahiko wrote:
>> I added documentation changes to patch is attached.
>> Also I tried to use memory context for allocation of guc_file_variable
>> in TopMemoryContext,
>> but it was f
e efficiently counting how many things in a byte are set. Probably
> doesn't make sense to fully refactor it, but at least CLOG is a good source
> for cut/paste/whack.
>
I agree with adding a bit that indicates corresponding page is
all-frozen into VM, just like CLOG.
I'l
On Mon, Apr 20, 2015 at 10:17 PM, David Steele wrote:
> On 4/20/15 4:40 AM, Sawada Masahiko wrote:
>>
>> Thank you for updating the patch.
>>
>> One question about regarding since v7 (or later) patch is;
>> What is the different between OBJECT logging and SESSI
Yeah. We have a serious need to reduce the size of our on-disk
> format. On a TPC-C-like workload Jan Wieck recently tested, our data
> set was 34% larger than another database at the beginning of the test,
> and 80% larger by the end of the test. And we did twice the disk
> wri
On Wed, Apr 22, 2015 at 12:02 AM, Andres Freund wrote:
> On 2015-04-21 23:59:45 +0900, Sawada Masahiko wrote:
>> The page as frozen could have the dead tuple for now, but I think to change
>> to that the frozen page guarantees that page is all frozen *and* all
>> visible.
>
On Tue, Apr 21, 2015 at 7:00 AM, Jim Nasby wrote:
> On 4/20/15 2:45 AM, Sawada Masahiko wrote:
>>
>> Current patch adds new source file src/backend/access/heap/frozenmap.c
>> which is quite similar to visibilitymap.c. They have similar code but
>> are separated for
On Thu, Apr 16, 2015 at 2:34 AM, David Steele wrote:
> On 4/15/15 11:30 AM, Sawada Masahiko wrote:
>> On Wed, Apr 15, 2015 at 10:52 AM, Sawada Masahiko
>> wrote:
>>> I tested v8 patch with CURSOR case I mentioned before, and got
>>> segmentation fault again
On Tue, Apr 7, 2015 at 11:22 AM, Sawada Masahiko wrote:
> On Tue, Apr 7, 2015 at 7:53 AM, Jim Nasby wrote:
>> On 4/6/15 5:18 PM, Greg Stark wrote:
>>>
>>> Only I would suggest thinking of it in terms of two orthogonal boolean
>>> flags rather than three
On Wed, Apr 15, 2015 at 10:52 AM, Sawada Masahiko wrote:
> On Wed, Apr 15, 2015 at 8:57 AM, David Steele wrote:
>> On 4/14/15 7:13 PM, Tatsuo Ishii wrote:
>>> This patch does not apply cleanly due to the moving of pgbench (patch
>>> to filelist.sgml failed).
>>
&
INT: In a moment you should be able to reconnect to the database and
repeat your command.
FATAL: the database system is in recovery mode
I hope that these messages helps you to address this problem.
I will also try to address this.
Regards,
---
Sawada Masahiko
--
Sent via pgsql-hackers mailing
On Thu, Apr 9, 2015 at 1:14 PM, Fujii Masao wrote:
> On Wed, Apr 8, 2015 at 10:53 PM, Sawada Masahiko
> wrote:
>> On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao wrote:
>>> On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko
>>> wrote:
>>>> On Wed, Apr 8
On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao wrote:
> On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko wrote:
>> On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello
>> wrote:
>>>
>>> On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko
>>> wrote:
On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello
wrote:
>
> On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko
> wrote:
>>
>> On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio de Royes Mello
>> wrote:
>> >
>> > On Tue, Apr 7, 2015 at 7:22 AM, Sawada Ma
On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio de Royes Mello
wrote:
>
> On Tue, Apr 7, 2015 at 7:22 AM, Sawada Masahiko
> wrote:
>>
>> Thank you for your reviewing.
>> I modified the patch and attached latest version patch(v7).
>> Please have a look it.
>>
&
On Tue, Apr 7, 2015 at 9:32 AM, Fabrízio de Royes Mello
wrote:
>
> On Mon, Apr 6, 2015 at 10:21 AM, Sawada Masahiko
> wrote:
>>
>> On Fri, Mar 13, 2015 at 5:10 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, I have some trivial comments about the latest patch.
&g
has. And DDL command which changes these status is like ALTER
TABLE SET READ ONLY, or READ WRITE.
Also as Alvaro's suggested, the read-only table affect not only
freezing table but also performance optimization. I'll consider
including them when I deal with read-only table.
Regards,
---
Sawada Masahiko
--
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, Apr 6, 2015 at 10:17 PM, Jim Nasby wrote:
> On 4/6/15 1:46 AM, Sawada Masahiko wrote:
>>
>> On Sun, Apr 5, 2015 at 8:21 AM, Jeff Janes wrote:
>>>
>>> On Sat, Apr 4, 2015 at 3:10 PM, Jim Nasby
>>> wrote:
>>>&g
On Fri, Mar 13, 2015 at 5:10 PM, Kyotaro HORIGUCHI
wrote:
> Hello, I have some trivial comments about the latest patch.
>
> At Thu, 12 Mar 2015 21:15:14 +0900, Sawada Masahiko
> wrote in
> sawada.mshk> On Thu, Mar 12, 2015 at 6:36 AM, Jim Nasby
> wrote:
>> >>
On Fri, Apr 3, 2015 at 10:01 PM, David Steele wrote:
> On 4/3/15 3:59 AM, Sawada Masahiko wrote:
>> On Thu, Apr 2, 2015 at 2:46 AM, David Steele wrote:
>>> Let me know if you see any other issues.
>>>
>>
>> I pulled HEAD, and then tried to compile
On Fri, Apr 3, 2015 at 10:01 PM, David Steele wrote:
> On 4/3/15 3:59 AM, Sawada Masahiko wrote:
>> On Thu, Apr 2, 2015 at 2:46 AM, David Steele wrote:
>>> Let me know if you see any other issues.
>>>
>>
>> I pulled HEAD, and then tried to compile
On Sun, Apr 5, 2015 at 8:21 AM, Jeff Janes wrote:
> On Sat, Apr 4, 2015 at 3:10 PM, Jim Nasby wrote:
>>
>> On 4/3/15 12:59 AM, Sawada Masahiko wrote:
>>>
>>> + case HEAPTUPLE_LIVE:
>>> +
On Wed, Mar 11, 2015 at 11:46 PM, Sawada Masahiko wrote:
> On Tue, Mar 10, 2015 at 12:08 PM, Stephen Frost wrote:
>> Sawada,
>>
>> * Sawada Masahiko (sawada.m...@gmail.com) wrote:
>>> Thank you for your review!
>>> Attached file is the latest version (witho
On Thu, Apr 2, 2015 at 2:46 AM, David Steele wrote:
> Hi Sawada,
>
> On 3/25/15 9:24 AM, David Steele wrote:
>> On 3/25/15 7:46 AM, Sawada Masahiko wrote:
>>> 2.
>>> I got ERROR when executing function uses cursor.
>>>
>>> 1) create empty table
DIT: SESSION,6,1,READ,SELECT,,,selecT test();
LOG: AUDIT: SESSION,6,2,FUNCTION,EXECUTE,FUNCTION,public.test,selecT test();
LOG: AUDIT: SESSION,6,3,READ,SELECT,,,select * from hoge
CONTEXT: PL/pgSQL function test() line 6 at OPEN
ERROR: pg_audit stack is already empty
STATEMENT: selecT test();
It seems like that the item in stack is already freed by deleting
pg_audit memory context (in MemoryContextDelete()),
before calling stack_pop in dropping of top-level Portal.
Regards,
---
Sawada Masahiko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi David,
Thank you for your answer!
On Wed, Mar 25, 2015 at 12:38 AM, David Steele wrote:
> Hi Sawada,
>
> Thank you for taking the time to look at the patch.
>
> On 3/24/15 10:28 AM, Sawada Masahiko wrote:
>> I've applied these patchese successfully.
>>
>>
On Tue, Mar 24, 2015 at 3:17 AM, Alvaro Herrera
wrote:
> Sawada Masahiko wrote:
>
>> I tied to look into latest patch, but got following error.
>>
>> masahiko [pg_audit] $ LANG=C make
>> gcc -Wall -Wmissing-prototypes -Wpointer-arith
>> -Wdeclaration-after-s
lized and
> MemoryContextRegisterResetCallback() is used to cleanup the stack on errors.
>
> Let me know what you think.
>
Hi,
I tied to look into latest patch, but got following error.
masahiko [pg_audit] $ LANG=C make
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -g -fpic -I. -I. -I../../src/include -D_GNU_SOURCE -c -o
pg_audit.o pg_audit.c
pg_audit.c: In function 'log_audit_event':
pg_audit.c:456: warning: ISO C90 forbids mixed declarations and code
pg_audit.c: In function 'pg_audit_ddl_command_end':
pg_audit.c:1436: error: 'pg_event_trigger_expand_command' undeclared
(first use in this function)
pg_audit.c:1436: error: (Each undeclared identifier is reported only once
pg_audit.c:1436: error: for each function it appears in.)
make: *** [pg_audit.o] Error 1
Am I missing something?
Regards,
---
Sawada Masahiko
--
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 12, 2015 at 6:36 AM, Jim Nasby wrote:
> On 3/11/15 6:33 AM, Sawada Masahiko wrote:
>>>>>>>
>>>>>>> As a refresher, current commands are:
>>>>>>> >>>>>
>>>>>>> >>>>>
On Tue, Mar 10, 2015 at 5:05 PM, Jim Nasby wrote:
> On 3/9/15 9:43 PM, Sawada Masahiko wrote:
>>
>> On Fri, Mar 6, 2015 at 11:07 AM, Jim Nasby
>> wrote:
>>>
>>> On 3/2/15 10:58 AM, Sawada Masahiko wrote:
>>>>
>>>>
>>>> O
On Tue, Mar 10, 2015 at 12:08 PM, Stephen Frost wrote:
> Sawada,
>
> * Sawada Masahiko (sawada.m...@gmail.com) wrote:
>> Thank you for your review!
>> Attached file is the latest version (without document patch. I making it
>> now.)
>> As per discussion, ther
On Tue, Mar 10, 2015 at 5:05 PM, Jim Nasby wrote:
> On 3/9/15 9:43 PM, Sawada Masahiko wrote:
>>
>> On Fri, Mar 6, 2015 at 11:07 AM, Jim Nasby
>> wrote:
>>>
>>> On 3/2/15 10:58 AM, Sawada Masahiko wrote:
>>>>
>>>>
>>>> O
On Fri, Mar 6, 2015 at 11:07 AM, Jim Nasby wrote:
> On 3/2/15 10:58 AM, Sawada Masahiko wrote:
>>
>> On Wed, Feb 25, 2015 at 4:58 PM, Jim Nasby
>> wrote:
>>>
>>> On 2/24/15 8:28 AM, Sawada Masahiko wrote:
>>>>>
>>>>>
&g
: REINDEX DATABASE cannot run inside a transaction block
STATEMENT: reindex system postgres;
Regards,
---
Sawada Masahiko
fix_reindex_error_message.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On Sat, Feb 28, 2015 at 2:27 PM, Stephen Frost wrote:
> Sawada,
>
> * Sawada Masahiko (sawada.m...@gmail.com) wrote:
>> Attached patch is latest version including following changes.
>> - This view is available to super use only
>> - Add sourceline coulmn
>
> Al
On Wed, Feb 25, 2015 at 4:58 PM, Jim Nasby wrote:
> On 2/24/15 8:28 AM, Sawada Masahiko wrote:
>>>
>>> According to the above discussion, VACUUM and REINDEX should have
>>> trailing options. Tom seems (to me) suggesting that SQL-style
>>> (bare word prece
.)]
>
> =# REINDEX TABLE t1 (VERBOSE);
>
> REINDEX [{INDEX|TABLE|...}] name [WITH {VERBOSE [bool]|...}]
>
> =# REINDEX INDEX i_t1_pkey WITH VERBOSE;
>
> Also, both of them seems to be unintuitive..
>
>
> EXPLAIN.. it seems to be preferred to be as it is..
>
>
;From consistency perspective, I tend to agree with Robert to put
option at immediately after command name as follows.
REINDEX [(VERBOSE | FORCE)] {INDEX | ...} name;
Btw how long will the FORCE command available?
Regards,
---
Sawada Masahiko
--
Sent via pgsql-hackers mailing list (p
aving to reserve keywords.
>
As per discussion, it seems to good with
REINDEX { INDEX | TABLE | etc } name [ ( option [, option ...] ) ]
or
REINDEX { INDEX | TABLE | etc } [ (option [, optoin ...] ) ] name
i.g., the options of reindex(VERBOSE and FORCE) are put at before or
after object name.
Be
On Tue, Feb 3, 2015 at 12:32 AM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Mon, Feb 2, 2015 at 9:21 PM, Michael Paquier
>> wrote:
>>> Now, I think that it may
>>> be better to provide the keyword VERBOSE before the type of object
>>> reindexed as
On Mon, Feb 2, 2015 at 9:21 PM, Michael Paquier
wrote:
> On Mon, Feb 2, 2015 at 8:31 PM, Sawada Masahiko wrote:
>> Attached patch adds VERBOSE option to REINDEX commands.
>> Please give me feedbacks.
> This could provide useful feedback to users.
Thanks.
> Now, I think th
00s/0.00u sec elapsed 0.00 sec.
INFO: index "hoge2_idx" was reindexed.
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: indexes of whole table "s.hoge" were reindexed
REINDEX
Please give me feedbacks.
Regards,
---
Sawada Masahiko
000_reindex_verbose_v1.patch
De
On Sat, Jan 31, 2015 at 3:20 PM, Sawada Masahiko wrote:
> On Sat, Jan 31, 2015 at 2:00 PM, Sawada Masahiko
> wrote:
>> On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane wrote:
>>> David Johnston writes:
>>>> On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote
On Sat, Jan 31, 2015 at 2:00 PM, Sawada Masahiko wrote:
> On Sat, Jan 31, 2015 at 4:56 AM, Tom Lane wrote:
>> David Johnston writes:
>>> On Fri, Jan 30, 2015 at 12:05 PM, David Fetter wrote:
>>>> Why might the contents of pg_settings be different from what wou
1 - 100 of 243 matches
Mail list logo
