es as I can't imagine the query tool doing something other than
querying the database for specs. I think it looks at the PID. This very
well might be a PgAdmin issue and have nothing to do with postgres.
~Ben
On Fri, Jun 15, 2012 at 4:00 PM, Kevin Grittner wrote:
> Benedict Holland wr
I see! Thank you very much!
~Ben
On Fri, Jun 15, 2012 at 3:51 PM, Kevin Grittner wrote:
> Benedict Holland wrote:
>
> > I can even accept the use case that the select should block with
> > an Alter Table operation if data is retrieved from the table, but
> > a select c
a
finish only. This should not block or be blocked on anything. The where
clause, a group by or a distinct clause etc. should block on an Alter
table. Is this just an edge case which is not worth looking at?
Thank you so much for your help.
~Ben
On Fri, Jun 15, 2012 at 3:32 PM, Kevin Grittner w
For kicks I stopped the full vacuum and the status of the remaining
processes has not changed. The select count(*) is still blocked by the
update.
~Ben
On Fri, Jun 15, 2012 at 3:12 PM, Benedict Holland <
benedict.m.holl...@gmail.com> wrote:
> Yes. I needed to do a full vacuum. A
also don't understand why a select count(*) requires an
AccessShareLock. I don't understand why a select should lock anything at
all.
~Ben
On Fri, Jun 15, 2012 at 3:03 PM, Kevin Grittner wrote:
> Benedict Holland wrote:
>
> > 10:25:08.329-04vacuum (analyze, verbose, ful
. The
dates are the start time of the operations. The YES/NO is the running state
of the process. In the activity section the 2nd to last column is the
process blocking the executing process.
Thanks,
~Ben
On Fri, Jun 15, 2012 at 2:54 PM, Kevin Grittner wrote:
> Benedict Holland wrote:
> &g
PM, Benedict Holland <
benedict.m.holl...@gmail.com> wrote:
> Yes I actually seem to have two of them for the single update. The update
> I am running will set the value of a single column in the table without a
> where clause. I actually have two AccessShareLock's, two Exclus
n 15, 2012 at 2:43 PM, Kevin Grittner wrote:
> Peter Geoghegan wrote:
> > Benedict Holland wrote:
> >> Do I seem to have this right and is there anything I can do?
> >
> > There are a couple of maintenance operations that could block a
> > select. D
Hi all,
I am using postgresql 9.0 and I am updating a large table and running a
select count(*). The update is run first and then the select. The update is
blocking the select statement. To use the term MVCC (as seems to be done so
much in this list), well it seems to be broken. MVCC should allow
