.
regards,
Feike Steenbergen
0001-Make-header-of-postgresql.conf.auto-consistent.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
When installing pgstattuple on 10, the documentation about its
privileges was unclear to me. (Does the pg_stat_scan_tables role get
EXECUTE privileges by default or not?).
By making the privilege paragraph less verbose and a duplicate of the
paragraph used for pgfreespacemap and pgbuffercache
Forwarding message from pgsql-bugs for review
Attached a patch which copies the logic from commit
93a6be63a55a8cd0d73b3fa81eb6a46013a3a974.
In the current implementation we only consider privileges of the foreign
server
in determining whether or not to show the user mapping details. This patch
c
On 6 January 2017 at 15:42, Magnus Hagander wrote:
> Is there actual value in providing both %p and %f? It's not like it's
really hard to do, but since the path will be specified on the same
commandline, you could just put it in the command?
As %f can be determined from %p I don't mind that much
On Fri, Jan 6, 2017 at 2:30 PM, David Steele wrote:
> For my part I still prefer an actual command to be executed so it will
start/restart the archiver if it is not already running or died. This
reduces the number of processes that I need to ensure are running.
>
> If the consensus is that a sign
On 6 January 2017 at 13:50, Magnus Hagander wrote:
> I think we're better off clearly documenting that we don't care about it.
And basically let the external command be responsible for that part.
> So for example, your typical backup manager would listen to this signal
or whatever to react quickl
Hi all,
When reading through "Support for pg_receivexlog --format=plain|tar"[1], I
came across a notion from Magnus Hagander that has crossed my mind a few
times as well in the past years. As the feature proposed here is not
directly related to that thread, I thought it best to start a new thread
> but -X stream is, then we use a temporary slot always.
This seems even more useful with -X fetch to me, as with fetch we are sure
we
are not immediately receiving the WAL. So, I'd propose to use it whenever -X
is specified, regardless of which method is specified.
> (I still think we should chan
This patch is redundant as of
commit 2ac3be2e763d9b971352819f285dd51519e0aeb9
(Ashutosh Sharma diagnosed and patched the same problem)
On 15 April 2016 at 14:13, Michael Paquier
wrote:
> On Fri, Apr 15, 2016 at 8:48 PM, Feike Steenbergen
> wrote:
> > pg_get_functiondef(oid) doe
pg_get_functiondef(oid) does not return the PARALLEL indicators.
Attached a small patch to have pg_get_functiondef actually add these
indicators, using commit 7aea8e4f2 (pg_dump.c) as a guide.
The logic is the same as with the volatility: we only append non-default
indicators.
Feike Steenbergen
You can create a Security Definer Funtion which can then be executed by
then non-superuser monitoring role:
(Assuming you have a role monitoring and pg_stat_statements is installed in
schema public)
-- connected as a superuser
CREATE FUNCTION pg_stat_statements()
RETURNS SETOF pg_stat
- VACUUM
The following statements call PreventTransactionChain and do generate errors
in autocommit-off mode:
- DROP INDEX CONCURRENTLY
- ALTER DATABASE ... SET TABLESPACE
- ALTER TYPE ... ADD
I don't see why these last three should be treated seperately from the
first list; we should
either al
it-on; so only running it in
autocommit-off would not test the majority of users.
- autocommit-off also obliges you to explicitly rollback transactions after
errors occur; this would probably mean a rewrite of some tests?
kind regards,
Feike Steenbergen
--
Sent via pgsql-hackers
It would test that when setting AUTOCOMMIT to off that you will not run into:
ERROR: [...] cannot run inside a transaction block
when issuing one of these PreventTransactionChain commands. In
src/bin/psql/common.c
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On 6 October 2014 14:09, Michael Paquier wrote:
> That's a good catch and it should be a separate patch. This could even be
> considered for a back-patch down to 9.2. Thoughts?
If I isolate "DROP INDEX concurrently", this patch would do the trick.
20141006_drop_index_concurrently.patch
Descript
atch consisting of a regression test and adding DROP
INDEX CONCURRENTLY to command_no_begin.
Kind regards,
Feike Steenbergen
20141006_autocommit-off_regression.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
16 matches
Mail list logo
