Re: [HACKERS] Proposal for db level triggers

Hi, We have something that seems to work and may be used as a start point. Please, take a look at http://gorda.di.uminho.pt/community/pgsqlg/ In particular, take a look at the file src/backend/commands/triggerspecial. Cheers, Alfranio. > > On Mar 13, 2008, at 5:14 PM, James Mansion

Re: [HACKERS] Re: [PATCHES] As proposed the complete changes to pg_trigger and pg_rewrite

ations would be very useful for replication. Best regards, Alfranio. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

[HACKERS] Execution Plan

document available. Best regards, Alfranio. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] standard interfaces for replication providers

> > Why reinvent the wheel for everything if there was an interface that > offered some of the needed functionality? Maybe PostgreSQL-R is simply > too deep in the database for any of this to be useful, but I'm 99% > certain that Slony could make use of some of this stuff, such as a hook > on tu

Re: [HACKERS] standard interfaces for replication providers

ecution plan generation 6 - tuples written Our current prototype covers some of them and some of them partially (2,6). Besides, we also need the priority mechanism. Best regards, Alfranio Junior. ---(end of broadcast)--- TIP 3: Have you ch

Re: [HACKERS] standard interfaces for replication providers

ould be enough. In this case, the API should provide only an interface to set the priority of a transaction In our case, still unfinished and quite simple: "set transaction master" but it could be easily transformed into "set transaction priority ". Best regards, Alfranio Junior. ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] standard interfaces for replication providers

Markus Schiltknecht wrote: > Hi, > > José Orlando Pereira wrote: >> I would argue that people haven't been able to build production-grade >> multi-master replication, in part, due to the barrier of not having a >> "standard" database-agnostic API. :-) >> >> In fact, the problem is not the lack of a

[HACKERS] standard interfaces for replication providers

. We welcome the comments and suggestions of PostgreSQL hackers. Best regards, Alfranio Junior. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [HACKERS] Locks

I mean, any C function. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

[HACKERS] Locks

Are there some sort of functions that I could use to know which process has an exclusive lock on relations, pages, tuples, transactions, etc... ? Best regards, Alfranio Junior ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ

[HACKERS] Lock Functions

I don't know if this the correct list to ask about implementation details. If not, let me know. Anyway, are there functions that return which processes or transactions are holding locks in relations, tuples, etc ? Best regards, Alfranio ---(end of broa

Re: [HACKERS] strange behavior on locks

I am executing some stored procedures written in pl/pgsql But wouldn't PostgreSQL show information per statement executed by the functions ? or SELECT func_with_side_effects() ? -Mike ---(end of broadcast)--- TIP 5: don't forget to increas

Re: [HACKERS] strange behavior on locks

Perhaps you are using SELECT FOR UPDATE? I am not using "SELECT FOR UPDATES"... Could it have another cause ? ---(end of broadcast)--- TIP 6: explain analyze is your friend

[HACKERS] strange locks

ow is this situation possible ? 3 - What could cause the status ("select waiting") ? Best regards, Alfranio ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

[HACKERS] strange behavior on locks

ion id ? 2 - How is this situation possible ? What could cause the status ("select waiting") ? Best regards, Alfranio ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] HOOKS for Synchronous Replication?

I fixed the patch and now it compiles in windows. The first one did not compile because there were some problems in the Makefile. It is currently available for download at http://gorda.di.uminho.pt/community/pgsqlhooks/. Regards, Alfranio ---(end of broadcast

Re: [HACKERS] Need A Suggestion

such as plgsql, perl, java, etc.. and also to allow triggers on [before | after] commit and [before | after] abort. Best regards, Alfranio Junior ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] HOOKS for Synchronous Replication

ror: syntax error before '{' token Linux alfranio.lsd.di.uminho.pt 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) Do you have any idea ? Best regards, Alfranio Junior. ---(end of broadcast)--

Re: [HACKERS] HOOKS for Synchronous Replication

efore" and "after commit" without changing the code. On a different front, have you considered talking to the people behind Slony-II to see if they'd have some use for your hooks? I would like to share the hooks with them and other things that I have

[HACKERS] HOOKS for Synchronous Replication

and suggestions welcome, Regards Alfranio Junior. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org