On 3 December 2015 at 14:54, konstantin knizhnik
wrote:
>
> I'd really like to collaborate using pglogical_output if at all possible.
> Petr's working really hard to get the pglogical downstrem out too, with me
> helping where I can.
>
> And where I can get pglogical_output plugin? Sorry, but I
I've recently noticed W-TinyLfu cache admission policy (see [1]) being
used for caffeine "high performance caching library for Java 8".
It demonstrates high cache hit ratios (see [2]) and enables to build
high-throughput caches (see caffeine in [3])
Authors explicitly allow implementations of the a
On Dec 3, 2015, at 4:18 AM, Craig Ringer wrote:
> Excellent.
>
> It should be possible to make that a separate extension. You can use C
> functions from other extensions by exposing a single pg_proc function with
> 'internal' return type that populates a struct of function pointers for the
>
Hi,
On 2015/12/03 15:27, Kyotaro HORIGUCHI wrote:
> At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote wrote
>> On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
>>>
>>> Apart from the representation of the relation, OID would be
>>> better as a field in beentry.
>>
>> I wonder if the field should be a
Hello, it's disappointing.
At Thu, 3 Dec 2015 15:48:50 +0900, Michael Paquier
wrote in
> On Thu, Dec 3, 2015 at 2:53 PM, Kyotaro HORIGUCHI
> wrote:
> > The attached patch adds a function to load output filter DLL.
> > The second file is an example filter module. The following
> > commandline w
Hi Ashutosh,
On 2015/12/02 20:45, Ashutosh Bapat wrote:
It's been a long time since last patch on this thread was posted. I have
started
to work on supporting join pushdown for postgres_fdw.
Thanks for the work!
Generating paths
A join between two foreign relations is con
On 3 December 2015 at 19:24, Haribabu Kommi
wrote:
> On Thu, Dec 3, 2015 at 4:18 PM, David Rowley
> wrote:
> >
> > Hi,
> >
> > I just wanted to cross post here to mark that I've posted an updated
> patch
> > for combining aggregate states:
> >
> http://www.postgresql.org/message-id/CAKJS1f9wfPKS
2015-12-03 7:04 GMT+01:00 Catalin Iacob :
> On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule
> wrote:
> > here is complete patch - regress tests for all supported Python branches
>
> I had a look at what changed in v10 since my last reviewed version and
> indeed most of it is straightforward: rename
On Dec 3, 2015, at 4:09 AM, Craig Ringer wrote:
> On 1 December 2015 at 00:20, Konstantin Knizhnik
> wrote:
>
> > We have implemented ACID multimaster based on logical replication and our
> > DTM (distributed transaction manager) plugin.
>
> What are you using for an output plugin and for re
On Thu, Dec 3, 2015 at 2:53 PM, Kyotaro HORIGUCHI
wrote:
> The attached patch adds a function to load output filter DLL.
> The second file is an example filter module. The following
> commandline with the file can create a test filter module. I
> suppose preload feature only needs additional few l
On Wed, Dec 2, 2015 at 8:59 PM, Robert Haas wrote:
>
>
> I think the approach this patch takes is pretty darned strange, and
> almost certainly not what we want. What you're doing here is putting
> every outstanding CLOG-update request into a linked list, and then the
> leader goes and does all o
On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote:
> I didn't push the changed for config_default you requested a few
> messages upthread; it's not clear to me how setting it to undef affects
> the whole thing. If setting it to undef makes the MSVC toolchain run
> the tap tests in the default c
On 2015/12/03 13:09, Tom Lane wrote:
> Amit Langote writes:
>> Currently find_inheritance_children() is smart enough to skip a child
>> table that it finds has been dropped concurrently after it gets a lock on
>> the same. It does so by looking up the child relid in syscache. It seems
>> it should
Hello,
At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote
wrote in <565fd0ba.5020...@lab.ntt.co.jp>
> On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
> > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
> > wrote
> >>
> >> Actually, do we really need to have the table name as a string at all
> >>
On Thu, Dec 3, 2015 at 4:18 PM, David Rowley
wrote:
>
> Hi,
>
> I just wanted to cross post here to mark that I've posted an updated patch
> for combining aggregate states:
> http://www.postgresql.org/message-id/CAKJS1f9wfPKSYt8CG=t271xbymzjrzwqbjeixiqrf-olh_u...@mail.gmail.com
>
> I also wanted t
On Thu, Dec 3, 2015 at 12:55 AM, cevian wrote:
> Hi all,
>
> I have a question about postgres_fdw optimizations/pushdown:
>
> I have the following code running on 9.5beta2 (same format as
> previous/related message for consistency)
> CREATE EXTENSION postgres_fdw;
> CREATE SERVER loop foreign dat
On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule wrote:
> here is complete patch - regress tests for all supported Python branches
I had a look at what changed in v10 since my last reviewed version and
indeed most of it is straightforward: renames from SPIError to Error.
The patch also changes plpy.
Hello, the attched is an example implement of output filter
dynamic loading feature of psql.
At Thu, 3 Dec 2015 10:41:11 +0900, Michael Paquier
wrote in
> > How about plugins on psql side? Calling hooked function in
> > printQuery could do that on psql. Impact on psql itself is
> > minimized. (
On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
> At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
> wrote
>>
>> Actually, do we really need to have the table name as a string at all
>> here? Why not just report the table OID? Surely whoever wants to check
>> the progress can connect to the data
On 20 October 2015 at 23:23, David Rowley
wrote:
> On 13 October 2015 at 20:57, Haribabu Kommi
> wrote:
>
>> On Tue, Oct 13, 2015 at 5:53 PM, David Rowley
>> wrote:
>> > On 13 October 2015 at 17:09, Haribabu Kommi
>> > wrote:
>> >>
>> >> On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas
>> >> wro
On 27 July 2015 at 04:58, Heikki Linnakangas wrote:
>
> This patch seems sane to me, as far as it goes. However, there's no
> planner or executor code to use the aggregate combining for anything. I'm
> not a big fan of dead code, I'd really like to see something to use this.
>
I've attached an u
2015-12-03 5:00 GMT+01:00 Haribabu Kommi :
> On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule
> wrote:
> >
> >
> > 2015-11-25 8:05 GMT+01:00 Haribabu Kommi :
> >>
> >>
> >> Thanks. Here I attached the poc patch that returns authentication method
> >> of the
> >> first matched hba entry in pg_hba.co
Hello,
At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
wrote in <20151202184820.GL2763@alvherre.pgsql>
> Vinayak wrote:
>
> > In the vacuum progress, column table_name is showing first 30 characters of
> > table name.
> > postgres=# create table test_vacuum_progress_in_postgresql(c1 int,c2 te
Hello, sorry for the cloberred CC list.
# I restored it manually from upthread..
At Wed, 2 Dec 2015 13:42:01 -0500, Robert Haas wrote in
> On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI
> wrote:
> > Yeah, it is actually restricted in that length. But if we allow
> > the buffer to store who
2015-12-02 23:00 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > Today I have problem with regress tests on my laptop.
>
> Looks like
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1286692
sure
Pavel
>
>
> regards, tom lane
>
On Thu, Dec 3, 2015 at 12:50 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
>>> BTW, not the fault of this patch in particular, but this example points
>>> up the complaint I've had right along about how opaque TAP test failures
>>> are. How di
Amit Langote writes:
> Currently find_inheritance_children() is smart enough to skip a child
> table that it finds has been dropped concurrently after it gets a lock on
> the same. It does so by looking up the child relid in syscache. It seems
> it should also check if the table is still in the li
On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule wrote:
>
>
> 2015-11-25 8:05 GMT+01:00 Haribabu Kommi :
>>
>>
>> Thanks. Here I attached the poc patch that returns authentication method
>> of the
>> first matched hba entry in pg_hba.conf with the given input values.
>> Currently these
>> functions
On Wed, Dec 02, 2015 at 10:36:56PM -0500, Josh Berkus wrote:
> On 12/02/2015 05:24 PM, Tom Lane wrote:
> > Don't think I agree. Suppose that you have a wider-than-screen table
> > and you use a pager to scroll left and right in that. If we shorten the
> > dashed lines, then once you scroll to the
Michael Paquier writes:
> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
>> BTW, not the fault of this patch in particular, but this example points
>> up the complaint I've had right along about how opaque TAP test failures
>> are. How did you dig down to see that error message?
> Well, it sh
On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
> BTW, not the fault of this patch in particular, but this example points
> up the complaint I've had right along about how opaque TAP test failures
> are. How did you dig down to see that error message?
Well, it showed up on my terminal...
> Is
On 12/02/2015 05:24 PM, Tom Lane wrote:
> Don't think I agree. Suppose that you have a wider-than-screen table
> and you use a pager to scroll left and right in that. If we shorten the
> dashed lines, then once you scroll to the right of wherever they stop,
> you lose that visual cue separating t
On 3 December 2015 at 09:32, Peter Eisentraut wrote:
> On 12/2/15 7:00 PM, Craig Ringer wrote:
> > I notice that you don't set the 'waiting' flag. 'waiting' is presently
> > documented as:
> >
> >True if this backend is currently waiting on a lock
> >
> > ... but I'm inclined to just wid
Michael Paquier writes:
> On Thu, Dec 3, 2015 at 8:38 AM, Tom Lane wrote:
>> Test Summary Report
>> ---
>> t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0)
>> Non-zero exit status: 25
>> Parse errors: Bad plan. You planned 14 tests but ran 8.
>> Files=1, Tests=8, 0 wallclock secs
On Wed, Dec 2, 2015 at 9:30 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
>> You're right, it's not necessary.
>> Attached latest v29 patch which removes the mention in pg_upgrade
>> documentation.
>
> The changes looks to be correct but I haven't tested.
> And I have some additional random comments.
>
On 3 December 2015 at 14:28, Peter Eisentraut wrote:
> On 11/30/15 11:00 PM, David Rowley wrote:
> > It seems that there's no shortage of relational databases in existence
> > today which don't support this. These databases would require the GROUP
> > BY clause to include the p.description column
On Mon, Nov 30, 2015 at 04:29:43PM +0900, KAWAMICHI Ryoji wrote:
>
>
> Robert Haas wrote:
> >
> > - If we're sequential scanning a small table, let's say less than 1/4
> > of shared_buffers, which is the point where synchronized scans kick
> > in, then assume the data is coming from shared_buff
On Thu, Dec 3, 2015 at 10:09 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier
> wrote in
>
>> On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote:
>> > On 11/15/15 7:37 PM, Peter Eisentraut wrote:
>> > I was more thinking it would be nice to be able to
On 12/2/15 7:00 PM, Craig Ringer wrote:
> I notice that you don't set the 'waiting' flag. 'waiting' is presently
> documented as:
>
>True if this backend is currently waiting on a lock
>
> ... but I'm inclined to just widen its definition and set it here, since
> we most certainly are wa
On 11/30/15 11:00 PM, David Rowley wrote:
> It seems that there's no shortage of relational databases in existence
> today which don't support this. These databases would require the GROUP
> BY clause to include the p.description column too.
Well, actually, we implemented this because other datab
On 3 December 2015 at 01:30, Robert Haas wrote:
> 1. Do the transaction.
> 2. PREPARE.
> 3. Replay the transaction.
>
As Konstantin noted they aren't using Pg's 2PC. They actually couldn't if
they wanted to because logical decoding does not support decoding an xact
at PREPARE TRANSACTION time,
On 3 December 2015 at 04:18, Konstantin Knizhnik
wrote:
> The problem is that transactions are delivered to replica through single
> channel: logical replication slot.
> And while such transaction is waiting acknowledgement from arbiter, it is
> blocking replication channel preventing other (par
Hello,
At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier
wrote in
> On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote:
> > On 11/15/15 7:37 PM, Peter Eisentraut wrote:
> > I was more thinking it would be nice to be able to temporarily
> > over-ride/wrap what an output function is doing. AFAIK t
On 1 December 2015 at 00:20, Konstantin Knizhnik
wrote:
> We have implemented ACID multimaster based on logical replication and our
DTM (distributed transaction manager) plugin.
What are you using for an output plugin and for replay?
I'd really like to collaborate using pglogical_output if at a
On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova
wrote:
> If we don't need c4 as an index scankey, we don't need any btree opclass on
> it.
> But we still want to have it in covering index for queries like
>
> SELECT c4 FROM tbl WHERE c1=1000; // uses the IndexOnlyScan
> SELECT * FROM tbl WHE
On 3 December 2015 at 04:22, Julian Schauder
wrote:
>
> I suggest adding a new state to pg_stat_activity.state for backends that
> are
> waiting for their synchronous commit to be flushed on the remote host.
> I chose 'waiting for synchronous replication' for now.
>
>
I've added this to the next
On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote:
> On 11/15/15 7:37 PM, Peter Eisentraut wrote:
>>
>> On 11/15/15 3:20 PM, Jim Nasby wrote:
>>>
>>> As to the argument about displaying a check or an X, why should that
>>> capability only exist for boolean types? For example, why not allow psql
>>>
On Thu, Dec 3, 2015 at 5:48 AM, Kevin Grittner wrote:
>> There has been a review but no replies for more than 1 month. Returned
>> with feedback?
>
> I do intend to post another version of the patch to tweak the
> calculations again, after I can get a patch in to expand the
> testing capabilities t
On 3 December 2015 at 04:22, Julian Schauder
wrote:
> I suggest adding a new state to pg_stat_activity.state for backends that
> are
>
waiting for their synchronous commit to be flushed on the remote host.
>
>
Excellent idea. Anything that improves management and visibility into what
the system
On 02/12/2015 20:25, cevian wrote:
> Hi all,
>
Hello,
> I have a question about postgres_fdw optimizations/pushdown:
>
> I have the following code running on 9.5beta2 (same format as
> previous/related message for consistency)
> CREATE EXTENSION postgres_fdw;
> CREATE SERVER loop foreign data
On Mon, Nov 30, 2015 at 11:00 PM, David Rowley
wrote:
> There are in fact also two queries in TPC-H (Q10 and Q18) which are written
> to include all of the non-aggregated column in the GROUP BY list. During a
> recent test I witnessed a 50% gain in performance in Q10 by removing the
> unneeded col
Jeff Janes writes:
> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote:
>> If you're fixing the dashed-line code, is there a way to say that we
>> never have more than a reasonable number of dashes (ideally, the width
>> of the terminal) no matter how wide the data is? Having 4000 dashes
>> bec
On 9/15/15 11:49 PM, Pavel Stehule wrote:
1. processing user input with little bit more comfort - the user doesn't
need to separate schema and table
This is especially useful if you're doing anything that needs to
dynamically work with different objects. I'd say about 80% of the time
I'm doin
Pavel Stehule writes:
> Today I have problem with regress tests on my laptop.
Looks like
https://bugzilla.redhat.com/show_bug.cgi?id=1286692
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Michael Paquier wrote:
> Well, Alvaro has whispered me a more elegant method by using TestLib()
> to only import a portion of the routines and avoid the redefinition
> errors. Hence, patch 0001 attached creates equivalents of command_*
> for PostgresNode and tests use it without setting PGPORT. Pa
On Tue, Dec 1, 2015 at 7:21 AM, Amit Kapila wrote:
> Above and changes in add_path() makes planner not to select parallel path
> for seq scan where earlier it was possible. I think you want to change the
> costing of parallel plans based on rows selected instead of total_cost,
> but there seems to
Sorry, I initially responded only to Josh. Forwarding to list:
On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote:
> On 12/01/2015 11:20 AM, Tom Lane wrote:
>> Notice that the dashed lines go all the way to the right margin of my
>> 80-column terminal window, even though the data requires no m
On Wed, Dec 2, 2015 at 12:39 AM, Michael Paquier
wrote:
> On Mon, Nov 9, 2015 at 8:07 AM, Steve Singer wrote:
>> In snapmgr.c
>>
>>
>> + * XXX: If we can trust a read of an int64 value to be atomic, we can skip
>> the
>> + * spinlock here.
>> + */
>> +int64
>> +GetOldSnapshotThresholdTimestamp(
Hello Hackers,
I recently analyzed an incident where a major lag in synchronous replication
blocked a number of synchronous backends. I found myself looking at backends
that, according to pg_stat_activity, were neither waiting nor idle but yet they
didn't finish their work.
As it turns out, the
On 12/01/2015 11:20 AM, Tom Lane wrote:
> Notice that the dashed lines go all the way to the right margin of my
> 80-column terminal window, even though the data requires no more than
> 22 columns. While this doesn't look so awful as-is, when I'm working
> in a very wide window it starts to look a
Hi
2015-11-17 1:49 GMT+01:00 Marko Tiikkaja :
> On 9/11/15 12:25 PM, Pavel Stehule wrote:
>
>> new update of parse_ident function patch
>>
>
> Nice! I've certainly wanted something like this a number of times.
>
> Some comments about the v2 of the patch:
>
>- The patch doesn't apply anymore,
Thank you for reply.
On 12/02/2015 08:30 PM, Robert Haas wrote:
Logical decoding only begins decoding a transaction once the
transaction is complete. So I would guess that the sequence of
operations here is something like this - correct me if I'm wrong:
1. Do the transaction.
2. PREPARE.
3. R
On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
wrote:
> On Tuesday 01 December 2015 08:38:21 you wrote:
>> it (zero
>> based indexing support) doesn't meet the standard of necessity for
>> adding to the core API and as stated it's much to magical.
>
> We do not touch the arrays, we simply create
Noah Misch wrote:
> On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote:
> > Finally, I ran perltidy on all the files, which strangely changed stuff
> > that I didn't expect it to change. I wonder if this is related to the
> > perltidy version.
>
> The last pgindent run (commit 807b9e0
2015-12-02 20:08 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > Hi
> >
> > Today I have problem with regress tests on my laptop.
>
> Maybe this is because of the libxml version?
100%, same issue is with 9.4.5
After downgrade to 2.9.2 (from 2.9.3) this issue was out
So it is looking like
On Wed, Dec 2, 2015 at 10:03 AM, Robert Haas wrote:
>> I'm not very concerned about a regression that is only seen when
>> work_mem is set below the (very conservative) postgresql.conf default
>> value of 4MB when sorting 100 million integers.
>
> Perhaps surprisingly, I tend to agree. I'm cautio
Hi all,
I have a question about postgres_fdw optimizations/pushdown:
I have the following code running on 9.5beta2 (same format as
previous/related message for consistency)
CREATE EXTENSION postgres_fdw;
CREATE SERVER loop foreign data wrapper postgres_fdw
OPTIONS (port '5432', dbname 'testdb
Pavel Stehule wrote:
> Hi
>
> Today I have problem with regress tests on my laptop.
Maybe this is because of the libxml version?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailin
Hi
Today I have problem with regress tests on my laptop.
I did fresh clone of git
Is it working elsewhere?
Regards
Pavel
regression.diffs
Description: Binary data
regression.out
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Vinayak wrote:
> In the vacuum progress, column table_name is showing first 30 characters of
> table name.
> postgres=# create table test_vacuum_progress_in_postgresql(c1 int,c2 text);
> postgres=# select * from pg_stat_vacuum_progress ;
> -[ RECORD 1 ]---+--
> pid
On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI
wrote:
> Yeah, it is actually restricted in that length. But if we allow
> the buffer to store whole the qualified names, it will need 64 *
> 2 + 1 +1 = 130 bytes * 10 1300 bytes for each beentry... It might
> be acceptable by others, but I don't t
On Mon, Nov 30, 2015 at 9:10 PM, Vinayak wrote:
> Thanks for the v7.
> Please check the comment below.
> -Table name in the vacuum progress
>
> + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s",
> schemaname,relname);
Uh, I hope that line doesn't appear in the patch. We're scarcel
On Wed, Dec 2, 2015 at 1:24 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote:
>>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
This seems surprising to me: any other program in the world would do
exit(1) after discovering that
"David G. Johnston" writes:
> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote:
>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
>>> This seems surprising to me: any other program in the world would do
>>> exit(1) after discovering that it couldn't write where it had been
>>> told to. Shou
On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote:
> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
> > I just noticed that parse_psql_options() ignores the result of
> setQFout(),
> > meaning that if the argument of a -o command line option is bogus, we'll
> > ignore the switch entirely afte
On 11/15/15 7:37 PM, Peter Eisentraut wrote:
On 11/15/15 3:20 PM, Jim Nasby wrote:
As to the argument about displaying a check or an X, why should that
capability only exist for boolean types? For example, why not allow psql
to convert a numeric value into a bar of varying sizes? I've frequently
On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
> I just noticed that parse_psql_options() ignores the result of setQFout(),
> meaning that if the argument of a -o command line option is bogus, we'll
> ignore the switch entirely after printing an error report. For example
>
> $ psql -o /dev/foo
On Sat, Nov 28, 2015 at 7:05 PM, Peter Geoghegan wrote:
> On Sat, Nov 28, 2015 at 2:04 PM, Jeff Janes wrote:
>> For me very large sorts (100,000,000 ints) with work_mem below 4MB do
>> better with unpatched than with your patch series, by about 5%. Not a
>> big deal, but also if it is easy to ke
On Mon, Nov 30, 2015 at 11:20 AM, Konstantin Knizhnik
wrote:
> We have implemented ACID multimaster based on logical replication and our
> DTM (distributed transaction manager) plugin.
> Good news is that it works and no inconsistency is detected.
> But unfortunately it is very very slow...
>
> At
Robert Haas writes:
> On Fri, Nov 27, 2015 at 8:54 PM, Tatsuo Ishii wrote:
>> In short, there are number of reasons we cannot simply import the
>> consortium's mapping regarding SJIS (and EUC_JP).
> I haven't seen a response to this point, but it seems important.
I'll defer to Tatsuo-san concer
On Sun, Nov 29, 2015 at 4:02 PM, Peter Geoghegan wrote:
> The C collation is treated exactly the same as other collations when
> considering whether the generation of abbreviated keys for text should
> continue. This doesn't make much sense. With text, the big cost that
> we are concerned about go
On Fri, Nov 27, 2015 at 8:54 PM, Tatsuo Ishii wrote:
> I explain why the manual editing is necessary.
>
> One of the most famous problems with Unicode is "wave dash"
> (U+301C). According the Unicode consortium's Unicode/SJIS map, it
> corresponds to 0x8160 of Shift_JIS. Unfortunately this was a m
I wrote:
> I just noticed that parse_psql_options() ignores the result of setQFout(),
> meaning that if the argument of a -o command line option is bogus, we'll
> ignore the switch entirely after printing an error report.
There's more silliness in the same area. \o with an invalid target spec
is
On 12/02/2015 08:39 AM, Andres Freund wrote:
On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote:
A feature does not exist without documentation.
Uh, you do realize there's actually documentation about RLS? The issues
mentioned here are some small adjustments, not entirely new docs.
No I did
On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote:
> A feature does not exist without documentation.
Uh, you do realize there's actually documentation about RLS? The issues
mentioned here are some small adjustments, not entirely new docs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 12/02/2015 05:27 AM, Robert Haas wrote:
On Mon, Nov 30, 2015 at 4:55 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Well, it's December nearly, and we don't seem to be making much progress
towards pushing out 9.5.0. I see the following items on
https://wiki.postgresql.org/
I just noticed that parse_psql_options() ignores the result of setQFout(),
meaning that if the argument of a -o command line option is bogus, we'll
ignore the switch entirely after printing an error report. For example
$ psql -o /dev/foo -c 'select 1'
/dev/foo: Permission denied
?column?
--
On 2015-12-02 09:57:19 -0500, Noah Misch wrote:
> On Tue, Dec 01, 2015 at 05:07:15PM -0500, Robert Haas wrote:
> > I think it's weird to back a commit out only to put a bunch of very similar
> > stuff back in.
>
> I agree with that. If the original patches and their replacements shared 95%
> of di
On Fri, Nov 27, 2015 at 2:32 AM, Amit Kapila wrote:
> Okay, as discussed I have handled the case of sub-transactions without
> additional shmem in the attached patch. Apart from that, I have tried
> to apply this optimization for Prepared transactions as well, but as
> the dummy proc used for suc
On Tue, Dec 01, 2015 at 05:07:15PM -0500, Robert Haas wrote:
> I think it's weird to back a commit out only to put a bunch of very similar
> stuff back in.
I agree with that. If the original patches and their replacements shared 95%
of diff lines in common, we wouldn't be having this conversation
On Wed, Dec 2, 2015 at 7:45 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> Thank you for picking this up.
>
> At Tue, 1 Dec 2015 20:33:02 +0530, Amit Kapila
wrote in
> > On Mon, Nov 30, 2015 at 6:17 PM, Kyotaro HORIGUCHI <
> > horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > > ===
On Fri, Nov 27, 2015 at 9:28 PM, Peter Geoghegan wrote:
> It looks like commit 3bd909b22 did not place GatherPath within
> print_path(), preventing complete information for Gather paths from
> appearing when OPTIMIZER_DEBUG is in use.
Thanks, committed. Sorry I missed that.
--
Robert Haas
Ente
On Mon, Nov 30, 2015 at 4:55 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Well, it's December nearly, and we don't seem to be making much progress
>> towards pushing out 9.5.0. I see the following items on
>> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>>
>>
On Wed, Dec 2, 2015 at 1:06 PM, Bruce Momjian wrote:
> On Wed, Dec 2, 2015 at 08:53:07AM +, Dave Page wrote:
>> On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian wrote:
>> > On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
>> >> Bruce Momjian wrote:
>> >>
>> >> > Do we still have
On Wed, Dec 2, 2015 at 08:53:07AM +, Dave Page wrote:
> On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian wrote:
> > On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>
> >> > Do we still have licensing issues if we ship Postgres and OpenSSL
> >> > toget
On Wed, Dec 2, 2015 at 5:45 PM, Amit Kapila wrote:
> I am fine with it. I think the further optimizations can be done
> separately.
Done.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
Thanks Ashutosh.
Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
looks good to me.
On Fri, Nov 27, 2015 at 3:02 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Thanks Rushabh for your review and comments.
>
> On Thu, Nov 26, 2015 at 5:39 PM, Rushabh Lathia
> wrote
On Wed, Dec 2, 2015 at 12:36 PM, Andres Freund wrote:
>
> On 2015-12-02 12:25:37 +0100, Joel Jacobson wrote:
> > On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> > > The significant changes are in 9.5.
> >
> > Will multixact truncations be WAL logged in 9.5?
>
> Yes.
>
> C.f. the release n
On 2015-12-02 12:25:37 +0100, Joel Jacobson wrote:
> On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> > The significant changes are in 9.5.
>
> Will multixact truncations be WAL logged in 9.5?
Yes.
C.f. the release notes:
* Rework truncation of the multixact commit log to be properly WAL
On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> The significant changes are in 9.5.
Will multixact truncations be WAL logged in 9.5?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
1 - 100 of 113 matches
Mail list logo
