I've been working on fixing the bugs that Jeff Janes found [1] with
approach #2 to value locking [2]. Approach #1 was unaffected.
I'm starting this new thread, to discuss these issues. Let's try and
confine discussion of semantics and syntax to the main thread, since
that has been what has mostly
On 31 December 2014 18:36, Amit Kapila Wrote,
>The patch looks good to me. I have done couple of
>cosmetic changes (spelling mistakes, improve some comments,
>etc.), check the same once and if you are okay, we can move
>ahead.
Thanks for review and changes, changes looks fine to me..
Regards,
D
On Wed, Dec 31, 2014 at 01:56:08PM -0500, Noah Misch wrote:
> On Wed, Dec 31, 2014 at 12:32:37AM -0500, Robert Haas wrote:
> > On Sun, Dec 28, 2014 at 4:58 PM, Noah Misch wrote:
> > > I wondered whether to downgrade FATAL to LOG in back branches.
> > > Introducing a
> > > new reason to block sta
On Wed, Dec 31, 2014 at 01:55:23PM -0500, Dave Cramer wrote:
> So at this point removing the --enable-nls from my config will solve the
> build problem.
>
> Everyone knows there is an issue so there is no point in continuing to have
> it fail.
We hope all packagers will build with --enable-nls,
On Fri, Jan 2, 2015 at 1:59 AM, Bruce Momjian wrote:
>
> On Thu, Jan 1, 2015 at 10:40:53AM +0530, Amit Kapila wrote:
> > Good question, I think there might be some impact due to that, but in
> > general for page level compression still there will be much more to
> > compress.
> >
> > In general,
On Thu, Jan 1, 2015 at 12:03 PM, Michael Paquier
wrote:
> On Thu, Jan 1, 2015 at 2:10 PM, Amit Kapila
wrote:
> > On Thu, Jan 1, 2015 at 2:39 AM, Bruce Momjian wrote:
> >> > So why are you bringing it up? That's not an argument for anything,
> >> > except not doing it in such a simplistic way.
>
So at this point removing the --enable-nls from my config will solve the
build problem.
Everyone knows there is an issue so there is no point in continuing to have
it fail.
On 31 December 2014 at 13:52, Noah Misch wrote:
> On Sun, Dec 28, 2014 at 07:20:04PM -0500, Andrew Dunstan wrote:
> > On
David Rowley wrote:
> At the moment I feel the patch is a bit half done. I really think that
> since the gaussian and exponential stuff was added in commit ed802e7d, that
> this should now be changed so that we have functions like random(),
> erandom() and grandom() and the way to use this becomes
On Wed, Dec 31, 2014 at 12:46:17PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Dec 29, 2014 at 11:03 AM, Tom Lane wrote:
> >> Either one of those approaches would cripple our freedom to change those
> >> data structures; which we've done repeatedly in the past and will surely
> >> wa
On Wed, Dec 31, 2014 at 4:23 PM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Wed, Dec 31, 2014 at 3:08 PM, Stephen Frost
> wrote:
> > > * Magnus Hagander (mag...@hagander.net) wrote:
> > > I think having it do exactly what pg_dump needs, and not things like
> > >
On Thu, Jan 1, 2015 at 10:40:53AM +0530, Amit Kapila wrote:
> Good question, I think there might be some impact due to that, but in
> general for page level compression still there will be much more to
> compress.
>
> In general, I think this idea has merit with respect to compressible data,
>
On Thu, Jan 1, 2015 at 09:04:48PM +0100, Andres Freund wrote:
> On January 1, 2015 8:49:06 PM CET, Robert Haas wrote:
> >On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund
> >wrote:
> >> The problem is that just aligning the main allocation to some
> >boundary
> >> doesn't mean the hot part of the a
On January 1, 2015 8:49:06 PM CET, Robert Haas wrote:
>On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund
>wrote:
>> The problem is that just aligning the main allocation to some
>boundary
>> doesn't mean the hot part of the allocation is properly aligned.
>shmem.c
>> in fact can't really do much abo
On Thu, Jan 1, 2015 at 11:59 AM, Andres Freund wrote:
> The problem is that just aligning the main allocation to some boundary
> doesn't mean the hot part of the allocation is properly aligned. shmem.c
> in fact can't really do much about that - so fully moving the
> responsibility seems more like
On Thu, Jan 1, 2015 at 05:59:25PM +0100, Andres Freund wrote:
> > That seems like a strange approach. I think it's pretty sensible to
> > try to ensure that allocated blocks of shared memory have decent
> > alignment, and we don't have enough of them for aligning on 64-byte
> > boundaries (or eve
On Thu, Jan 1, 2015 at 12:00 PM, Fabrízio de Royes Mello
wrote:
> Can we check the number of free bgworkers slots to set the max workers?
The real solution here is that this patch can't throw an error if it's
unable to obtain the desired number of background workers. It needs
to be able to smoot
> I think one thing we could do minimize the chance of such an
> error is set the value of parallel workers to be used for plan equal
> to max_worker_processes if parallel_seqscan_degree is greater
> than max_worker_processes. Even if we do this, still such an
> error can come if user has register
On 2015-01-01 11:55:03 -0500, Robert Haas wrote:
> On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund wrote:
> >> Andres reported the above 2x pgbench difference in February, but no
> >> action was taken as everyone felt there needed to be more performance
> >> testing, but it never happened:
> >
> >
On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund wrote:
>> Andres reported the above 2x pgbench difference in February, but no
>> action was taken as everyone felt there needed to be more performance
>> testing, but it never happened:
>
> FWIW, I have no idea what exactly should be tested there. Rig
Hello David,
At the moment I feel the patch is a bit half done. I really think that
since the gaussian and exponential stuff was added in commit ed802e7d, that
this should now be changed so that we have functions like random(),
erandom() and grandom() and the way to use this becomes:
\set na
Hi All,
While looking at the patch for supporting inheritance on foreign tables, I
noticed that if a transaction makes changes to more than two foreign
servers the current implementation in postgres_fdw doesn't make sure that
either all of them rollback or all of them commit their changes, IOW ther
On Wed, Dec 31, 2014 at 9:46 PM, Thom Brown wrote:
>
> Another issue (FYI, pgbench2 initialised with: pgbench -i -s 100 -F 10
pgbench2):
>
>
> ➤ psql://thom@[local]:5488/pgbench2
>
> # explain (analyse, buffers, verbose) select distinct bid from
pgbench_accounts;
> server closed the connection un
On 1 January 2015 at 21:23, Fabien COELHO wrote:
>
> I was about to go and look at this, but I had a problem when attempting to
>> compile with MSVC.
>>
>
> Thanks! Here is a v4 which includes your fix.
Thank you.
I've had a quick look at the patch as I'm quite interested in seeing some
impro
I was about to go and look at this, but I had a problem when attempting to
compile with MSVC.
Thanks! Here is a v4 which includes your fix.
--
Fabien.diff --git a/contrib/pgbench/.gitignore b/contrib/pgbench/.gitignore
index 489a2d6..aae819e 100644
--- a/contrib/pgbench/.gitignore
+++ b/contr
24 matches
Mail list logo
