On Wed, Feb 18, 2015 at 9:06 AM, James Sewell
wrote:
> I've just noticed something in the Commit fest post
> - Reducing lock strength of trigger and foreign key DDL
>
This reduces the lock taken for ADD FOREIGN KEY to ShareRowExclusiveLock,
authorizing SELECT and SELECT FOR [SHARE | UPDATE ... ]
Oh,
I've just noticed something in the Commit fest post
- Reducing lock strength of trigger and foreign key DDL
Perhaps I just need to be more patient.
Cheers,
James Sewell,
Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 83
Hello all,
When I add a FK with a statement like this:
ALTER TABLE a ADD FOREIGN KEY (id) REFERENCES b(id);
I see a lock on table b:
select locktype,mode,granted from pg_locks, pg_stat_activity where
relation::regclass::text = 'b' AND pg_locks.pid = pg_stat_activity.pid;
locktype | relation
mo
Christopher Browne <[EMAIL PROTECTED]> writes:
> I would, given an ideal world, prefer to be able to have a connection
> or two live during this to let me monitor the DB and even get an early
> peek at the data.
On that note, how hard would it be to implement a read-dirty mode in postgres?
Thi
Manfred Koizar <[EMAIL PROTECTED]> writes:
> db=> SET disable-fk-verification = true;
> ERROR: "disable-fk-verification" can only be set in single user mode
I don't really see the point of such a restriction. Restricting the
system to a single user has nothing to do with making
disable-fk-verific
[EMAIL PROTECTED] (Manfred Koizar) writes:
> On Tue, 30 Sep 2003 08:00:07 -0400, Christopher Browne
> <[EMAIL PROTECTED]> wrote:
>>I would be pretty "game" for a near-single-user-mode approach that
>>would turn off some of the usual functionality that we knew we didn't
>>need because the data sourc
On Tue, 30 Sep 2003 08:00:07 -0400, Christopher Browne
<[EMAIL PROTECTED]> wrote:
>I would be pretty "game" for a near-single-user-mode approach that
>would turn off some of the usual functionality that we knew we didn't
>need because the data source was an already-committed-and-FK-checked
>set of
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Tom Lane) would write:
> Since there's no performance difference at pg_dump time, I can't see any
> advantage to freezing your decision then.
This parallels the common suggestion of throwing an ANALYZE in at the
bottom of a pg_dump script.
