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, the second arrival w
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:
> Ian Campbell write
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 pg_ls_
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.
Well AFAIK SQL doesn't even have
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 machine.
You might be inspired
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 it is you're
blocki
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] O
