Hi
I created a materialized view to manage editings via a real postgres
view. The view has some rules to deliver all inserts, updates and
deletes to the underlaying table with the appropriate privileges,
insert, update and delete, for members of an editing role. To avoid
editings on the underlay
On 24 November 2010 08:57, Düster Horst wrote:
> Hi
>
> I created a materialized view to manage editings via a real postgres view.
> The view has some rules to deliver all inserts, updates and deletes to the
> underlaying table with the appropriate privileges, insert, update and
> delete, for me
On 24/11/2010, at 5:07 PM, Tom Lane wrote:
> Elliot Chance writes:
>> This is a hypothetical problem but not an impossible situation. Just curious
>> about what would happen.
>
>> Lets say you have an OLTP server that keeps very busy on a large database.
>> In this large database you have one
On Wed, Nov 24, 2010 at 12:59 PM, Elliot Chance wrote:
> > Elliot Chance writes:
> >> This is a hypothetical problem but not an impossible situation. Just
> curious about what would happen.
> >
> >> Lets say you have an OLTP server that keeps very busy on a large
> database. In this large databas
Hi Szymon Guz
Thanks a lot for your response. I think the SECURITY DEFINER doesn't
solve my problem. Here an example (stupid I know but just for
explanation):
1. I have created the view myView (select id from myTable) with an
insert rule and I have created a table myTable (id integer, time
ti
On 24 November 2010 14:56, Düster Horst wrote:
> Hi Szymon Guz
>
> Thanks a lot for your response. I think the SECURITY DEFINER doesn't solve
> my problem. Here an example (stupid I know but just for explanation):
>
> 1. I have created the view myView (select id from myTable) with an insert
> r
Vladimir Rusinov wrote:
> I think it would be advisable not to use pg_dump on such load.
Agreed.
> Use fs- or storage-level snapshots instead.
Or PITR backup techniques. Or hot/warm standby. Or streaming
replication. Or one of the many good trigger-based replication
products. Just abou
Elliot Chance writes:
> Wouldn't that mean at some point it would be advisable to be using 64bit
> transaction IDs? Or would that change too much of the codebase?
It's not so much "too much of the codebase" as "nobody wants another 8
bytes added to per-row overhead". Holding a transaction open
> "TL" == Tom Lane writes:
TL> Here is the problem: what if someday that filesystem happens not to
TL> be mounted? Then you have a bare mountpoint directory, with no real
TL> way for the postmaster to notice that that wasn't what you intended.
TL> Hilarity ensues.
That is a convincing argum
On Wed, Nov 24, 2010 at 11:56:16AM +0530, c k wrote:
> Hello,
> Does calling a pl/python function from each database connection load the
> python interpreter each time? what are the effects of using pl/python
> function in a environment where no. of concurrent connections are more and
> each user c
Hi to all,
i've seen this is a popular topic but haven't found any concrete answers so
far.
So my scenario is this :
- created a new user with :
sudo -u postgres createuser -D -A -P john
- created a new database with :
sudo -u postgres createdb -E 'UTF8' -O john test
- added plpgsql
sudo -u po
Le 23/11/2010 13:24, tomislavb a écrit :
> [...]
> i've seen this is a popular topic but haven't found any concrete answers so
> far.
> So my scenario is this :
>
> - created a new user with :
> sudo -u postgres createuser -D -A -P john
>
> - created a new database with :
> sudo -u postgres creat
12 matches
Mail list logo
