On 2018-May-23, Tom Lane wrote:
> Tiffany Thang writes:
> > Where do I find pg_controldata? I could not locate it on the file system.
>
> Hmm, should be one of the installed PG executables.
>
> > pg_clog/ or pg_subtrans/ or pg_multixact/offsets/ are getting larger too
> > but by only a few hun
Tiffany Thang writes:
> Where do I find pg_controldata? I could not locate it on the file system.
Hmm, should be one of the installed PG executables.
> pg_clog/ or pg_subtrans/ or pg_multixact/offsets/ are getting larger too
> but by only a few hundreds MBs.
This is consistent with the idea th
Thanks Tom and Thomas.
Where do I find pg_controldata? I could not locate it on the file system.
pg_clog/ or pg_subtrans/ or pg_multixact/offsets/ are getting larger too
but by only a few hundreds MBs.
This is not a replicated system.
How do I tell if a system is aggressively running "wraparou
On Wed, May 23, 2018 at 7:49 AM, Tom Lane wrote:
> Tiffany Thang writes:
>> Our pg_multixact/members directory has been growing to more than 18GB over
>> the last couple of months. According to the documentation, the files in
>> there are used to support row locking by multiple transactions and w
Tiffany Thang writes:
> Our pg_multixact/members directory has been growing to more than 18GB over
> the last couple of months. According to the documentation, the files in
> there are used to support row locking by multiple transactions and when all
> tables in all databases are eventually scanne
Hi,
Our pg_multixact/members directory has been growing to more than 18GB over
the last couple of months. According to the documentation, the files in
there are used to support row locking by multiple transactions and when all
tables in all databases are eventually scanned by VACUUM, the older
mult
