On Mon, Feb 11, 2019 at 10:21 AM Tom Lane wrote:
> Ah, so Andrew was correct: we panicked due to lack of WAL space, and
> that explains why the vacuuming process didn't have an opportunity
> to delete the files belonging to the uncommitted new relation.
> It's a pretty well-understood dynamic, I
Hannes Erven writes:
> Am 10.02.19 um 16:41 schrieb Tom Lane:
>> What do you mean by "crash" exactly?
> Here's the exact log (the pgadmin process was running the VACCUM FULL):
> 2019-02-09 23:44:53.516 CET [20341] @/ <> PANIC: could not write to
> file "pg_wal/xlogtemp.20341": No space left on
On 2/10/19 2:57 PM, auxsvr wrote:
We'd like to configure an RDS server for shared hosting. The idea is that every
customer will be using a different database and FDW will be configured, so that
the remote tables have access to the full data
I've set up something like this before (but on
Hi,
We'd like to configure an RDS server for shared hosting. The idea is that every
customer will be using a different database and FDW will be configured, so that
the remote tables have access to the full data, but materialized views will be
pulling from them data specific to each customer.
Hi again,
Am 10.02.19 um 16:41 schrieb Tom Lane:
Hannes Erven writes:
I've just had a "VACUUM FULL " crash due to 100% disk usage.
Clearly my fault, I was expecting the new table to be small enough.
What do you mean by "crash" exactly? A normal transactional failure
should've cleaned up
Hello Everyone!
We have a 9.2 pg cluster and we are in the process of rebuilding a master
database in our staging environment. In order to achieve the latter goal,
we are restoring our staging database using pg_basebackup against one of
our production replicas.
pg_basebackup has completed and
Hannes Erven writes:
> I've just had a "VACUUM FULL " crash due to 100% disk usage.
> Clearly my fault, I was expecting the new table to be small enough.
What do you mean by "crash" exactly? A normal transactional failure
should've cleaned up orphaned files. I suppose if the kernel decided to
Hi,
I've just had a "VACUUM FULL " crash due to 100% disk usage.
Clearly my fault, I was expecting the new table to be small enough.
After freeing up space, restarting the cluster and issuing another
VACCUM FULL, I noticed that the cluster was way bigger that it should be.
In the base//
