On Fri, Nov 20, 2015 at 7:03 AM, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown wrote:
>> This bug still exists.
>
> Hmm. This probably should have been on the open items list.
I have added an open item for 9.5. That's not a cool bug to release
the next GA even if that's not l
On Fri, Nov 20, 2015 at 1:25 AM, Robert Haas wrote:
>
> On Thu, Nov 19, 2015 at 2:59 AM, Amit Kapila
wrote:
> > Won't it be useful to consider parameterized paths for below kind of
> > plans where we can push the jointree to worker and each worker can
> > scan the complete outer relation A and th
> On Thu, Nov 19, 2015 at 6:39 AM, Kouhei Kaigai wrote:
> > So, are you suggesting to make a patch that allows ForeignScan to have
> > multiple sub-plans right now? Or, one sub-plan?
>
> Two:
>
> http://www.postgresql.org/message-id/CA+TgmoYZeje+ot1kX4wdoB7R7DPS0CWXAzfqZ-
> 14ykfkgkr...@mail.gma
On Thu, Nov 19, 2015 at 9:29 PM, Robert Haas wrote:
>
> On Wed, Nov 18, 2015 at 10:41 PM, Amit Kapila
wrote:
> > I think whats going on here is that when any of the session doesn't
> > get any workers, we shutdown the Gather node which internally destroys
> > the dynamic shared memory segment as
On Fri, Nov 20, 2015 at 1:33 AM, Peter Eisentraut wrote:
> There is no documentation what use case the new (in 9.5) parameter
> wal_retrieve_retry_interval is for. The commit message
> (5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but
> even that is not clear, and obviously in
Attached patch fixes minor issue with an ON CONFLICT DO UPDATE comment.
--
Peter Geoghegan
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index dabaea9..119061e 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyT
> On Mon, Nov 16, 2015 at 9:03 PM, Kouhei Kaigai wrote:
> > I guess we will put a pointer to static ExtensibleNodeMethods structure
> > on ForeignScan, CustomScan, CustomScanState and etc...
>
> I think that makes it confusing. What I'd prefer to do is have only
> the name stored in the node, an
On 2015/11/20 6:57, Robert Haas wrote:
On Wed, Nov 18, 2015 at 10:54 PM, Etsuro Fujita
wrote:
Noted, but let's do it that way and move on. It would be a shame if
we didn't end up with a working FDW join pushdown system in 9.6
because of a disagreement on this point.
Another idea would be to
On 2015-11-20 10:25:20 +0900, Amit Langote wrote:
> On 2015/11/20 10:24, Robert Haas wrote:
> > On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote
> > wrote:
> >> Attached fixes $SUBJECT:
> >>
> >> s/replication_origin.c/origin.c/g
> >
> > Committed.
Thanks Robert and Amit!
I do wonder however if w
On Thu, Nov 19, 2015 at 5:32 PM, Greg Stark wrote:
> Hm. Have you tested a nearly-sorted input set around 1.5x the size of
> work_mem? That should produce a single run using the heap to generate
> runs but generate two runs if, AIUI, you're just filling work_mem,
> running quicksort, dumping that
On Fri, Nov 20, 2015 at 12:54 AM, Peter Geoghegan wrote:
> * One run can be created with replacement selection, where a
> hyrbid-sort merge strategy needs to create and then merge many runs.
> When I started work on this patch, I was pretty sure that case would
> be noticeably regressed. I was wro
On 2015/11/20 0:57, Jim Nasby wrote:
> On 11/19/15 1:18 AM, Amit Langote wrote:
>> 1) General purpose interface for (maintenance?) commands to report a set
>
> I'm surprised no one has picked up on using this for DML. Certainly anyone
> works with ETL processes would love to be able to get some cl
On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote
wrote:
> Attached fixes $SUBJECT:
>
> s/replication_origin.c/origin.c/g
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 2015/11/20 10:24, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote
> wrote:
>> Attached fixes $SUBJECT:
>>
>> s/replication_origin.c/origin.c/g
>
> Committed.
Thanks!
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On Thu, Nov 19, 2015 at 2:53 PM, Peter Geoghegan wrote:
> The latter 16MB work_mem example query/table is still faster with a
> 12MB work_mem than master, even with multiple passes. Quite a bit
> faster, in fact: about 37 seconds on master, to about 24.7 seconds
> with the patches (same for higher
Folks,
The docs for ALTER DEFAULT PRIVILEGES state:
You can change default privileges only for objects that will be
created by yourself or by roles that you are a member of.
but I have not been able to reproduce the "or by roles that you are a
member of" part. The attached script should
Dean Rasheed writes:
> On 18 November 2015 at 22:19, Tom Lane wrote:
>> Still, this proves that we are onto a real problem.
> Agreed. I had a go at turning that example into something using
> log(base, num) so that the result would be visible in a pure SQL test,
> but I didn't have any luck.
I
On Thu, Nov 19, 2015 at 2:35 PM, Robert Haas wrote:
> OK, so reversing this analysis, with the default work_mem of 4MB, we'd
> need a multi-pass merge for more than 235MB/4 = 58MB of data. That is
> very, very far from being a can't-happen scenario, and I would not at
> all think it would be acce
On Thu, Nov 19, 2015 at 12:35 PM, Greg Stark wrote:
> So I think you're kind of right and kind of wrong. The vast majority
> of use cases are either sub 1TB or are in work environments designed
> specifically for data warehouse queries where a user can obtain much
> more memory for their queries.
On Thu, Nov 19, 2015 at 3:43 PM, Peter Geoghegan wrote:
>> I'd be interested in seeing this analysis in some detail.
>
> Sure. Jeff mentioned 8MB as a work_mem setting, so let's examine a
> case where that's the work_mem setting, and see experimentally where
> the crossover point for a multi-pass
On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown wrote:
> On 27 March 2015 at 04:54, Kyotaro HORIGUCHI
> wrote:
>> Hello,
>>
>> At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund
>> wrote in <20150326175024.gj...@alap3.anarazel.de>
>>> I think the problem here is that the *primary* makes no such
>>>
On Wed, Nov 18, 2015 at 10:54 PM, Etsuro Fujita
wrote:
>> Noted, but let's do it that way and move on. It would be a shame if
>> we didn't end up with a working FDW join pushdown system in 9.6
>> because of a disagreement on this point.
>
> Another idea would be to consider join pushdown as unsup
On Thu, Nov 19, 2015 at 6:39 AM, Kouhei Kaigai wrote:
> So, are you suggesting to make a patch that allows ForeignScan to have
> multiple sub-plans right now? Or, one sub-plan?
Two:
http://www.postgresql.org/message-id/ca+tgmoyzeje+ot1kx4wdob7r7dps0cwxazfqz-14ykfkgkr...@mail.gmail.com
--
Rober
On Thu, Nov 19, 2015 at 4:26 PM, Andres Freund wrote:
> On 2015-11-19 14:58:05 -0500, Robert Haas wrote:
>> On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote:
>> > It's really not particularly convenient to allocate tranches right
>> > now. You have to store at least the identifier in shared
On 2015-11-19 14:58:05 -0500, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote:
> > It's really not particularly convenient to allocate tranches right
> > now. You have to store at least the identifier in shared memory and
> > then redo the registration in each process. O
On 18 November 2015 at 22:19, Tom Lane wrote:
> A bit of progress on this: I've found a test case, namely
>
> select sqrt(99...
>
Wow.
> Still, this proves that we are onto a real problem.
>
Agreed. I had a go at turning that example into something using
log(base, num) so that the result wo
On Thu, Nov 19, 2015 at 8:35 PM, Greg Stark wrote:
> Hm. So a bit of back-of-envelope calculation. If we have want to
> buffer at least 1MB for each run -- I think we currently do more
> actually -- and say that a 1GB work_mem ought to be enough to run
> reasonably (that's per sort after all and t
On Wed, Nov 18, 2015 at 6:19 PM, Robert Haas wrote:
> On Wed, Nov 18, 2015 at 6:29 PM, Peter Geoghegan wrote:
>> In principle, I have no problem with doing that. Through testing, I
>> cannot see any actual upside, though. Perhaps I just missed something.
>> Even 8MB is enough to avoid the multipa
On Thu, Nov 19, 2015 at 6:56 PM, Peter Geoghegan wrote:
> Yes, I really do mean it when I say that the DBA is not supposed to
> see this message, no matter how much or how little memory or data is
> involved. There is no nuance intended here; it isn't sensible to allow
> a multi-pass sort, just as
On 19 November 2015 at 01:22, Greg Stark wrote:
> Perhaps the right thing to do is report a statistic to pg_stats so
> DBAs can see how often sorts are in memory, how often they're on disk,
> and how often the on disk sort requires n passes. That would put them
> in the same category as "sequent
On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote:
> On November 19, 2015 8:09:38 AM PST, Robert Haas
> wrote:
>>On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
>> wrote:
>>> The moving base tranches to shared memory has been discussed many
>>times.
>>> The point is using them later in p
On Thu, Nov 19, 2015 at 2:59 AM, Amit Kapila wrote:
> On Thu, Nov 19, 2015 at 12:27 AM, Robert Haas wrote:
>>
>> On Wed, Nov 18, 2015 at 7:25 AM, Amit Kapila
>> wrote:
>> > Don't we need the startup cost incase we need to build partial paths for
>> > joinpaths like mergepath?
>> > Also, I think
On 9/15/15 11:04 PM, Fujii Masao wrote:
> If --slot option is specified, pg_receivexlog reports a flush position to
> the server even though --synchronous is not specified. So users might think
> that --synchrnous option is not necessary for synchronous pg_receivexlog
> setting. But that's not true
On 11/19/15 11:05 AM, Robert Haas wrote:
> On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera
> wrote:
>> In my days of Perl, it was starting to become frowned upon to call
>> subroutines without parenthesizing arguments. Is that no longer the
>> case? Because I notice there are many places in thi
On Wed, Nov 18, 2015 at 5:22 PM, Greg Stark wrote:
> On Wed, Nov 18, 2015 at 11:29 PM, Peter Geoghegan wrote:
>> Other systems expose this explicitly, and, as I said, say in an
>> unqualified way that a multi-pass merge should be avoided. Maybe the
>> warning isn't the right way of communicating
Alvaro Herrera writes:
> Marko Tiikkaja wrote:
>> On the test server I'm running on, it doesn't look quite as bad as the
>> profiles we had in production, but s_lock is still the worst offender in the
>> profiles, called from:
>>
>> - 80.33% LWLockAcquire
>> + 48.34% asyncQueueReadAllNotification
On Thu, Nov 19, 2015 at 9:22 PM, Marko Tiikkaja wrote:
> Of course, something might break if we added a new statement type which
> supported RETURNING, but I'm really not worried about that. I'm not dead
> set against adding some Assert(IsA()) calls here, but I don't see the point.
gram.y has a
Thom Brown writes:
> On 19 November 2015 at 16:11, Robert Haas wrote:
>> The only explanation I can think of here is that pgbench on startup
>> queries one of the tables to figure out the scale factor, and it seems
>> to be coming up with scaling factor 0, suggesting that the table was
>> perhaps
On 19 November 2015 at 14:47, Jaime Casanova
wrote:
> On 19 November 2015 at 14:18, Alvaro Herrera wrote:
>> Alvaro Herrera wrote:
>>> Jeff Janes wrote:
>>> > I've written a function which allows users to clean up the pending list.
>>> > It takes the index name and returns the number of pending l
On 19 November 2015 at 14:18, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Jeff Janes wrote:
>> > I've written a function which allows users to clean up the pending list.
>> > It takes the index name and returns the number of pending list pages
>> > deleted.
>>
>> I just noticed that your patc
On 11/19/15 5:32 PM, Tom Lane wrote:
Marko Tiikkaja writes:
On 11/19/15 4:21 PM, Tom Lane wrote:
... and then you gotta get the notifications to the clients, so it seems
like this just leaves the performance question hanging.
I'm not sure which performance question you think is left hanging
On 19 November 2015 at 16:11, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown wrote:
>> I'm using git master, and if I crash the database whilst it's running
>> pgbench, then restart the database and try to run pgbench again, I
>> can't:
>>
>> thom@swift:~/Development/postgresql$
On Thu, Nov 19, 2015 at 10:05 AM, Robert Haas wrote:
> On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera
> wrote:
> > In my days of Perl, it was starting to become frowned upon to call
> > subroutines without parenthesizing arguments. Is that no longer the
> > case?
>
As I understand it, there
On 12 August 2015 at 20:19, Jeff Janes wrote:
>
> But where does this belong? Core? Its own separate extension?
>
I will say core. Gin indexes are in core and i don't see why this
function shouldn't.
FWIW, brin indexes has a similar function brin_summarize_new_values() in core
--
Jaime Casano
On November 19, 2015 8:09:38 AM PST, Robert Haas wrote:
>On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
> wrote:
>> The moving base tranches to shared memory has been discussed many
>times.
>> The point is using them later in pg_stat_activity and other
>monitoring
>> views.
>
>I'm not in agre
Marko Tiikkaja wrote:
> On the test server I'm running on, it doesn't look quite as bad as the
> profiles we had in production, but s_lock is still the worst offender in the
> profiles, called from:
>
> - 80.33% LWLockAcquire
> + 48.34% asyncQueueReadAllNotifications
> + 23.09% SIGetDat
There is no documentation what use case the new (in 9.5) parameter
wal_retrieve_retry_interval is for. The commit message
(5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but
even that is not clear, and obviously in the wrong place. Could we come
up with something more to put into
Marko Tiikkaja writes:
> On 11/19/15 4:21 PM, Tom Lane wrote:
>> ... and then you gotta get the notifications to the clients, so it seems
>> like this just leaves the performance question hanging.
> I'm not sure which performance question you think is left hanging. If
> every client is connecte
В письме от 19 ноября 2015 10:57:27 пользователь Tom Lane написал:
> Nikolay Shaplov writes:
> > But this is not the issue. We can change it any way we like. The question
> > do we need such example at all, or no?
>
> I'm kind of -1 on the idea of a module that doesn't actually do something
> *us
Jim Nasby writes:
> On 11/19/15 9:57 AM, Tom Lane wrote:
>> Agreed. We aren't going to accept any core tests that depend on DBI/DBD.
>> Now, that might be a fine example for tests written to test something that
>> uses Postgres ... but not as an example of how to write a core test.
> Isn't one o
Alvaro Herrera wrote:
> Jeff Janes wrote:
> > I've written a function which allows users to clean up the pending list.
> > It takes the index name and returns the number of pending list pages
> > deleted.
>
> I just noticed that your patch uses AccessShareLock on the index. Is
> that okay? I wou
On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown wrote:
> I'm using git master, and if I crash the database whilst it's running
> pgbench, then restart the database and try to run pgbench again, I
> can't:
>
> thom@swift:~/Development/postgresql$ pgbench -c 1 -j 1 -T 20 -S pgbench
> ...crash database..
On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
wrote:
> The moving base tranches to shared memory has been discussed many times.
> The point is using them later in pg_stat_activity and other monitoring
> views.
I'm not in agreement with this idea. Actually, I'd prefer that the
tranches live
On 11/19/15 4:21 PM, Tom Lane wrote:
Marko Tiikkaja writes:
I've in the past wanted to listen on all notification channels in the
current database for debugging purposes. But recently I came across
another use case. Since having multiple postgres backends listening for
notifications is very i
On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera
wrote:
> In my days of Perl, it was starting to become frowned upon to call
> subroutines without parenthesizing arguments. Is that no longer the
> case? Because I notice there are many places in this patch and pre-
> existing that call psql with
On Wed, Nov 18, 2015 at 5:18 AM, Konstantin Knizhnik
wrote:
> Hello,
>
> SPI was originally developed for execution SQL statements from C user
> defined functions in context of existed transaction.
> This is why it is not possible to execute any transaction manipulation
> statement (BEGIN, COMMIT,
On 11/19/15 9:57 AM, Tom Lane wrote:
>I wrote this example based on ssl TAP test. There was no DBI there. And I
>think it was done for purpose. If we add DBI to tests, then we should add it
>to build dependencies. And it is not a good idea, and so not a good example.
Agreed. We aren't going to
On Wed, Nov 18, 2015 at 10:41 PM, Amit Kapila wrote:
> I think whats going on here is that when any of the session doesn't
> get any workers, we shutdown the Gather node which internally destroys
> the dynamic shared memory segment as well. However the same is
> needed as per current design for d
On 11/19/15 1:18 AM, Amit Langote wrote:
1) General purpose interface for (maintenance?) commands to report a set
I'm surprised no one has picked up on using this for DML. Certainly
anyone works with ETL processes would love to be able to get some clue
on the status of a long running query...
Inspecting the multicorn source was helpful.
For the purposes of anyone searching the mailing lists, I needed to access
the quals natively. The code that helped me figure out how to do this was
in the native odbc fdw here:
https://github.com/ZhengYang/odbc_fdw/blob/master/odbc_fdw.c
particularly
Nikolay Shaplov writes:
> But this is not the issue. We can change it any way we like. The question do
> we need such example at all, or no?
I'm kind of -1 on the idea of a module that doesn't actually do something
*useful*. Let's write some actual tests instead, and make them readable
enough t
Jeff Janes wrote:
> I've written a function which allows users to clean up the pending list.
> It takes the index name and returns the number of pending list pages
> deleted.
I just noticed that your patch uses AccessShareLock on the index. Is
that okay? I would have assumed that you'd need Shar
On Wed, Nov 18, 2015 at 12:32 AM, Haribabu Kommi
wrote:
> On Wed, Nov 18, 2015 at 6:02 AM, Robert Haas wrote:
>> On Mon, Nov 16, 2015 at 4:27 AM, Marti Raudsepp wrote:
>>> Thank you so much for the review and patch update. I should have done that
>>> myself, but I've been really busy for the las
В письме от 19 ноября 2015 09:39:41 пользователь Jim Nasby написал:
> On 11/19/15 8:42 AM, Nikolay Shaplov wrote:
> > +sub psql_ok
> > +{
> > + my $db = shift;
> > + my $sql = shift;
> > + my $comment = shift;
>
> Isn't the preferred method of parameter assignment to use @_?
Hm... it is the
On 11/19/15 8:42 AM, Nikolay Shaplov wrote:
+sub psql_ok
+{
+ my $db = shift;
+ my $sql = shift;
+ my $comment = shift;
Isn't the preferred method of parameter assignment to use @_?
Also, I'd think one of the examples should use DBI, since presumably one
of the big benefits
Marko Tiikkaja writes:
> I've in the past wanted to listen on all notification channels in the
> current database for debugging purposes. But recently I came across
> another use case. Since having multiple postgres backends listening for
> notifications is very inefficient (one Thursday I fo
Alvaro Herrera writes:
> Erik Rijkers wrote:
>> make contrib:
>> In file included from hstore_plperl.c:6:0:
>> ../../contrib/hstore/hstore.h:79:0: warning: "HS_KEY" redefined
>> #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)]))
> So we need to get this one fixed.
As for the HS_KEY
On Thu, Nov 19, 2015 at 5:54 AM, Jeff Janes wrote:
> On Wed, Nov 18, 2015 at 11:18 AM, Jeff Janes wrote:
>>
>> I get an error when running pg_upgrade from 9.4 to 9.6-this
>>
>> error while copying relation "mediawiki.archive"
>> ("/tmp/data/base/16414/21043_vm" to
>> "/tmp/data_fm/base/16400/2104
Don't we need a simple example of TAP tests in src/test ? Something that test
a trivial feature, but shows basic testing tricks?
While explaining to my friends how does TAP test works I wrote an example TAP
test. May be we we should add it to the core with sensible README explanation?
--
Niko
Thank you for the review. I've made changes according to your comments.
I don't stick on current names in the patch.
I've removed all unnecerrary indirections, and added cache aligning
to LWLock arrays.
On Tue, 17 Nov 2015 19:36:13 +0100
"and...@anarazel.de" wrote:
> On 2015-11-17 14:14:50 +030
On 11/19/15 2:13 AM, Michael Paquier wrote:
> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> It seems weird to not have a dedicated role for pg_switch_xlog.
>>
>> I didn't add a pg_switch_xlog default role in this patch series, but
Erik Rijkers wrote:
> In file included from ../../../src/include/postgres.h:48:0,
> from plperl.c:8:
> plperl.c: In function ‘select_perl_context’:
> ../../../src/include/utils/elog.h:41:16: warning: passing argument 1 of
> ‘errmsg’ makes pointer from integer without a cast [-Wint
On 11/19/15 1:17 PM, Michael Paquier wrote:
On Thu, Nov 19, 2015 at 11:04 AM, Marko Tiikkaja wrote:
Further, if someone's going to add new stuff to PreparableStmt, she should
probably think about whether it would make sense to add it to COPY and CTEs
from day one, too, and in that case not split
On 27 March 2015 at 04:54, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund
> wrote in <20150326175024.gj...@alap3.anarazel.de>
>> I think the problem here is that the *primary* makes no such
>> assumptions. Init forks are logged via stuff like
>> smg
On Thu, Nov 19, 2015 at 11:04 AM, Marko Tiikkaja wrote:
> This was discussed in 2010 when CTEs got the same treatment, and I agree
> with what was decided back then. If someone needs to make PreparableStmt
> different from what COPY and CTEs support, we can split them up. But
> they're completely
> On Tue, Nov 17, 2015 at 10:22 PM, Kouhei Kaigai wrote:
> > Apart from EPQ rechecks, the above aggressive push-down idea allows to send
> > contents of multiple relations to the remote side. In this case, ForeignScan
> > needs to have multiple sub-plans.
> >
> > For example, please assume here is
Hi,
I'm using git master, and if I crash the database whilst it's running
pgbench, then restart the database and try to run pgbench again, I
can't:
thom@swift:~/Development/postgresql$ pgbench -c 1 -j 1 -T 20 -S pgbench
...crash database...
connection to database "pgbench" failed:
could not conne
On 11/19/15 4:48 AM, Pavel Stehule wrote:
2015-11-19 4:40 GMT+01:00 Marko Tiikkaja :
I've in the past wanted to listen on all notification channels in the
current database for debugging purposes. But recently I came across
another use case. Since having multiple postgres backends listening for
Hello Michael,
I am planning to continue contributing to this feature in any way be it by
reviewing the patch or making one. Though I haven't been able to reply to
the comments or post an updated patch lately. I plan to do that soon.
Thank you,
Rahila
On Thu, Nov 19, 2015 at 1:09 PM, Michael Paq
Attached fixes $SUBJECT:
s/replication_origin.c/origin.c/g
Thanks,
Amit
diff --git a/src/backend/access/rmgrdesc/replorigindesc.c b/src/backend/access/rmgrdesc/replorigindesc.c
index 60cf0f6..479e3b4 100644
--- a/src/backend/access/rmgrdesc/replorigindesc.c
+++ b/src/backend/access/rmgrdesc/replo
On Thu, Nov 19, 2015 at 5:48 PM, konstantin knizhnik
wrote:
> I want to use logical replication for implementing multimaster (so all nodes
> are both sending and receiving changes).
> But there is one "stupid" problem: how to prevent infinite recursion and not
> to rereplicate replicated data.
>
On 2015/11/19 17:48, konstantin knizhnik wrote:
> Hi,
>
> I want to use logical replication for implementing multimaster (so all nodes
> are both sending and receiving changes).
> But there is one "stupid" problem: how to prevent infinite recursion and not
> to rereplicate replicated data.
> I.e
On Thu, Nov 19, 2015 at 1:29 PM, Amit Kapila
wrote:
>
> On Thu, Nov 19, 2015 at 12:27 AM, Robert Haas
wrote:
> -
> Is the main reason to have add_partial_path() is that it has some
> less checks or is it that current add_path will give wrong answers
> in any case?
>
> If there is no case where ad
Hi,
I want to use logical replication for implementing multimaster (so all nodes
are both sending and receiving changes).
But there is one "stupid" problem: how to prevent infinite recursion and not to
rereplicate replicated data.
I.e. node receives change set from some other node, applies it wi
On 2015-11-19 01:55, Mike Blackwell wrote:
Google says this was present in beta1. (
http://www.postgresql.org/message-id/5596a162.30...@dunslane.net)
Still seems broken, at least for me.
Built with Perl 5.22.
uname -m = x86_64
uname -r = 2.6.32-504.12.2.el6.x86_64
FWIW: Here, Centos 6.6 with
On Thu, Nov 19, 2015 at 12:27 AM, Robert Haas wrote:
>
> On Wed, Nov 18, 2015 at 7:25 AM, Amit Kapila
wrote:
> > Don't we need the startup cost incase we need to build partial paths for
> > joinpaths like mergepath?
> > Also, I think there are other cases for single relation scan where
startup
>
86 matches
Mail list logo
