Re: Is there a shortage of postgresql skilled ops people

From: "Martin Gainty" <mgainty(at)hotmail(dot)com>
To: "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Is there a shortage of postgresql skilled ops people
Date: 2007-04-13 14:52:49
Message-ID: BAY133-DAV1600A01AD830AE44BDB507AE5D0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-general

Oracle's suggested solution for 'mutating table error' is to create a global
temporary table for the parent
To avoid inconsistent behaviour with the parent table a AFTER ROW trigger
checks new rows and commits rows only to the temporary table then
the changes from the temp table are committed to permanent parent table
when AFTER STATEMENT trigger is executed
http://www.akadia.com/services/ora_mutating_table_problems.html
M--
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.

----- Original Message -----
From: "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>
To: <pgsql-general(at)postgresql(dot)org>
Sent: Friday, April 13, 2007 10:02 AM
Subject: Re: [GENERAL] Is there a shortage of postgresql skilled ops people

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/09/07 10:50, Erik Jones wrote:
>>
>> On Apr 9, 2007, at 9:46 AM, Vivek Khera wrote:
> [snip]
>>> One thing that was really counter-intuitive to me from a guy who runs
>>> really large databases, was to get rid of some of the FK's and manage
>>> them in the application layer. This one scares me since I've had my
>>> behind saved at least a couple of times by having the extra layer in
>>> the DB to protect me... the data integrity would be managed by some
>>> external program that sweeps the DB every so often and purges out data
>>> that should no longer be there (ie stuff that would have been CASCADE
>>> DELETEd).
>>
>> This is often debated and it does seem strange to here that stance from
>> a dba. It's normally the application developers who want to do that.
>
> It depends on how efficient your engine and site are at deleting
> cascades. If it causes an unacceptable amount of extra locking in a
> multi-user situation, away goes the FK and in comes the off-hour
> sweeper.
>
> - --
> Ron Johnson, Jr.
> Jefferson LA USA
>
> Give a man a fish, and he eats for a day.
> Hit him with a fish, and he goes away for good!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGH41yS9HxQb37XmcRArGnAJ4n12NxeKleCf7n1OFUtOQYnJy1wQCg6OVz
> fMjwTsezDnukoV8yyXTouJw=
> =XgVW
> -----END PGP SIGNATURE-----
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Josh Berkus 2007-04-15 00:48:27 Re: [pgsql-advocacy] Broken links in presskit
Previous Message Ron Johnson 2007-04-13 14:02:26 Re: Is there a shortage of postgresql skilled ops people

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-04-13 15:08:54 Re: Regard to PANIC: unexpected hash relation size
Previous Message Tom Lane 2007-04-13 14:48:04 Re: ERROR: XLogFlush: request