Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dfonta...@hi-media.com writes:
Please find attached a little little patch which run
process_local_preload_libraries from within a transaction.
This is inevitably going to break other people's code. Put the
transaction wrapper in your
Hi,
Le 31 mai 09 à 18:21, Tom Lane a écrit :
The reason this doesn't work is that SPI can only be invoked inside a
transaction, and you're not inside one when a library is being
preloaded.
Please find attached a little little patch which run
process_local_preload_libraries from within a
Dimitri Fontaine dfonta...@hi-media.com writes:
Please find attached a little little patch which run
process_local_preload_libraries from within a transaction.
This is inevitably going to break other people's code. Put the
transaction wrapper in your own stuff if you have to have it.
Dimitri Fontaine wrote:
Le 31 mai 09 à 18:21, Tom Lane a écrit :
You could maybe make this work by executing your own transaction
to do it, but I really have to wonder if it's a good idea. One
point to think about is that elog(ERROR) still means elog(FATAL)
at this point, so any brokenness
On Mon, 2009-06-01 at 12:23 -0400, Alvaro Herrera wrote:
Dimitri Fontaine wrote:
Le 31 mai 09 à 18:21, Tom Lane a écrit :
You could maybe make this work by executing your own transaction
to do it, but I really have to wonder if it's a good idea. One
point to think about is that
Dimitri Fontaine dfonta...@hi-media.com writes:
Dimitri Fontaine dfonta...@hi-media.com writes:
And currently calling SPI_connect() from _PG_init will crash the
backend. I'll try to obtain a gdb backtrace, I've just been told about
pre_auth_delay and post_auth_delay parameters.
Here we go:
Hi,
First, thank you to have taken the time to see about the case.
Le 31 mai 09 à 18:21, Tom Lane a écrit :
The reason this doesn't work is that SPI can only be invoked inside a
transaction, and you're not inside one when a library is being
preloaded.
Makes sense. Still crashing with basic
Dimitri Fontaine dfonta...@hi-media.com writes:
And currently calling SPI_connect() from _PG_init will crash the
backend. I'll try to obtain a gdb backtrace, I've just been told about
pre_auth_delay and post_auth_delay parameters.
Here we go:
(gdb) handle SIGABRT nopass
SignalStop
Some feedback
1. Want some very clear and supported way to know whether Postgres is
fully up. Currently, if you write _PG_init you sometimes need to know if
it is being executed by LOAD or as a reload. So actual initialisation
sometimes needs to happen outside of _PG_init.
2. shmem_startup_hook
Hi,
Le 20 mai 09 à 20:51, Simon Riggs a écrit :
1. Want some very clear and supported way to know whether Postgres is
fully up. Currently, if you write _PG_init you sometimes need to
know if
it is being executed by LOAD or as a reload. So actual initialisation
sometimes needs to happen
Simon Riggs si...@2ndquadrant.com writes:
2. shmem_startup_hook doesn't allow multiple modules to create shmem.
All callers of the hook think they are the only caller, causing chaos if
multiple people need this.
The only known caller, contrib/pg_stat_statements/, does not think that.
Do what
On Wed, 2009-05-20 at 16:03 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
2. shmem_startup_hook doesn't allow multiple modules to create shmem.
All callers of the hook think they are the only caller, causing chaos if
multiple people need this.
The only known caller,
12 matches
Mail list logo
