On 2015/10/07 15:06, Kyotaro HORIGUCHI wrote:
At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas wrote
I think it rather requires *replacing* two resjunk columns by one new
one. The whole-row references for the individual foreign tables are
only there to support EvalPlanQual; if we instead have a
Hi All,
There appears to be a typo error in documentation of this function. Actual
function is 'pg_replication_origin_session_setup' while documentation has
it as 'pg_replication_origin_setup_session'.
Please find patch for 9.5 and master attached.
Thanks,
Pallavi
diff --git a/doc/src/sgml/func.
On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier
wrote:
> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier
> wrote:
>> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
>>> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
>>> It seems that these days 'make check' creates a directory in /tmp
Hello,
At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas wrote in
> On Wed, Oct 7, 2015 at 12:10 AM, Kyotaro HORIGUCHI
> wrote:
> >> IIUC, I think that if ROW_MARK_COPY is in use, the descriptor would
> >> have 6 columns: those 4, plus a whole-row var for ft1 and another
> >> whole-row bar for ft
On Wed, Oct 7, 2015 at 12:10 AM, Kyotaro HORIGUCHI
wrote:
>> IIUC, I think that if ROW_MARK_COPY is in use, the descriptor would
>> have 6 columns: those 4, plus a whole-row var for ft1 and another
>> whole-row bar for ft2. Maybe I'm missing something, though.
>
> You're right. The result tuple f
On Tue, Oct 6, 2015 at 11:30 PM, Etsuro Fujita
wrote:
> IIUC, I think that if ROW_MARK_COPY is in use, the descriptor would have 6
> columns: those 4, plus a whole-row var for ft1 and another whole-row bar for
> ft2. Maybe I'm missing something, though.
Currently, yes, but I think we should chan
Hello,
At Wed, 7 Oct 2015 12:30:27 +0900, Etsuro Fujita
wrote in <561491d3.3070...@lab.ntt.co.jp>
> On 2015/10/07 6:19, Robert Haas wrote:
> > On Fri, Oct 2, 2015 at 4:26 AM, Kyotaro HORIGUCHI
> > wrote:
> >> During join search, a joinrel should be comptible between local
> >> joins and remote
On 2015/10/07 6:19, Robert Haas wrote:
On Fri, Oct 2, 2015 at 4:26 AM, Kyotaro HORIGUCHI
wrote:
During join search, a joinrel should be comptible between local
joins and remote joins, of course target list also should be
so. So it is quite difficult to add wholerow resjunk for joinrels
before w
Ouch!
At Tue, 6 Oct 2015 17:22:17 -0400, Robert Haas wrote in
> On Mon, Oct 5, 2015 at 6:07 AM, Kyotaro HORIGUCHI
> wrote:
> > /*
> > * We use the expand_dbname parameter to process the connection
> > string (or
> > -* URI), and pass some extra options. The deliberate
On 2015/10/07 7:01, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
>> wrote:
>>> I think "best_inner_indexscan()" in the following comment in tidpath.c
>>> is obsolete.
>>>
>>> * There is currently no special support for joins involving CTID; in
>>> * parti
> > > > Who can provide a projection to generate joined tuple?
> > > > It is a job of individual plan-state-node to be walked on during
> > > > EvalPlanQualNext().
> > >
> > > EvalPlanQualNext simply does recheck tuples stored in epqTuples,
> > > which are designed to be provided by EvalPlanQualFet
On Tue, Oct 6, 2015 at 10:29 PM, Stephen Frost wrote:
> * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
>> On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
>> wrote:
>> > Here I attached an updated version of the patch with the following changes.
>>
>> I found some problems related to providing
On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier
wrote:
> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
>> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
>> It seems that these days 'make check' creates a directory in /tmp
>> called /tmp/pg_regress-RANDOMSTUFF. Listening on TCP ports
When working on a script, I stumbled over a mistake in the pt_BR.po
translation for ecpg. Patch attached.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany -
On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
> It seems that these days 'make check' creates a directory in /tmp
> called /tmp/pg_regress-RANDOMSTUFF. Listening on TCP ports is
> disabled, and the socket goes inside this directory with
When working on a script, I stumbled over a mistake in the zh_CN.po
translation for initdb. Patch attached.
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany
On Mon, Oct 5, 2015 at 1:29 PM, Stas Kelvich wrote:
> Hello.
>
> There is patch that adds some editing routines for tsvector type.
>
> tsvector delete(tsvector, text)
> removes entry from tsvector by lexeme name
> set unnest(tsvector)
> expands a tsvector to a set of rows. Each row
On Tue, Oct 6, 2015 at 6:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 6, 2015 at 6:10 PM, Tom Lane wrote:
>>> I'm concerned though whether this would amount to a protocol break.
>
>> Me, too.
>
> There are enough CCI's floating around the code that there may not
> actually be any
Robert Haas writes:
> On Tue, Oct 6, 2015 at 6:10 PM, Tom Lane wrote:
>> I'm concerned though whether this would amount to a protocol break.
> Me, too.
There are enough CCI's floating around the code that there may not
actually be any observable problem, at least not in typical cases.
That woul
On Tue, Oct 6, 2015 at 6:10 PM, Tom Lane wrote:
> I'm concerned though whether this would amount to a protocol break.
Me, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Robert Haas writes:
> On Tue, Oct 6, 2015 at 5:53 PM, Tom Lane wrote:
>> I dunno, if you close a portal before you've gotten CommandComplete,
>> should you expect that all its actions were taken? Arguably, that
>> should be more like a ROLLBACK.
> I dunno either, but a rollback would undo every
On Wed, Oct 7, 2015 at 7:05 AM, Michael Paquier
wrote:
> On Wed, Oct 7, 2015 at 6:44 AM, Tom Lane wrote:
>> I wrote:
>>> So the attached modified patch adjusts the PID-match logic and some
>>> comments, but is otherwise what I posted before. I believe that this
>>> might actually work on Windows
On Wed, Oct 7, 2015 at 6:44 AM, Tom Lane wrote:
> I wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before. I believe that this
>> might actually work on Windows, but I have no way to test it. Someone
>> please try that?
Robert Haas writes:
> On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
> wrote:
>> I think "best_inner_indexscan()" in the following comment in tidpath.c
>> is obsolete.
>>
>> * There is currently no special support for joins involving CTID; in
>> * particular nothing corresponding to best_inner_in
On 10/06/2015 05:45 PM, Thomas Munro wrote:
On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas wrote:
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan wrote:
Isn't this arguably a Fedora regression? What did they change in F23 to make
it fail? I note that F23 is still in Beta.
Maybe, but it's pret
On Tue, Oct 6, 2015 at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> From looking at the code, it appears to me that if the Execute is run
>> to completion, then its results will be seen by future statements, but
>> if the portal is closed earlier, then not. See the end of
>> exec_execute_me
Robert Haas writes:
> From looking at the code, it appears to me that if the Execute is run
> to completion, then its results will be seen by future statements, but
> if the portal is closed earlier, then not. See the end of
> exec_execute_message. The handler for the Close message (inside
> Pos
On 10/06/2015 04:49 PM, Robert Haas wrote:
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan wrote:
Isn't this arguably a Fedora regression? What did they change in F23 to make
it fail? I note that F23 is still in Beta.
Maybe, but it's pretty unfriendly for us to complain about a library
issue
On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas wrote:
> On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan wrote:
>> Isn't this arguably a Fedora regression? What did they change in F23 to make
>> it fail? I note that F23 is still in Beta.
>
> Maybe, but it's pretty unfriendly for us to complain about
I wrote:
> So the attached modified patch adjusts the PID-match logic and some
> comments, but is otherwise what I posted before. I believe that this
> might actually work on Windows, but I have no way to test it. Someone
> please try that? (Don't forget to test the service-start path, too.)
Ha
On Sat, Oct 3, 2015 at 5:03 AM, Shay Rojansky wrote:
> Hi hackers, some odd behavior has been reported with Npgsql and I wanted to
> get your help.
>
> Npgsql supports sending multiple SQL statements in a single packet via the
> extended protocol. This works fine, but when the second query SELECTs
On Mon, Oct 5, 2015 at 6:07 AM, Kyotaro HORIGUCHI
wrote:
> /*
> * We use the expand_dbname parameter to process the connection
> string (or
> -* URI), and pass some extra options. The deliberately undocumented
> -* parameter "replication=true" makes it a replicati
On Fri, Oct 2, 2015 at 4:26 AM, Kyotaro HORIGUCHI
wrote:
> During join search, a joinrel should be comptible between local
> joins and remote joins, of course target list also should be
> so. So it is quite difficult to add wholerow resjunk for joinrels
> before whole join tree is completed even i
On Mon, Oct 5, 2015 at 3:05 AM, Etsuro Fujita
wrote:
> I think "best_inner_indexscan()" in the following comment in tidpath.c
> is obsolete.
>
> * There is currently no special support for joins involving CTID; in
> * particular nothing corresponding to best_inner_indexscan(). Since it's
> * n
On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier
wrote:
>> Granted, you have to try fairly hard to shoot yourself in the leg,
>> but since the solution is so simple, why not? If we never reuse ports
>> within a single test, this goes away.
>
> Well, you can reuse the same port number in a test. Sim
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan wrote:
> Isn't this arguably a Fedora regression? What did they change in F23 to make
> it fail? I note that F23 is still in Beta.
Maybe, but it's pretty unfriendly for us to complain about a library
issue, if it is one, by failing an Assert(). Peo
On Sun, Oct 4, 2015 at 3:25 PM, Andres Freund wrote:
> I don't think it's worth investing time and complexity to bypass SLRU in
> certain cases. We should rather rewrite the thing completely.
+1. That code is considerably past its sell-by date.
--
Robert Haas
EnterpriseDB: http://www.enterpris
On Tue, Oct 6, 2015 at 4:26 PM, Peter Geoghegan wrote:
> On Tue, Oct 6, 2015 at 1:16 PM, Robert Haas wrote:
>>> I guess I imagined that bswap64() was fundamental infrastructure, but
>>> on second thought that's not actually in evidence -- it is not already
>>> needed in plenty of other places. So
On Tue, Oct 6, 2015 at 1:16 PM, Robert Haas wrote:
>> I guess I imagined that bswap64() was fundamental infrastructure, but
>> on second thought that's not actually in evidence -- it is not already
>> needed in plenty of other places. So yeah, works for me.
>
> If you would care to revise the patc
On Tue, Oct 6, 2015 at 4:09 PM, Peter Geoghegan wrote:
> On Tue, Oct 6, 2015 at 1:07 PM, Robert Haas wrote:
>> Reviewing 0001, I'm happy to see us add bswap64, but I'm not sure we
>> should put it in c.h, because that's included by absolutely
>> everything. How about putting it in a new #include
On Sun, Oct 4, 2015 at 2:21 AM, Peter Geoghegan wrote:
> Attached is SortSupport for UUID type patch. This accelerates all UUID
> related sort-intense operations, making them about twice as fast with
> millions of tuples. I know that Heroku has plenty of tables used by
> various applications with
On Tue, Oct 6, 2015 at 1:07 PM, Robert Haas wrote:
> Reviewing 0001, I'm happy to see us add bswap64, but I'm not sure we
> should put it in c.h, because that's included by absolutely
> everything. How about putting it in a new #include inside src/port,
> like src/port/pg_bswap.h? Then pg_crc.h
On Sun, Oct 4, 2015 at 2:17 AM, Peter Geoghegan wrote:
> On Tue, Aug 4, 2015 at 12:41 PM, Robert Haas wrote:
>> Some comments:
>
> I attach a new version of the patch series that incorporates all your
> feedback. The patch series is now made cumulative in a way that makes
> it easy for someone to
On Thu, Oct 1, 2015 at 11:01 PM, Michael Paquier
wrote:
>> Right, see attached.
>
> It seems to me that we could as well simplify checkpoint.c and
> logical.c. In those files volatile casts are used as well to protect
> from reordering for spinlock operations. See for example 0002 on top
> of 0001
On 10/06/2015 12:03 PM, Bruce Momjian wrote:
> On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> On 10/06/2015 10:57 AM, Josh Berkus wrote:
On 10/06/2015 10:17 AM, Bruce Momjian wrote:
>>
Speaking of which ... this project is rich in skilled use
On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > On 10/06/2015 10:57 AM, Josh Berkus wrote:
> > >On 10/06/2015 10:17 AM, Bruce Momjian wrote:
>
> > >Speaking of which ... this project is rich in skilled users who are
> > >involved in the community but do
On 10/06/2015 11:51 AM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
[I have heated water with wood till boiling point, FWIW]
Hahahah I have no doubt.
It should be, "I once heated water with wood and it didn't boil. How can I
change my process so that it will?"
Oh, I am not saying we s
Joshua D. Drake wrote:
> On 10/06/2015 11:33 AM, Alvaro Herrera wrote:
> >So I am dubious that people that currently do not contribute will
> >contribute in the future just because we change the system.
>
> No, not just because we change the software. The mindset has to change too
> and procedure
On 10/06/2015 11:33 AM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
On 10/06/2015 10:57 AM, Josh Berkus wrote:
On 10/06/2015 10:17 AM, Bruce Momjian wrote:
Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is exactly th
On Tue, Oct 06, 2015 at 01:17:48PM -0400, Bruce Momjian wrote:
> I do think we rushed to choose a tracker a little too quickly.
Have we chosen one?
> Let me explain, from a high level, what a new tracker will change in
> our workflow.
[snip]
I won't quote your whole message, which I essentiall
Joshua D. Drake wrote:
> On 10/06/2015 10:57 AM, Josh Berkus wrote:
> >On 10/06/2015 10:17 AM, Bruce Momjian wrote:
> >Speaking of which ... this project is rich in skilled users who are
> >involved in the community but don't code. Bug triage is exactly the
> >kind of thing very part-time communi
On Tue, Oct 6, 2015 at 8:52 AM, Andres Freund wrote:
> I think it'd be good to add a test exercising two servers with different
> extensions marked as shippable.
Done,
P
20151006b_postgres_fdw_extensions.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Tue, Oct 6, 2015 at 10:57:42AM -0700, Josh Berkus wrote:
> This is kind of like CVS. We didn't upgrade so Subversion, becuase we
> said "we already have a user-friendly interface to CVS, called Marc."
> We only moved to git when it could provide us with solid advantages.
>
> I believe the sam
On Tue, Oct 6, 2015 at 8:15 PM, Nathan Wagner wrote:
> On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote:
>
> > Speaking of which ... this project is rich in skilled users who are
> > involved in the community but don't code. Bug triage is exactly the
> > kind of thing very part-time c
On 6 October 2015 at 12:32, Nathan Wagner wrote:
>
> Also, the version numbers are user reported and a bit of a mess. I
> don't think they could really be relied on as is for users trying to
> find out if a bug affects their version. Someone would have to update
> that information, and communica
On 10/06/2015 10:57 AM, Josh Berkus wrote:
On 10/06/2015 10:17 AM, Bruce Momjian wrote:
This is kind of like CVS. We didn't upgrade so Subversion, becuase we
said "we already have a user-friendly interface to CVS, called Marc."
We only moved to git when it could provide us with solid advantag
On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote:
> On 10/06/2015 10:17 AM, Bruce Momjian wrote:
> > Therefore, our current default behavior is to ignore user reports,
> > unless someone takes an action to reply, record, or retain the email for
> > later review. What a tracker does is
On 10/06/2015 10:17 AM, Bruce Momjian wrote:
> First, let me say I am glad we are talking about this, and am open to
> the criticism that my and other's tracking open items by keeping them in
> our personal mailboxes is not only odd, but bizarre given the size of
> our community and the responsibil
On Tue, Oct 06, 2015 at 12:04:11PM -0500, Jaime Casanova wrote:
> I like how this page is looking now, good work.
Thank you.
> Now, AFAIU from previous mails part of the reason to have a bug
> tracker is to make easy to know when a bug was fixed. Which should be
> interpreted as: which versions
On Tue, Oct 6, 2015 at 01:05:24PM +, Nathan Wagner wrote:
> So, in order to do some clean up and see how my pgbugs page
> (https://granicus.if.org/pgbugs/) might actually work I've been going
> through bugs and marking their status. A lot of questions arise.
>
> A lot of the reports aren't b
Magnus Hagander writes:
> It doesn't actually. You can post to the bugs list without being subscribed
> and it hits moderation. If you fill out the bug form without being
> subscribed, it hits exactly the same moderation. There is no difference -
> the bug form basically just sends an email with y
On Tue, Oct 6, 2015 at 7:04 PM, Jaime Casanova <
jaime.casan...@2ndquadrant.com> wrote:
> On 6 October 2015 at 08:05, Nathan Wagner wrote:
> > A lot of the reports aren't bugs at all, but requests for help. My
> > guess is that the users either don't know where to ask or don't
> > understand the
On 6 October 2015 at 08:05, Nathan Wagner wrote:
> So, in order to do some clean up and see how my pgbugs page
> (https://granicus.if.org/pgbugs/) might actually work I've been going
> through bugs and marking their status. A lot of questions arise.
>
/* DISCLAIMER */
My opinion is not
This patch changes in
http://www.postgresql.org/docs/9.5/static/sql-createtype.html
"variable length" into "variable-length", since in other places there it is
written with "-" in the middle, not " ".
--
Nikolay Shaplov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Comp
On 2015-10-06 07:01:53 -0700, Paul Ramsey wrote:
> diff --git a/contrib/postgres_fdw/sql/shippable.sql
> b/contrib/postgres_fdw/sql/shippable.sql
> new file mode 100644
> index 000..83ee38c
> --- /dev/null
> +++ b/contrib/postgres_fdw/sql/shippable.sql
> @@ -0,0 +1,76 @@
I think it'd be good
On Tue, Oct 6, 2015 at 10:32 PM, Andres Freund wrote:
> Maybe I'm missing something major here. But given that you're looking up
> solely based on Oid objnumber, Oid classnumber, how would this cache
> work if there's two foreign servers with different extension lists?
Oh. Nice catch here.
--
Mic
On Wednesday 30 September 2015 14:41:34 you wrote:
> On Tue, Sep 29, 2015 at 12:08:56PM +1300, Gavin Flower wrote:
> > Linux kernel project uses bugzilla (https://bugzilla.kernel.org)
>
> AIUI this is not mandatory for kernel hackers, and more opt-in from a
> some/many/a few(?) subsystem maintaine
On Tue, Oct 6, 2015 at 6:55 AM, Andres Freund wrote:
> On 2015-10-06 06:42:17 -0700, Paul Ramsey wrote:
>> *sigh*, no you’re not missing anything. In moving to the cache and
>> marking things just as “shippable” I’ve lost the test that ensures
>> they are shippable for this *particular* server (wh
On 2015-10-06 06:42:17 -0700, Paul Ramsey wrote:
> *sigh*, no you’re not missing anything. In moving to the cache and
> marking things just as “shippable” I’ve lost the test that ensures
> they are shippable for this *particular* server (which only happens in
> the lookup stage). So yeah, the cache
On Tue, Oct 6, 2015 at 03:58:44PM +0900, Michael Paquier wrote:
> On Tue, Oct 6, 2015 at 12:41 AM, Oleksii Kliukin wrote:
> > pg_rewind -D postgresql0 --source-server="host=127.0.0.1 port=5433
> > dbname=postgres"
> > The servers diverged at WAL position 0/360 on timeline 1.
> > could not ope
On October 6, 2015 at 6:32:36 AM, Andres Freund
(and...@anarazel.de(mailto:and...@anarazel.de)) wrote:
> On 2015-10-06 06:28:34 -0700, Paul Ramsey wrote:
> > +/*
> > + * is_shippable
> > + * Is this object (proc/op/type) shippable to foreign server?
> > + * Check cache first, then look-up whether
Nathan,
* Nathan Wagner (nw...@hydaspes.if.org) wrote:
> So, in order to do some clean up and see how my pgbugs page
> (https://granicus.if.org/pgbugs/) might actually work I've been going
> through bugs and marking their status. A lot of questions arise.
Thanks for working on this!
> A lot of
On 2015-10-06 06:28:34 -0700, Paul Ramsey wrote:
> +/*
> + * is_shippable
> + * Is this object (proc/op/type) shippable to foreign server?
> + * Check cache first, then look-up whether (proc/op/type) is
> + * part of a declared extension if it is not cached.
> + */
> +bool
> +is_shippab
On Tue, Oct 6, 2015 at 5:32 AM, Andres Freund wrote:
> The problem is basically that cache invalidations can arrive while
> you're building new cache entries. Everytime you e.g. open a relation
> cache invalidations can arrive. Assume you'd written the code like:
> You're avoiding that by only e
Use the correct name “pgindent” in comments.
0001-Make-pgindent-references-consistent.patch
Description: Binary data
--
David Christensen
PostgreSQL Team Manager
End Point Corporation
da...@endpoint.com
785-727-1171
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Fixes a build issue I ran into while adding some columns to system tables:
Throws a build error if we encounter a different number of fields in a
DATA() line than we expect for the catalog in question.
Previously, it was possible to silently ignore any mismatches at build
time
So, in order to do some clean up and see how my pgbugs page
(https://granicus.if.org/pgbugs/) might actually work I've been going
through bugs and marking their status. A lot of questions arise.
A lot of the reports aren't bugs at all, but requests for help. My
guess is that the users either don
On 2015-10-03 19:40:40 -0700, Paul Ramsey wrote:
> > > + /*
> > > + * Right now "shippability" is exclusively a function of whether
> > > + * the obj (proc/op/type) is in an extension declared by the user.
> > > + * In the future we could additionally have a whitelist of functions
> > > +
On October 4, 2015 at 9:56:10 PM, Michael Paquier
(michael.paqu...@gmail.com(mailto:michael.paqu...@gmail.com)) wrote:
> On Sun, Oct 4, 2015 at 11:40 AM, Paul Ramsey wrote:
> > I put all changes relative to your review here if you want a nice colorized
> > place to check
> >
> > https://github.c
Hello.
I tried to read this and had some random comments on this.
-- general
I got some warning on compilation on unused variables and wrong
arguemtn type.
I failed to have a query that this patch works on. Could you let
me have some specific example for this patch?
This patch needs more comme
* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
> wrote:
> > Here I attached an updated version of the patch with the following changes.
>
> I found some problems related to providing multi-tenancy on a system
> catalog view.
> This is because,
Hello,
Please check the attached patch as the earlier one had typo in regression test
output.
>+#define PG_STAT_GET_PROGRESS_COLS30
>Why did you use 30?
That has come from N_PROGRESS_PARAM * 3 where N_PROGRESS_PARAM = 10 is the
number of progress parameters of each type stored in shared me
Hi All,
standard_qp_callback() sets root->query_pathkeys to pathkeys on which the
result of query_planner are expected be sorted upon (see the function for
more details). The patch checks if any prefix of these pathkeys can be
entirely evaluated using the foreign relation and at the foreign server
Hello Fujii-san,
>Here are another review comments
Thank you for review. Please find attached an updated patch.
> You removed some empty lines, for example, in vacuum.h.
>Which seems useless to me.
Has been corrected in the attached.
>Why did you use an array to store the progress information o
On Tue, Oct 6, 2015 at 6:04 PM, Oleksii Kliukin wrote:
> Does pg_rewind actually rely on the cluster being rewound to finish
> recovery?
That's not mandatory AFAIK. I think that Heikki has just implemented
it in the safest way possible for a first shot. That's something we
could relax in the futu
> On 06 Oct 2015, at 08:58, Michael Paquier
> wrote:
>
> On Tue, Oct 6, 2015 at 12:41 AM, Oleksii Kliukin
> wrote:
>> pg_rewind -D postgresql0 --source-server="host=127.0.0.1 port=5433
>> dbname=postgres" The servers diverged at WAL position 0/360 on
>> timeline 1. could not open file
>> "da
86 matches
Mail list logo
