On Tuesday 25 July 2006 22:05, Marko Kreen wrote:
> On 7/24/06, Nicolai Petri <[EMAIL PROTECTED]> wrote:
> > I'm in the need for my custom written replication engine to obtain the
> > current transaction id from a trigger function. As far as I'm told it's
l C code I have left in my application and I
think it would be a nice information in general to have available for users.
If not for anything else then for simple statistics.
I attached the function I use with great success today.
Best regards,
Nicolai Petri
-
users of our software download and compile it. Especially when they are used
to just install binary rpms.
If people hate contrib so much why not just get rid of it forever.. Either it
should embrace as much small contrib modules as possible - else it should
disappear in
linux systems - if pgxs will fix
this so it can be compiled as a "standalone" extension then it is a solution
I can live with.
Best regards,
Nicolai Petri
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an a
ommon workloads like webpages. Where it would be troublesome
is systems with long-running transactions - it might as well just be disabled
there.
Best regards,
Nicolai Petri
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hi All,
Just a small comment from a mortal user.
On Thursday 01 June 2006 19:28, Josh Berkus wrote:
> 5. random_page_cost (as previously discussed) is actually a funciton of
> relatively immutable hardware statistics, and as such should not need to
> exist as a GUC once the cost model is fixed.
I
API before I start coding anything.
---
Nicolai Petri
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
for adding new tablestore engines (like mysql can)
- for adding callbacks that get's called on transaction
success/failure
using SPI. (e.g. for housekeeping and cleanup)
5) Adding parameter support for NOTIFY / LISTEN
Jim C. Nasby, Database Consultant [EMAIL PROT
