> 6) Failovers, at least in Aurora, apparently cause pg_stat_reset() to be
> run, at least judging by the timestamp I'm seeing in
> pg_stat_bgwriter.stat_reset. We haven't done a failover in the data center in
> a while, and it's less trivial for me to test there atm, so I'm not certain
> whe
On 4/13/19 7:28 PM, Schneider, Jeremy wrote:
On Apr 11, 2019, at 19:52, Tom Lane wrote:
Ron writes:
I bet requests like this will start to make it onto the beaten path.
Meh. I'm not that excited about inventing our own versions of wheels
that already exist, especially when there's nothing v
Pushover.net comes to mind.
The email sending should not delay login.
If you want notifications, look at mqtt.
https://dan.langille.org/2018/04/15/using-mtqq-to-create-a-notification-network-mosquitto-mqttwarn-hare-and-hared/
Lightweight, non-pausing solution.
HTH
--
Dan Langille
d...@
> On Apr 13, 2019, at 17:28, Schneider, Jeremy wrote:
>
>> On Apr 11, 2019, at 19:52, Tom Lane wrote:
>>
>> Ron writes:
>>> I bet requests like this will start to make it onto the beaten path.
>>
>> Meh. I'm not that excited about inventing our own versions of wheels
>> that already exist,
> On Apr 11, 2019, at 19:52, Tom Lane wrote:
>
> Ron writes:
>> I bet requests like this will start to make it onto the beaten path.
>
> Meh. I'm not that excited about inventing our own versions of wheels
> that already exist, especially when there's nothing very Postgres-specific
> about th
I did it in pgadmin, without begin commit.
On Sat, Apr 13, 2019 at 4:24 PM Adrian Klaver
wrote:
> On 4/13/19 7:10 AM, Paul van der Linden wrote:
> > It was just 99 files of 1GB each for each id, and no I didn't vacuum.
> > I did see disk usage dropping quite a lot after dropping those tables
>
It was just 99 files of 1GB each for each id, and no I didn't vacuum.
I did see disk usage dropping quite a lot after dropping those tables
though, so I expected postgres to delete all unneccesary files for all the
tables.
However when checking just now I saw that the files I was referring to were
On 4/13/19 7:10 AM, Paul van der Linden wrote:
It was just 99 files of 1GB each for each id, and no I didn't vacuum.
I did see disk usage dropping quite a lot after dropping those tables
though, so I expected postgres to delete all unneccesary files for all
the tables.
However when checking j
Am 13.04.19 um 11:22 schrieb Nithin Johnson:
We are seeing this intermittent problem after we upgrade (using
pg_upgrade) from postgres 9.3.12 to 9.6.12
Querying few of the rows in the table using a TEXT field is failing.
sounds like a corrupt index, can you show us the complete error m
We are seeing this intermittent problem after we upgrade (using pg_upgrade)
from postgres 9.3.12 to 9.6.12
Querying few of the rows in the table using a TEXT field is failing.
The following query fails:
SELECT * from table where jobid = 'foo';
Whereas the following is passing:
SELECT * from tab
10 matches
Mail list logo
