Fix busy-wait in pgbench, with --rate.
If --rate was used to throttle pgbench, it failed to sleep when it had
nothing to do, leading to a busy-wait with 100% CPU usage. This bug was
introduced in the refactoring in v10. Before that, sleep() was called with
a timeout, even when there were no file d
Fix busy-wait in pgbench, with --rate.
If --rate was used to throttle pgbench, it failed to sleep when it had
nothing to do, leading to a busy-wait with 100% CPU usage. This bug was
introduced in the refactoring in v10. Before that, sleep() was called with
a timeout, even when there were no file d
Hi,
On 2017-09-30 22:28:39 -0400, Andrew Dunstan wrote:
> >> But even after fixing that, there unfortunately is:
> >>
> >> static void
> >> set_sig(char *signame)
> >> {
> >> …
> >> #if 0
> >>/* probably should NOT provide SIGKILL */
> >>else if (strcmp(signame, "KILL") == 0)
> >>
On 09/30/2017 06:44 PM, Andres Freund wrote:
> On 2017-09-30 15:27:12 -0700, Andres Freund wrote:
>> On 2017-09-30 18:21:33 -0400, Andrew Dunstan wrote:
>>> [re-adding commiters which I inadvertently left off]
>>>
>>>
>>> On 09/30/2017 06:10 PM, Andres Freund wrote:
> I was just looking
On 2017-09-30 15:27:12 -0700, Andres Freund wrote:
> On 2017-09-30 18:21:33 -0400, Andrew Dunstan wrote:
> >
> > [re-adding commiters which I inadvertently left off]
> >
> >
> > On 09/30/2017 06:10 PM, Andres Freund wrote:
> > >
> > >
> > >> I was just looking at this. Why aren't we using "pg_ct
On 2017-09-30 18:21:33 -0400, Andrew Dunstan wrote:
>
> [re-adding commiters which I inadvertently left off]
>
>
> On 09/30/2017 06:10 PM, Andres Freund wrote:
> >
> >
> >> I was just looking at this. Why aren't we using "pg_ctl kill" to
> >> terminate the backend? That's supposed to be portable
[re-adding commiters which I inadvertently left off]
On 09/30/2017 06:10 PM, Andres Freund wrote:
>
>
>> I was just looking at this. Why aren't we using "pg_ctl kill" to
>> terminate the backend? That's supposed to be portable.
> Because pg_ctl can't do that for any process but postmaster, no? T
Fix pg_dump to assign domain array type OIDs during pg_upgrade.
During a binary upgrade, all type OIDs are supposed to be assigned by
pg_dump based on their values in the old cluster. But now that domains
have arrays, there's nothing to base the arrays' type OIDs on, if we're
upgrading from a pre
On 09/30/2017 03:32 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> We seem to have caused a problem with pg_upgrade :-(
>> pg_restore: [archiver (db)] could not execute query: ERROR: pg_type
>> array OID value not set when in binary upgrade mode
>> Here we're upgrading from 9.2 to HEAD
Andrew Dunstan writes:
> We seem to have caused a problem with pg_upgrade :-(
> pg_restore: [archiver (db)] could not execute query: ERROR: pg_type
> array OID value not set when in binary upgrade mode
> Here we're upgrading from 9.2 to HEAD. Of course, there isn't an array
> oid for th
On 09/30/2017 01:41 PM, Tom Lane wrote:
> Support arrays over domains.
We seem to have caused a problem with pg_upgrade :-(
The failing log file is:
command: "/home/bf/bfr/root/upgrade/HEAD/inst/bin/pg_restore" --host
/home/bf/bfr/root/upgrade/HEAD/inst --port 5648 --username buildfar
Support arrays over domains.
Allowing arrays with a domain type as their element type was left un-done
in the original domain patch, but not for any very good reason. This
omission leads to such surprising results as array_agg() not working on
a domain column, because the parser can't identify a
Andres Freund writes:
> On 2017-09-30 12:17:06 -0400, Tom Lane wrote:
>> c.h will already have included . There might be some
>> value in this if we anticipated allowing freestanding use of this
>> header, but that won't happen because it depends on configure symbols.
> Well, it's not that obvio
On 2017-09-30 12:17:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Extend & revamp pg_bswap.h infrastructure.
>
> Hm, what is the point of this in pg_bswap.h:
>
> +#ifdef _MSC_VER
> +#include
> +#endif
>
> c.h will already have included . There might be some
> value in this if we antic
Andres Freund writes:
> Extend & revamp pg_bswap.h infrastructure.
Hm, what is the point of this in pg_bswap.h:
+#ifdef _MSC_VER
+#include
+#endif
c.h will already have included . There might be some
value in this if we anticipated allowing freestanding use of this
header, but that won't happ
15 matches
Mail list logo
