Tom Lane writes:
> Dimitri Fontaine 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 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.
reg
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 tran
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
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 br
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 na
Dimitri Fontaine writes:
> Dimitri Fontaine 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:
The reason this doesn't work is that
Dimitri Fontaine 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 Print Pass to pr
On Wed, 2009-05-20 at 16:03 -0400, Tom Lane wrote:
> Simon Riggs 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_sta
Simon Riggs 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 it does.
I agree it
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 outsid
11 matches
Mail list logo
