Allow external recovery_config_directory
If required, recovery.conf can now be located outside of the data directory.
Server needs read/write permissions on this directory.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/bc5334d8679c428a709d150666b288171795bd76
Modif
On Wed, Mar 27, 2013 at 12:47 PM, Simon Riggs wrote:
> Allow external recovery_config_directory
> If required, recovery.conf can now be located outside of the data directory.
> Server needs read/write permissions on this directory.
Should we consider verifying that it has write permissions and fa
sepgsql: Support for new post-ALTER access hook.
KaiGai Kohei
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/1cea9bbb21e9e90dc7085ce605d9160e7161fa58
Modified Files
--
contrib/sepgsql/database.c | 27 +
contrib/sepgsql/expected/alter.out |
On 27 March 2013 12:33, Robert Haas wrote:
> sepgsql: Support for new post-ALTER access hook.
I notice that due to commit bc5334d8 I can't actually build the docs
at the moment.
But I think the language here definitely needs improving:
"On CREATE FUNCTION, install permission will be checked if
On 27 March 2013 12:02, Magnus Hagander wrote:
> On Wed, Mar 27, 2013 at 12:47 PM, Simon Riggs wrote:
>> Allow external recovery_config_directory
>> If required, recovery.conf can now be located outside of the data directory.
>> Server needs read/write permissions on this directory.
>
> Should we
On 27 March 2013 11:47, Simon Riggs wrote:
> Allow external recovery_config_directory
> If required, recovery.conf can now be located outside of the data directory.
> Server needs read/write permissions on this directory.
The docs don't build due to this commit. Please remove the unpaired
"" fro
On 27 March 2013 13:14, Thom Brown wrote:
> On 27 March 2013 11:47, Simon Riggs wrote:
>> Allow external recovery_config_directory
>> If required, recovery.conf can now be located outside of the data directory.
>> Server needs read/write permissions on this directory.
>
> The docs don't build due
On 03/27/2013 07:47 AM, Simon Riggs wrote:
Allow external recovery_config_directory
If required, recovery.conf can now be located outside of the data directory.
Server needs read/write permissions on this directory.
This patch appears to have broken Windows builds on the buildfarm.
cheers
Move some pg_dump function around.
Move functions used only by pg_dump and pg_restore from dumputils.c to a new
file, pg_backup_utils.c. dumputils.c is linked into psql and some programs
in bin/scripts, so it seems good to keep it slim. The parallel functionality
is moved to parallel.c, as is exit
Set recovery_config_directory for EXEC_BACKEND.
Remove comment questioning whether this is necessary for DataDir.
From buildfarm failures on Windows.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7a5a59d378e052618d6feae64d1d2b4f2ad6f9bc
Modified Files
-
Fix buffer pin leak in heap update redo routine.
In a heap update, if the old and new tuple were on different pages, and the
new page no longer existed (because it was subsequently truncated away by
vacuum), heap_xlog_update forgot to release the pin on the old buffer. This
bug was introduced by t
Fix buffer pin leak in heap update redo routine.
In a heap update, if the old and new tuple were on different pages, and the
new page no longer existed (because it was subsequently truncated away by
vacuum), heap_xlog_update forgot to release the pin on the old buffer. This
bug was introduced by t
Fix buffer pin leak in heap update redo routine.
In a heap update, if the old and new tuple were on different pages, and the
new page no longer existed (because it was subsequently truncated away by
vacuum), heap_xlog_update forgot to release the pin on the old buffer. This
bug was introduced by t
Fix buffer pin leak in heap update redo routine.
In a heap update, if the old and new tuple were on different pages, and the
new page no longer existed (because it was subsequently truncated away by
vacuum), heap_xlog_update forgot to release the pin on the old buffer. This
bug was introduced by t
Fix pasto which broke docs build.
Commit bc5334d8679c428a709d150666b288171795bd76 accidentally
included a second tag for a new list item.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/40e873d854cae046df941d162c3cbcefd00b3915
Modified Files
--
doc/src/
Simon Riggs wrote:
> doc/src/sgml/config.sgml | 17 +
So that doc builds could proceed without error I fixed the obvious
pasto in config.sgml.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-committers m
On 27 March 2013 21:13, Kevin Grittner wrote:
> Fix pasto which broke docs build.
>
> Commit bc5334d8679c428a709d150666b288171795bd76 accidentally
> included a second tag for a new list item.
Thanks. I was sure I had pushed the fix Thom mentioned it, looks like
I skipped that part, sorry to trou
Reset OpenSSL randomness state in each postmaster child process.
Previously, if the postmaster initialized OpenSSL's PRNG (which it will do
when ssl=on in postgresql.conf), the same pseudo-random state would be
inherited by each forked child process. The problem is masked to a
considerable extent
Reset OpenSSL randomness state in each postmaster child process.
Previously, if the postmaster initialized OpenSSL's PRNG (which it will do
when ssl=on in postgresql.conf), the same pseudo-random state would be
inherited by each forked child process. The problem is masked to a
considerable extent
Reset OpenSSL randomness state in each postmaster child process.
Previously, if the postmaster initialized OpenSSL's PRNG (which it will do
when ssl=on in postgresql.conf), the same pseudo-random state would be
inherited by each forked child process. The problem is masked to a
considerable extent
Reset OpenSSL randomness state in each postmaster child process.
Previously, if the postmaster initialized OpenSSL's PRNG (which it will do
when ssl=on in postgresql.conf), the same pseudo-random state would be
inherited by each forked child process. The problem is masked to a
considerable extent
Reset OpenSSL randomness state in each postmaster child process.
Previously, if the postmaster initialized OpenSSL's PRNG (which it will do
when ssl=on in postgresql.conf), the same pseudo-random state would be
inherited by each forked child process. The problem is masked to a
considerable extent
On 03/27/2013 12:36 PM, Simon Riggs wrote:
Set recovery_config_directory for EXEC_BACKEND.
Remove comment questioning whether this is necessary for DataDir.
From buildfarm failures on Windows.
This hasn't cured the problem.
If you don't have a Windows machine / VM to test on, you can try t
23 matches
Mail list logo
