Ian Campbell writes:
> OK, so SPI is only suitable for single-call functions, right?
It's usable by strictly nested functions, but a multi-call SRF is more
like a coroutine.
> If another
> function in the query attempted to use SPI, I assume there would be a
> deadlock?
No,
I'm going to rewrite it to use your tuplestore suggestion.
OK, so SPI is only suitable for single-call functions, right? If another
function in the query attempted to use SPI, I assume there would be a
deadlock?
Regards, Ian
On Thu, Sep 22, 2016 at 7:25 PM Tom Lane wrote:
Thank you all, I thought there may be a specific posgresql stored procedure
that did the work of enumerating the files of the pg_xlog directory to get
its full size, or may be one that gave the full size of the server
databases including pg_xlog.
Nevermind, this does the work.
Regards,
Sylvain
On Thu, Sep 22, 2016 at 02:23:20PM +0200, Sylvain Marechal wrote:
> is there a way to monitor the size of the pg_xlog directory in SQL? The
Assuming you have superuser privileges, it will most likely work:
select sum( (f).size ) from (select pg_stat_file('pg_xlog/' || pg_ls_dir) as f
from
Hello:
On Thu, Sep 22, 2016 at 2:23 PM, Sylvain Marechal
wrote:
> is there a way to monitor the size of the pg_xlog directory in SQL? The goal
> is to monitor the pg_xlog file without ressorting to a 'du' like solution
> that needs a direct access to the machine.
On Thu, 22 Sep 2016 14:23:20 +0200
Sylvain Marechal wrote:
> Hello all,
>
> is there a way to monitor the size of the pg_xlog directory in SQL? The
> goal is to monitor the pg_xlog file without ressorting to a 'du' like
> solution that needs a direct access to the
Hello all,
is there a way to monitor the size of the pg_xlog directory in SQL? The
goal is to monitor the pg_xlog file without ressorting to a 'du' like
solution that needs a direct access to the machine.
I know I can get the retained size for existing replication slots segment
in case there are
Ian Campbell writes:
> Thanks for personally replying, Tom. I appreciate it.
> You are correct. In the interim, I found the following change solved the
> issue:
> SPI_finish(); // move to here
> SRF_RETURN_DONE(funcctx);
That might work under light usage, but the problem with
This is probably the start of your quest into this project. No doubt you’ll
need to handle other queries.
So my suggestion is first to rationalise the data storage before digging any
deeper.
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org]
Thanks for personally replying, Tom. I appreciate it.
You are correct. In the interim, I found the following change solved the
issue:
SPI_finish(); // move to here
SRF_RETURN_DONE(funcctx);
I'll look into tuplestore. Thanks for the hint. Fixed IMMUTABLE.
Regards
Ian Campbell
On Thu, Sep 22,
10 matches
Mail list logo