Re: Is there a shortage of postgresql skilled ops people - Mailing list pgsql-general

From Martin Gainty
Subject Re: Is there a shortage of postgresql skilled ops people
Date
Msg-id BAY133-DAV1600A01AD830AE44BDB507AE5D0@phx.gbl
Whole thread Raw
In response to Is there a shortage of postgresql skilled ops people  (Marc Evans <Marc@SoftwareHackery.Com>)
List 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.l.johnson@cox.net>
To: <pgsql-general@postgresql.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
>


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: XLogFlush: request
Next
From: Tom Lane
Date:
Subject: Re: Regard to PANIC: unexpected hash relation size