On Thu, Jan 13, 2005 at 07:11:09PM +0100, Martijn van Oosterhout wrote:
>
> Wouldn't the transaction ID be more useful. An earlier transaction ID
> obviously started earlier. So you should be able to identify the oldest
> transaction. Would the transaction ID field in pg_locks do?
That'll show wh
On Thursday January 13 2005 11:37, Michael Fuhr wrote:
>
> That'll show which transaction is oldest but not how long it's been
> open or idle, i.e., whether it's "long-open" or not. I assumed,
> perhaps incorrectly, that he was already looking at pg_locks and
> wanted to find out which of those tr
On Thu, Jan 13, 2005 at 10:33:50AM -0700, Ed L. wrote:
> On Thursday January 13 2005 10:09, Michael Fuhr wrote:
> >
> > For idle transactions pg_stat_activity shows " in transaction"
> > and the query_start column shows when the transaction became idle
>
> That will help, thanks. Unfortunately, th
On Thu, Jan 13, 2005 at 12:04:28PM -0700, Ed L. wrote:
> It'd be nice if pg_stat_activity.transaction_start were added in the future
> for a 100% answer, but I'm not sure there's much interest in this apart
> from our needs.
I wouldn't expect that to be hard to add. Consider submitting a
patch
On Thu, Jan 13, 2005 at 08:44:56AM -0700, Ed L. wrote:
> Yes, I see that in 7.4 (not in 7.3). But my purpose would be to remotely
> identify long-open transactions that are causing table bloat by making
> vacuum fail to reclaim space, so it seems I need the transaction start
> time, not query s
On Thu, Jan 13, 2005 at 09:50:38AM -0300, Alvaro Herrera wrote:
> On Wed, Jan 12, 2005 at 11:30:50PM -0700, Michael Fuhr wrote:
> >
> > I'm not aware of a way to find out when a transaction started, but
> > if you have stats_command_string enabled then you can query
> > pg_stat_activity to see when
On Thu, Jan 13, 2005 at 08:44:56AM -0700, Ed L. wrote:
> On Wednesday January 12 2005 11:30, Michael Fuhr wrote:
> >
> > I'm not aware of a way to find out when a transaction started, but
> > if you have stats_command_string enabled then you can query
> > pg_stat_activity to see when a session's cu
On Thursday January 13 2005 10:09, Michael Fuhr wrote:
>
> For idle transactions pg_stat_activity shows " in transaction"
> and the query_start column shows when the transaction became idle
> (i.e., when the last statement completed). So if long-lived idle
> transactions are the problem, then at l
On Thursday January 13 2005 5:50, Alvaro Herrera wrote:
> On Wed, Jan 12, 2005 at 11:30:50PM -0700, Michael Fuhr wrote:
> > On Wed, Jan 12, 2005 at 11:49:12AM -0700, Ed L. wrote:
> > > Is it possible via SQL query to tell how long a transaction has been
> > > open?
> >
> > I'm not aware of a way to
On Wednesday January 12 2005 11:30, Michael Fuhr wrote:
> On Wed, Jan 12, 2005 at 11:49:12AM -0700, Ed L. wrote:
> > Is it possible via SQL query to tell how long a transaction has been
> > open?
>
> I'm not aware of a way to find out when a transaction started, but
> if you have stats_command_stri
On Thu, Jan 13, 2005 at 08:45:38AM -0700, Ed L. wrote:
> On Thursday January 13 2005 5:50, Alvaro Herrera wrote:
> > On Wed, Jan 12, 2005 at 11:30:50PM -0700, Michael Fuhr wrote:
> > > On Wed, Jan 12, 2005 at 11:49:12AM -0700, Ed L. wrote:
> > > > Is it possible via SQL query to tell how long a tra
On Wed, Jan 12, 2005 at 11:30:50PM -0700, Michael Fuhr wrote:
> On Wed, Jan 12, 2005 at 11:49:12AM -0700, Ed L. wrote:
> >
> > Is it possible via SQL query to tell how long a transaction has been open?
>
> I'm not aware of a way to find out when a transaction started, but
> if you have stats_comm
On Wed, Jan 12, 2005 at 11:49:12AM -0700, Ed L. wrote:
>
> Is it possible via SQL query to tell how long a transaction has been open?
I'm not aware of a way to find out when a transaction started, but
if you have stats_command_string enabled then you can query
pg_stat_activity to see when a sessi
On Wednesday January 12 2005 11:10, Scott Marlowe wrote:
>
> I believe the problem is occurring if the open transaction is older than
> the tuples that could be vacuumed. The MVCC system means that as long
> as a transaction that started X hours ago is still open, the tuples that
> have been freed
On Wed, 2005-01-12 at 11:59, Ed L. wrote:
> I'm looking at some 7.3.4 vacuum output, and at first glance it does not
> appear that vacuum is reclaiming any dead tuple space if there is even a
> single open transaction, even if the open transaction does not in any way
> reference the table being
I'm looking at some 7.3.4 vacuum output, and at first glance it does not
appear that vacuum is reclaiming any dead tuple space if there is even a
single open transaction, even if the open transaction does not in any way
reference the table being vacuumed. Is that correct? Is the behavior
dif
16 matches
Mail list logo