On Fri, Sep 12, 2014 at 1:50 PM, Dilip kumar wrote:
> On 11 September 2014 10:21, Amit kapila Wrote,
> >I don't think currently such a limitation is mentioned in docs,
>
> >however I think we can update the docs at below locations:
> >1. In description of pg_start_backup in below page:
> >
http://
On 09/12/2014 11:38 AM, Heikki Linnakangas wrote:
Now that the logic is fixed, I hope we
won't get complaints that the indexes are bigger, if you fill a table by
appending to the end. I wonder if we should aim at an even more uneven
split; the default fillfactor for B-trees is 90%, for example. I
On 09/12/2014 03:48 AM, Michael Paquier wrote:
On Fri, Sep 12, 2014 at 7:35 AM, Gaetano Mendola wrote:
At line 650 I can read:
if ((leaf->lsize - segsize) - (leaf->lsize - segsize) < BLCKSZ / 4)
break;
I believe one of the two should be leaf->rsize
Yes this condition is broken. S
On 11 September 2014 10:21, Amit kapila Wrote,
>I don't think currently such a limitation is mentioned in docs,
>however I think we can update the docs at below locations:
>1. In description of pg_start_backup in below page:
>http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTI
(2014/09/12 16:03), Albe Laurenz wrote:
Tom Lane wrote:
Stephen Frost writes:
I have to admit that, while I applaud the effort made to have this
change only be to postgres_fdw, I'm not sure that having the
update/delete happening during the Scan phase and then essentially
no-op'ing the ExecFor
On 09/12/2014 03:17 AM, Michael Paquier wrote:
On Fri, Sep 12, 2014 at 9:08 AM, Michael Paquier
wrote:
In walsender.c, sentPtr is initialized as follows:
static XLogRecPtr sentPtr = 0;
Isn't that incorrect and shouldn't we use InvalidXLogRecPtr instead?
Actually by looking more around I found
(2014/09/11 20:51), Heikki Linnakangas wrote:
On 09/11/2014 02:30 PM, Etsuro Fujita wrote:
So, should I split the patch into the two?
Yeah, please do.
OK, Will do.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Tom Lane wrote:
> Stephen Frost writes:
>> I have to admit that, while I applaud the effort made to have this
>> change only be to postgres_fdw, I'm not sure that having the
>> update/delete happening during the Scan phase and then essentially
>> no-op'ing the ExecForeignUpdate/ExecForeignDelete i
101 - 108 of 108 matches
Mail list logo