On Fri, 2010-11-26 at 01:11 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > That would mean running GetCurrentTransactionId() inside LockAcquire()
>
> > if (lockmode >= AccessExclusiveLock &&
> > locktag->locktag_type == LOCKTAG_RELATION &&
> > !RecoveryInProgress())
> > (void) GetCu
On Fri, Nov 26, 2010 at 7:27 PM, Tom Lane 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, whereas un
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 que
Robert Haas writes:
> On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane 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 I can see, that's complete nonse
On Fri, Nov 26, 2010 at 6:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
>> 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
Robert Haas writes:
> On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
> 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 has enough information, and tinkering with the r
On Fri, Nov 26, 2010 at 2:06 PM, Heikki Linnakangas
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 process replays a truncatio
On 26.11.2010 20:17, Robert Haas wrote:
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
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 table at the same time?
Beep, tim
On Fri, Nov 26, 2010 at 10:53 AM, Heikki Linnakangas
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 when a local trans
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
On 26.11.2010 17:28, Robert Haas wrote:
On Fri, Nov 26, 2010 at 7:41 AM, Andres Freund wrote:
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
Simon Riggs writes:
That would mean running GetCurrentTransactionId() inside LockAcquire()
On Fri, 2010-11-26 at 11:19 +0900, Fujii Masao wrote:
> On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs 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
On Fri, Nov 26, 2010 at 7:41 AM, Andres Freund wrote:
> On Friday 26 November 2010 13:32:18 Robert Haas wrote:
>> On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
>> > Simon Riggs writes:
>> >> That would mean running GetCurrentTransactionId() inside LockAcquire()
>> >>
>> >> if (lockmode >= Acc
On Friday 26 November 2010 13:32:18 Robert Haas wrote:
> On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> That would mean running GetCurrentTransactionId() inside LockAcquire()
> >>
> >> if (lockmode >= AccessExclusiveLock &&
> >> locktag->locktag_type == LOCKTAG
On Fri, Nov 26, 2010 at 1:11 AM, Tom Lane wrote:
> Simon Riggs writes:
>> That would mean running GetCurrentTransactionId() inside LockAcquire()
>
>> if (lockmode >= AccessExclusiveLock &&
>> locktag->locktag_type == LOCKTAG_RELATION &&
>> !RecoveryInProgress())
>> (void) GetCurrent
Simon Riggs writes:
> That would mean running GetCurrentTransactionId() inside LockAcquire()
> if (lockmode >= AccessExclusiveLock &&
> locktag->locktag_type == LOCKTAG_RELATION &&
> !RecoveryInProgress())
> (void) GetCurrentTransactionId();
> Any objections to that fix?
Could we
On Fri, Nov 26, 2010 at 7:40 AM, Simon Riggs 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 it?
> If I understa
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 Wed, Nov 24, 2010 at 1:27 PM, Fujii Masao 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 reproduce the above H
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 co
20 matches
Mail list logo
