pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedDiagnosing a massive toast file
12+ messages / 5 participants
[nested] [flat]
* Diagnosing a massive toast file
@ 2019-08-05 16:32 Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Wells Oliver @ 2019-08-05 16:32 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
Hi all, I have not seen this before, but one our toast tables has gotten to
15GB, the biggest table in the DB. I don't know why, is there some way I
can diagnose what's causing this?
I don't think I've ever seen a toast table even half of this size, so it's
concerning.
--
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 16:36 ` Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Ron @ 2019-08-05 16:36 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
On 8/5/19 11:32 AM, Wells Oliver wrote:
> Hi all, I have not seen this before, but one our toast tables has gotten
> to 15GB, the biggest table in the DB. I don't know why, is there some way
> I can diagnose what's causing this?
>
> I don't think I've ever seen a toast table even half of this size, so
> it's concerning.
We've got *lots* of toast tables that big. Are you asking how to find the
"human readable name" associated with the toast table?
And have you vacuumed it lately?
--
Angular momentum makes the world go 'round.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
@ 2019-08-05 16:37 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: Wells Oliver @ 2019-08-05 16:37 UTC (permalink / raw)
To: Ron <ronljohnsonjr@gmail.com>; +Cc: pgsql-admin@lists.postgresql.org
Yeah, trying to figure out what actual table is clearly in need of a vacuum
b/c of the size of that toast table.
On Mon, Aug 5, 2019 at 9:36 AM Ron <ronljohnsonjr@gmail.com> wrote:
> On 8/5/19 11:32 AM, Wells Oliver wrote:
>
> Hi all, I have not seen this before, but one our toast tables has gotten
> to 15GB, the biggest table in the DB. I don't know why, is there some way I
> can diagnose what's causing this?
>
> I don't think I've ever seen a toast table even half of this size, so
> it's concerning.
>
>
> We've got *lots* of toast tables that big. Are you asking how to find
> the "human readable name" associated with the toast table?
>
> And have you vacuumed it lately?
>
> --
> Angular momentum makes the world go 'round.
>
--
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 16:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2019-08-05 16:49 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; +Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
Wells Oliver <wells.oliver@gmail.com> writes:
> Yeah, trying to figure out what actual table is clearly in need of a vacuum
> b/c of the size of that toast table.
Something like
select relname from pg_class
where reltoastrelid = 'pg_toast.pg_toast_NNN'::regclass;
(or, if you have potential duplicate relnames, select oid::regclass ...)
The mere fact that it's big does not indicate a problem, though.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-08-05 17:00 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Wells Oliver @ 2019-08-05 17:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
Appreciate it, guys. I understand it being large isn't itself a problem,
but relative to history and the lack of real changes, it's just strange and
I'd like to better understand what is going on...
I tracked it down to a specific table, and then doing a VACUUM FULL ANALYZE
on that table yields: 108765 dead row versions cannot be removed yet.
Which strikes me as odd. Any reading I can do to better understand why so
many (relative to the overall table size) dead rows cannot be removed?
On Mon, Aug 5, 2019 at 9:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Wells Oliver <wells.oliver@gmail.com> writes:
> > Yeah, trying to figure out what actual table is clearly in need of a
> vacuum
> > b/c of the size of that toast table.
>
> Something like
>
> select relname from pg_class
> where reltoastrelid = 'pg_toast.pg_toast_NNN'::regclass;
>
> (or, if you have potential duplicate relnames, select oid::regclass ...)
>
> The mere fact that it's big does not indicate a problem, though.
>
> regards, tom lane
>
--
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 17:03 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:20 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 17:24 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 12+ messages in thread
From: Wells Oliver @ 2019-08-05 17:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table is
7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.
Why can't I free those rows up?
On Mon, Aug 5, 2019 at 10:00 AM Wells Oliver <wells.oliver@gmail.com> wrote:
> Appreciate it, guys. I understand it being large isn't itself a problem,
> but relative to history and the lack of real changes, it's just strange and
> I'd like to better understand what is going on...
>
> I tracked it down to a specific table, and then doing a VACUUM FULL
> ANALYZE on that table yields: 108765 dead row versions cannot be removed
> yet.
>
> Which strikes me as odd. Any reading I can do to better understand why so
> many (relative to the overall table size) dead rows cannot be removed?
>
>
> On Mon, Aug 5, 2019 at 9:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Wells Oliver <wells.oliver@gmail.com> writes:
>> > Yeah, trying to figure out what actual table is clearly in need of a
>> vacuum
>> > b/c of the size of that toast table.
>>
>> Something like
>>
>> select relname from pg_class
>> where reltoastrelid = 'pg_toast.pg_toast_NNN'::regclass;
>>
>> (or, if you have potential duplicate relnames, select oid::regclass ...)
>>
>> The mere fact that it's big does not indicate a problem, though.
>>
>> regards, tom lane
>>
>
>
> --
> Wells Oliver
> wells.oliver@gmail.com <wellsoliver@gmail.com>
>
--
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 17:20 ` Ron <ronljohnsonjr@gmail.com>
1 sibling, 0 replies; 12+ messages in thread
From: Ron @ 2019-08-05 17:20 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
"An open transaction" is the first place to look.
On 8/5/19 12:03 PM, Wells Oliver wrote:
> As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table is
> 7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.
>
> Why can't I free those rows up?
>
> On Mon, Aug 5, 2019 at 10:00 AM Wells Oliver <wells.oliver@gmail.com
> <mailto:wells.oliver@gmail.com>> wrote:
>
> Appreciate it, guys. I understand it being large isn't itself a
> problem, but relative to history and the lack of real changes, it's
> just strange and I'd like to better understand what is going on...
>
> I tracked it down to a specific table, and then doing a VACUUM FULL
> ANALYZE on that table yields: 108765 dead row versions cannot be
> removed yet.
>
> Which strikes me as odd. Any reading I can do to better understand why
> so many (relative to the overall table size) dead rows cannot be removed?
>
>
> On Mon, Aug 5, 2019 at 9:49 AM Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
> Wells Oliver <wells.oliver@gmail.com
> <mailto:wells.oliver@gmail.com>> writes:
> > Yeah, trying to figure out what actual table is clearly in need
> of a vacuum
> > b/c of the size of that toast table.
>
> Something like
>
> select relname from pg_class
> where reltoastrelid = 'pg_toast.pg_toast_NNN'::regclass;
>
> (or, if you have potential duplicate relnames, select
> oid::regclass ...)
>
> The mere fact that it's big does not indicate a problem, though.
>
> regards, tom lane
>
>
>
> --
> Wells Oliver
> wells.oliver@gmail.com <mailto:wellsoliver@gmail.com>
>
>
>
> --
> Wells Oliver
> wells.oliver@gmail.com <mailto:wellsoliver@gmail.com>
--
Angular momentum makes the world go 'round.
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 17:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:43 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
1 sibling, 1 reply; 12+ messages in thread
From: Tom Lane @ 2019-08-05 17:24 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; +Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
Wells Oliver <wells.oliver@gmail.com> writes:
> As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table is
> 7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.
> Why can't I free those rows up?
Old open transaction somewhere (possibly a prepared transaction?).
Or a replication slot that's holding back the xmin horizon due to
not keeping up.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:24 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-08-05 17:43 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:48 ` Re: Diagnosing a massive toast file Avinash Kumar <avinash.vallarapu@gmail.com>
2019-08-05 18:31 ` RE: Diagnosing a massive toast file Igor Neyman <ineyman@perceptron.com>
0 siblings, 2 replies; 12+ messages in thread
From: Wells Oliver @ 2019-08-05 17:43 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
Thanks, that was it exactly. PGAdmin session opened for a week. Argh. Gotta
have some conversations with some folks.
Do you guys have any kind of regular monitoring in place to flag users who
don't politely close their connections?
On Mon, Aug 5, 2019 at 10:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Wells Oliver <wells.oliver@gmail.com> writes:
> > As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table
> is
> > 7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.
>
> > Why can't I free those rows up?
>
> Old open transaction somewhere (possibly a prepared transaction?).
> Or a replication slot that's holding back the xmin horizon due to
> not keeping up.
>
> regards, tom lane
>
--
Wells Oliver
wells.oliver@gmail.com <wellsoliver@gmail.com>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:24 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:43 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 17:48 ` Avinash Kumar <avinash.vallarapu@gmail.com>
1 sibling, 0 replies; 12+ messages in thread
From: Avinash Kumar @ 2019-08-05 17:48 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
On Mon, Aug 5, 2019 at 2:43 PM Wells Oliver <wells.oliver@gmail.com> wrote:
> Thanks, that was it exactly. PGAdmin session opened for a week. Argh.
> Gotta have some conversations with some folks.
>
> Do you guys have any kind of regular monitoring in place to flag users who
> don't politely close their connections?
>
pg_stat_activity <https://www.postgresql.org/docs/11/monitoring-stats.html;
view would do the trick for you.
Search for the connections that are running long for more than a few hours
? or days ?
See if any idle in transactions that have now() - state_change, more than a
few mins ? or hours ? or days ?
>
>
> On Mon, Aug 5, 2019 at 10:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Wells Oliver <wells.oliver@gmail.com> writes:
>> > As a follow up, n_dead_tup from pg_stat_sys_tables for this TOAST table
>> is
>> > 7447444, live tuples, 623982, and tup_del 20823469. vacuum_count is 0.
>>
>> > Why can't I free those rows up?
>>
>> Old open transaction somewhere (possibly a prepared transaction?).
>> Or a replication slot that's holding back the xmin horizon due to
>> not keeping up.
>>
>> regards, tom lane
>>
>
>
> --
> Wells Oliver
> wells.oliver@gmail.com <wellsoliver@gmail.com>
>
--
9000799060
^ permalink raw reply [nested|flat] 12+ messages in thread
* RE: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:24 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:43 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
@ 2019-08-05 18:31 ` Igor Neyman <ineyman@perceptron.com>
2019-08-05 18:35 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 12+ messages in thread
From: Igor Neyman @ 2019-08-05 18:31 UTC (permalink / raw)
To: Wells Oliver <wells.oliver@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
From: Wells Oliver [mailto:wells.oliver@gmail.com]
Sent: Monday, August 05, 2019 1:43 PM
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org
Subject: Re: Diagnosing a massive toast file
Thanks, that was it exactly. PGAdmin session opened for a week. Argh. Gotta have some conversations with some folks.
Do you guys have any kind of regular monitoring in place to flag users who don't politely close their connections?
--
Wells Oliver
wells.oliver@gmail.com<mailto:wellsoliver@gmail.com>
idle_in_transaction_session_timeout GUC is your friend.
Read on it in the docs.
Regards,
Igor Neyman
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Diagnosing a massive toast file
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Re: Diagnosing a massive toast file Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:24 ` Re: Diagnosing a massive toast file Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:43 ` Re: Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 18:31 ` RE: Diagnosing a massive toast file Igor Neyman <ineyman@perceptron.com>
@ 2019-08-05 18:35 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2019-08-05 18:35 UTC (permalink / raw)
To: Igor Neyman <ineyman@perceptron.com>; +Cc: Wells Oliver <wells.oliver@gmail.com>; Ron <ronljohnsonjr@gmail.com>; pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Igor Neyman <ineyman@perceptron.com> writes:
> From: Wells Oliver [mailto:wells.oliver@gmail.com]
>> Do you guys have any kind of regular monitoring in place to flag users who don't politely close their connections?
> idle_in_transaction_session_timeout GUC is your friend.
Good idea, though it's only been around since 9.6.
Also, if you just want to monitor rather than impose a hard limit,
I imagine you can get Nagios to watch for this.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2019-08-05 18:35 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-08-05 16:32 Diagnosing a massive toast file Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:36 ` Ron <ronljohnsonjr@gmail.com>
2019-08-05 16:37 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 16:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:00 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:03 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:20 ` Ron <ronljohnsonjr@gmail.com>
2019-08-05 17:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-08-05 17:43 ` Wells Oliver <wells.oliver@gmail.com>
2019-08-05 17:48 ` Avinash Kumar <avinash.vallarapu@gmail.com>
2019-08-05 18:31 ` Igor Neyman <ineyman@perceptron.com>
2019-08-05 18:35 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox