(2014/11/12 20:04), Ashutosh Bapat wrote:
I reviewed fdw-chk-3 patch. Here are my comments
Thanks for the review!
Tests
---
1. The tests added in file_fdw module look good. We should add tests for
CREATE TABLE with CHECK CONSTRAINT also.
Agreed. I added the tests, and also changed the
On Sat, 2014-11-15 at 21:36 +, Simon Riggs wrote:
> Do I understand correctly that we are trying to account for exact
> memory usage at palloc/pfree time? Why??
Not palloc chunks, only tracking at the level of allocated blocks (that
we allocate with malloc).
It was a surprise to me that accou
On 16 November 2014 19:30, Simon Riggs Wrote:
> Sent: 16 November 2014 19:30
> > I marked the patch as ready for committer.
>
> This looks very interesting.
>
> The value of the patch seems to come from skipping costly checks. Your
> performance test has a leading VARCHAR column, so in that spe
On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier
wrote:
> I'll send an updated patch tomorrow.
Here are updated versions. I divided the patch into two for clarity,
the first one is the actual refactoring patch, renaming
SyncRepGetSynchronousNode to SyncRepGetSynchronousStandby (+alpha,
like updat
On Sat, Nov 8, 2014 at 1:26 AM, Alvaro Herrera
wrote:
>
>
> I just pushed this, after some more minor tweaks. Thanks, and please do
> continue testing!
>
Few typo's and few questions
1. * range. Need to an extra flag in mmtuples for that.
*/
Datum
brinbulkdelete(PG_FUNCTION_ARGS)
Isn't the
On Mon, Nov 17, 2014 at 10:02 AM, Fujii Masao wrote:
> On Sat, Nov 15, 2014 at 9:10 PM, Michael Paquier
> wrote:
>> Yep, sounds a good thing to do if master requested answer from the
>> client in the keepalive message. Something like the patch attached
>> would make the deal.
>
> Isn't it better
On 13 November 2014 15:35 Amit Kapila Wrote,
>As mentioned by you offlist that you are not able reproduce this
>issue, I have tried again and what I observe is that I am able to
>reproduce it only on *release* build and some cases work without
>this issue as well,
>example:
>./vacuumdb --analyze-i
On Sat, Nov 15, 2014 at 9:10 PM, Michael Paquier
wrote:
> On Sat, Nov 15, 2014 at 3:42 AM, Andres Freund wrote:
>> On 2014-11-15 03:25:16 +0900, Fujii Masao wrote:
>>> On Fri, Nov 14, 2014 at 7:22 PM, wrote:
>>> > "pg_ctl stop" does't work propley, if --slot option is specified when WAL
>>> >
Hi
2014-11-07 22:37 GMT+01:00 Alvaro Herrera :
>
> I did \o /tmp/tst, then
> \dS
> create table "eh | oh" ();
> \dS
>
> and then filtered the output file to HTML. The CREATE TABLE tag ended
> up in the same line as the title of the following table. I think
> there's a newline is missing somewhe
On 11/13/2014 02:44 PM, Andres Freund wrote:
Hi Steve,
If it still happens, could you send me instructions of how to reproduce
the problem after cloning the necessary source repositories? It's quite
hard to validate a possible fix otherwise.
1. Install PG 9.4
2. Perform an initdb
max_con
* Alvaro Herrera wrote:
Michael Paquier wrote:
Btw, perhaps this diff should be pushed as a different patch as this is a
rather different thing:
- if (heapRelation->rd_rel->relpersistence == RELPERSISTENCE_UNLOGGED
&&
+ if (indexRelation->rd_rel->relpersistence ==
RELPERSISTENCE_UN
On Sun, Nov 9, 2014 at 3:46 PM, Magnus Hagander wrote:
> On Thu, Nov 6, 2014 at 3:01 PM, Peter Eisentraut wrote:
>> On 11/6/14 6:16 AM, Magnus Hagander wrote:
>>> Another thought I had in that case is maybe we need to break out the
>>> pg_stat_activity and pg_stat_replication views into their own
On 30 October 2014 08:43, Haribabu Kommi wrote:
> I marked the patch as ready for committer.
This looks very interesting.
The value of the patch seems to come from skipping costly checks. Your
performance test has a leading VARCHAR column, so in that specific
case skipping the leading column is
On 16/11/14 13:13, didier wrote:
I think you have to add
recovery_target_timeline = '2'
in recovery.conf
with '2' being the new primary timeline .
cf http://www.postgresql.org/docs/9.4/static/recovery-target-settings.html
Thank you.
Based on the link I have added:
recovery_target_timeline = '
On Fri, Nov 14, 2014 at 12:03 PM, Andres Freund wrote:
> Note that you'd definitely not want to do this naively - currently
> there's baked in assumptions into the vaccum code that only one backend
> is doing parts of it.
>
> I think there's
Did something you intended get left out here?
>> 4. Pa
Hi,
On Sat, Nov 15, 2014 at 5:31 PM, Maeldron T. wrote:
>> A safely shut down master (-m fast is safe) can be safely restarted as
>> a slave to the newly promoted master. Fast shutdown shuts down all
>> normal connections, does a shutdown checkpoint and then waits for this
>> checkpoint to be re
Thanks for the comments!
On Sun, Nov 16, 2014 at 8:32 PM, Simon Riggs wrote:
> On 31 October 2014 00:27, Michael Paquier wrote:
>> On Fri, Oct 31, 2014 at 6:59 AM, Jim Nasby wrote:
>>>
>>> If we stick with this version I'd argue it makes more sense to just stick
>>> the sync_node = and priority
On 31 October 2014 00:27, Michael Paquier wrote:
> On Fri, Oct 31, 2014 at 6:59 AM, Jim Nasby wrote:
>>
>> If we stick with this version I'd argue it makes more sense to just stick
>> the sync_node = and priority = statements into the if block and ditch the
>> continue.
>
> Let's go with the cle
On 16 November 2014 06:59, Michael Paquier wrote:
> 1) This patch is authorizing VACUUM and CLUSTER to use the event
> triggers ddl_command_start and ddl_command_end, but aren't those
> commands actually not DDLs but control commands?
I could go either way on that. I'm happy to remove those from
On 16 November 2014 06:59, Michael Paquier wrote:
> Note that this patch has been submitted but there have been no real
> discussion around it.. This seems a bit too fast to commit it, no?
Committing uncontentious patches at the end of the commitfest seems normal, no?
--
Simon Riggs
20 matches
Mail list logo