Hello Peter,
http://git.postgresql.org/pg/commitdiff/b87b2f4bda1a3b98f8dea867b8bc419ace7a9ea9
doc/src/sgml/ref/pgbench.sgml | 8
- Here is example outputs:
+ Here is example output:
I think that something is missing now on this line. Should it rather be
"Here is an example out
On Sat, Apr 23, 2016 at 8:58 PM, Bruce Momjian wrote:
> Why is the parallelism variable called "max_parallel_degree"? Is that a
> descriptive name? What does "degree" mean? Why is it not called
> "max_parallel_workers"?
I also think that "max_parallel_workers" works better.
While certain othe
On Sun, Apr 24, 2016 at 9:28 AM, Bruce Momjian wrote:
>
> Why is the parallelism variable called "max_parallel_degree"? Is that a
> descriptive name? What does "degree" mean?
It is to denote amount of parallelism at node level.
>
> Why is it not called
> "max_parallel_workers"?
>
Degree of
Why is the parallelism variable called "max_parallel_degree"? Is that a
descriptive name? What does "degree" mean? Why is it not called
"max_parallel_workers"?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so onc
On Fri, Apr 22, 2016 at 11:53:46AM -0400, Robert Haas wrote:
> On Wed, Apr 20, 2016 at 1:32 PM, Magnus Hagander wrote:
> > Note that we have not marked them as deprecated. We're just giving warnings
> > that they will be deprecated.
>
> But I think that is being said here is that maybe they won't
On 04/23/2016 06:33 PM, Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
On 04/23/2016 05:30 PM, Christian Ullrich wrote:
In this case, I would prefer this:
#ifdef WIN32_ONLY_COMPILER
-typedef int pid_t;
+typedef intptr_t pid_t;
#endif
That's a change that will have a pretty wide effect. E
On 2016-04-15 16:53:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
> >> I think the bottom line is that we misdesigned the WAL representation
> >> by assuming that this sort of info could always be piggybacked on a
> >> transaction commit record
On Mon, Feb 15, 2016 at 02:02:41PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > That commit (0d32d2e) permitted things to compile and usually pass tests,
> > but
> > I missed the synchronization bug. Since 2015-10-01, the buildfarm has seen
> > sixteen duplicate-catalog-OID failures.
>
> I'd
On Fri, Apr 22, 2016 at 08:24:53PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Tue, Apr 05, 2016 at 05:50:18PM -0400, Stephen Frost wrote:
> > > Subject: [PATCH 4/5] In pg_dump, include pg_catalog and extension ACLs, if
> > > changed
> > >
> > > Now that all of th
On Fri, Apr 22, 2016 at 12:31:41PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Wed, Apr 20, 2016 at 10:50:21PM -0400, Stephen Frost wrote:
> > > I'm certainly open to improving these issues now if we agree that they
> > > should be fixed for 9.6. If we don't want t
I wrote:
> Andrew Dunstan writes:
>> On 04/23/2016 05:30 PM, Christian Ullrich wrote:
>>> In this case, I would prefer this:
>>>
>>> #ifdef WIN32_ONLY_COMPILER
>>> -typedef int pid_t;
>>> +typedef intptr_t pid_t;
>>> #endif
>> That's a change that will have a pretty wide effect. Everything up to
Andrew Dunstan writes:
> On 04/23/2016 05:30 PM, Christian Ullrich wrote:
>> In this case, I would prefer this:
>>
>> #ifdef WIN32_ONLY_COMPILER
>> -typedef int pid_t;
>> +typedef intptr_t pid_t;
>> #endif
> That's a change that will have a pretty wide effect. Everything up to
> now has been pre
On 04/23/2016 05:30 PM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a
* Andrew Dunstan wrote:
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a process.
pid_t is a typedef for int (in port/win32.
On 04/22/2016 01:21 AM, Michael Paquier wrote:
5. It also complains about us casting a pid_t to a HANDLE in
pg_basebackup.c. Not sure what to do about that.
The thing that's being cast is not a PID, but a HANDLE to a process. pid_t is a
typedef for int (in port/win32.h), therefore is always 3
On Fri, Apr 22, 2016 at 02:03:01PM -0700, Jeff Janes wrote:
> On Thu, Apr 21, 2016 at 11:00 PM, Noah Misch wrote:
> > Could you describe the test case in sufficient detail for Teodor to
> > reproduce
> > your results?
>
> [detailed description and attachments]
Thanks.
> The more I think about
On Thu, Mar 31, 2016 at 05:46:41PM +0200, Emre Hasegeli wrote:
> > Thank you, pushed
>
> Thank you for working on this.
>
> I noticed that have overlooked this:
>
> static RectBox *
> -initRectBox()
> +initRectBox(void)
> {
Done, thanks.
--
Bruce Momjian http://momjian.us
Enter
On Sat, Apr 23, 2016 at 12:48:08PM +0530, Amit Kapila wrote:
> On Sat, Apr 23, 2016 at 8:34 AM, Bruce Momjian wrote:
> >
> > I kind of agreed with Tom about just aborting transactions that held
> > snapshots for too long, and liked the idea this could be set per
> > session, but the idea that we a
Amit Kapila writes:
> The main point for this improvement is that the handling for guc s_s_names
> is not similar to what we do for other somewhat similar guc's and which
> causes in-efficiency in non-hot code path (less used code).
This is not about efficiency, this is about correctness. The pr
On Sat, Apr 23, 2016 at 5:20 PM, Michael Paquier
wrote:
>
> On Sat, Apr 23, 2016 at 7:44 PM, Amit Kapila
wrote:
> > On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI
> > wrote:
> >>
> >>
> >> assign_s_s_names causes SEGV when it is called without calling
> >> check_s_s_names. I think that's no
On Tue, Apr 19, 2016 at 8:41 PM, Kevin Grittner wrote:
>
> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila
wrote:
> > On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund
wrote:
> >>
> >> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> >> > That is more controversial than the potential ~2% regression f
On Sat, Apr 23, 2016 at 7:44 PM, Amit Kapila wrote:
> On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI
> wrote:
>>
>>
>> assign_s_s_names causes SEGV when it is called without calling
>> check_s_s_names. I think that's not the case for this varialbe
>> because it is unresettable amid a session
On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
>
> assign_s_s_names causes SEGV when it is called without calling
> check_s_s_names. I think that's not the case for this varialbe
> because it is unresettable amid a session. It is very uneasy for
> me
On 22/04/16 17:36, Amit Kapila wrote:
On Fri, Apr 22, 2016 at 1:31 AM, Gavin Flower
mailto:gavinflo...@archidevsys.co.nz>>
wrote:
On 22/04/16 06:07, Robert Haas wrote:
On Thu, Apr 21, 2016 at 1:48 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
Robert Haas mailto:robe
On Sat, Apr 23, 2016 at 8:34 AM, Bruce Momjian wrote:
>
> On Tue, Apr 19, 2016 at 07:38:04AM -0400, Robert Haas wrote:
> > 2. Without this feature, you can kill sessions or transactions to
> > control bloat, but this feature is properly thought of as a way to
> > avoid bloat *without* killing sess
25 matches
Mail list logo
