On Fri, 2010-11-26 at 01:11 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
That would mean running GetCurrentTransactionId() inside LockAcquire()
if (lockmode = AccessExclusiveLock
locktag-locktag_type == LOCKTAG_RELATION
!RecoveryInProgress())
(void)
On Fri, 2010-11-26 at 18:35 -0500, Tom Lane wrote:
Speaking of which, is there any code in there to ensure that a
deadlock
in the standby is resolved by killing HS queries and not the replay
process? Because deadlocks are certainly going to be possible no
matter
what.
Locks cause query
On Fri, Nov 26, 2010 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In fact, now that I think about it, what I'm proposing would actually
substantially REDUCE the risk of deadlock on the standby, because the
master would only ever need to lock a backing file long enough to drop
or truncate it,
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
That would mean running GetCurrentTransactionId() inside LockAcquire()
if (lockmode = AccessExclusiveLock
locktag-locktag_type == LOCKTAG_RELATION
!RecoveryInProgress())
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
That would mean running GetCurrentTransactionId() inside LockAcquire()
if (lockmode = AccessExclusiveLock
On Fri, Nov 26, 2010 at 7:41 AM, Andres Freund and...@anarazel.de wrote:
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
That would mean running GetCurrentTransactionId()
On Fri, 2010-11-26 at 11:19 +0900, Fujii Masao wrote:
On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
As to solutions, it cannot be acceptable to ignore some locks just
because an xid has not been assigned.
Even if GetRunningTransactionLocks ignores such a lock,
On 26.11.2010 17:28, Robert Haas wrote:
On Fri, Nov 26, 2010 at 7:41 AM, Andres Freundand...@anarazel.de wrote:
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Simon Riggssi...@2ndquadrant.com writes:
That would
On Fri, 2010-11-26 at 17:53 +0200, Heikki Linnakangas wrote:
Hmm,
looking at the code, we also allow RowShareLock and RowExclusiveLock
in
the standby. You can't actually insert/update/delete tuples or set
xmax
as SELECT FOR SHARE does on standby, though, so why do we allow that?
It was
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Incidentally, I haven't been able to wrap my head around why we need
to propagate AccessExclusiveLocks to the standby in the first place.
Can someone explain?
To make the standby stop applying WAL
On 26.11.2010 20:17, Robert Haas wrote:
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If you have operation A in the master that currently acquires an
AccessExclusiveLock on a table, do you think it's safe for another
transaction to peek at the
On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
As a concrete example, VACUUM acquires an AccessExclusiveLock when it
wants
to truncate the relation. A sequential scan running against the table in
the
standby will get upset, if the startup
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If you go down that path, you're going to spend a lot of time thinking
through every single case that uses an AccessExclusiveLock, ensuring that
the standby
On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If you go down that path, you're going to spend a lot of time thinking
through every
Robert Haas robertmh...@gmail.com writes:
On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think it's not only useless from a performance standpoint, but
probably actually dangerous, to not take AccessExclusiveLock on the
standby when it's taken on the master.
As far as
On Wed, Nov 24, 2010 at 1:27 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01303.php
When I did unusual operations (e.g., suspend bgwriter by gdb,
pgbench -i and issue txid_current many times) on the master
in order to try to
On Thu, 2010-11-25 at 16:59 +0900, Fujii Masao wrote:
To solve the problem, ISTM that XID should be assigned before the
information about AccessExclusive lock becomes visible to another
process. Or CHECKPOINT (i.e., GetRunningTransactionLocks) should
ignore the locks with XID = 0.
First,
On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
As to solutions, it cannot be acceptable to ignore some locks just
because an xid has not been assigned.
Even if GetRunningTransactionLocks ignores such a lock, it's eventually
WAL-logged by LogAccessExclusiveLock, isn't
Simon Riggs si...@2ndquadrant.com writes:
That would mean running GetCurrentTransactionId() inside LockAcquire()
if (lockmode = AccessExclusiveLock
locktag-locktag_type == LOCKTAG_RELATION
!RecoveryInProgress())
(void) GetCurrentTransactionId();
Any objections to that fix?
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01303.php
When I did unusual operations (e.g., suspend bgwriter by gdb,
pgbench -i and issue txid_current many times) on the master
in order to try to reproduce the above HS error, I encountered
the following assertion error.
Since I
20 matches
Mail list logo
