Re: [GENERAL] bloat indexes - opinion

2017-02-25 17:53 GMT+13:00 Patrick B : > > > 2017-02-23 11:46 GMT+13:00 Jeff Janes : > >> On Tue, Feb 21, 2017 at 1:44 PM, Patrick B >> wrote: >> >>> Hi guys, >>> >>> I've got a lot of bloat indexes on my 4TB database. >>>

Re: [GENERAL] bloat indexes - opinion

2017-02-23 11:46 GMT+13:00 Jeff Janes : > On Tue, Feb 21, 2017 at 1:44 PM, Patrick B > wrote: > >> Hi guys, >> >> I've got a lot of bloat indexes on my 4TB database. >> >> Let's take this example: >> >> Table: seg >> Index: ix_filter_by_tree >>

Re: [GENERAL] bloat indexes - opinion

2017-02-22 13:10 GMT+13:00 Adrian Klaver : > On 02/21/2017 03:41 PM, Patrick B wrote: > > 2017-02-22 11:11 GMT+13:00 Patrick B > >: > > > > 2017-02-22 10:59 GMT+13:00 Adrian Klaver

Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

On 2/25/17 at 6:56 AM, Gavin Flower wrote: On 25/02/17 08:39, John McKown wrote: On Fri, Feb 24, 2017 at 1:25 PM, David G. Johnston On Friday, February 24, 2017, Tom Lane wrote: Justin Pryzby writes: Is this expected behavior ? ts=# SELECT x'F'::int; ERROR: 22003: integer out of

Re: [GENERAL] could not translate host name

On 02/24/2017 01:37 PM, Tom Ekberg wrote: I'm running postgres 9.6.2 (also happened on 9.3.14) and have a cron job that runs hourly that runs a program that does mostly postgres SELECTs on a different host. Occasionally I get email (not hourly) from the cron daemon that contains a stack trace

Re: [GENERAL] could not translate host name

On 2/24/2017 1:37 PM, Tom Ekberg wrote: I'm running postgres 9.6.2 (also happened on 9.3.14) and have a cron job that runs hourly that runs a program that does mostly postgres SELECTs on a different host. Occasionally I get email (not hourly) from the cron daemon that contains a stack trace

Re: [GENERAL] could not translate host name

> On Feb 24, 2017, at 1:37 PM, Tom Ekberg wrote: > > I'm running postgres 9.6.2 (also happened on 9.3.14) and have a cron job that > runs hourly that runs a program that does mostly postgres SELECTs on a > different host. Occasionally I get email (not hourly) from the cron

[GENERAL] could not translate host name

I'm running postgres 9.6.2 (also happened on 9.3.14) and have a cron job that runs hourly that runs a program that does mostly postgres SELECTs on a different host. Occasionally I get email (not hourly) from the cron daemon that contains a stack trace that ends with this:

Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

On 25/02/17 08:39, John McKown wrote: On Fri, Feb 24, 2017 at 1:25 PM, David G. Johnston >wrote: On Friday, February 24, 2017, Tom Lane > wrote: Justin Pryzby

Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

On Fri, Feb 24, 2017 at 1:25 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Friday, February 24, 2017, Tom Lane wrote: > >> Justin Pryzby writes: >> > Is this expected behavior ? >> > ts=# SELECT x'F'::int; >> >

Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

On Friday, February 24, 2017, Tom Lane wrote: > Justin Pryzby > writes: > > Is this expected behavior ? > > ts=# SELECT x'F'::int; > > ERROR: 22003: integer out of range > > LOCATION: bittoint4, varbit.c:1575 > >

Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

On Fri, Feb 24, 2017 at 2:13 PM, Tom Lane wrote: > Justin Pryzby writes: > > Is this expected behavior ? > > ts=# SELECT x'F'::int; > > ERROR: 22003: integer out of range > > LOCATION: bittoint4, varbit.c:1575 > > Yes. The

Re: [GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

Justin Pryzby writes: > Is this expected behavior ? > ts=# SELECT x'F'::int; > ERROR: 22003: integer out of range > LOCATION: bittoint4, varbit.c:1575 Yes. The provided operation is "convert a bitstring of up to 32 bits to an integer". It's not

[GENERAL] SELECT x'00000000F'::int leading zeros causes "integer out of range"

Is this expected behavior ? This works: ts=# SELECT x'000F'::int; int4|15 .. but an additional leading zero causes it to fail: ts=# SELECT x'F'::int; ERROR: 22003: integer out of range LOCATION: bittoint4, varbit.c:1575 |/* Check that the

Re: [GENERAL] Postgres HA

Julyanto Sutandang wrote: > Talking about High Availability, we should understand the basic concept of > HA, it is avoiding SPOF (Single Point of Failure). When we use a Loadbalancer > (LTM) and that load balancer is single, then you may get HA only for the > PostgreSQL but

[GENERAL] echo

Excuse me... I was not receiving email from the list in the last 12 hours just to check.. Thanks -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general