On 2016/12/13 1:23, Tom Lane wrote:
> Fix creative, but unportable, spelling of "ptr != NULL".
>
> Or at least I suppose that's what was really meant here. But even
> aside from the not-per-project-style use of "0" to mean "NULL",
> I doubt it's safe to assume that all valid pointers are > NULL.
On 13/12/16 02:00, Andres Freund wrote:
> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>> I mentioned that as possible solution upthread, I am only worried that
>> the failure scenario is basically infinite loop.
>
> I don't see the problem with that. If you're really concerned you can
> set
On 13/12/16 02:08, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>>> I mentioned that as possible solution upthread, I am only worried that
>>> the failure scenario is basically infinite loop.
>
>> I don't see the problem with that. If you're really
On 2016-12-12 20:08:01 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
> >> I mentioned that as possible solution upthread, I am only worried that
> >> the failure scenario is basically infinite loop.
>
> > I don't see the problem with that. If
Andres Freund writes:
> On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
>> I mentioned that as possible solution upthread, I am only worried that
>> the failure scenario is basically infinite loop.
> I don't see the problem with that. If you're really concerned you can
> set a statement timeout
On 2016-12-13 01:57:01 +0100, Petr Jelinek wrote:
> I mentioned that as possible solution upthread, I am only worried that
> the failure scenario is basically infinite loop.
I don't see the problem with that. If you're really concerned you can
set a statement timeout.
Andres
--
Sent via pgsql-
On 13/12/16 01:49, Andres Freund wrote:
> On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote:
>> On 13/12/16 01:40, Tom Lane wrote:
>>> Petr Jelinek writes:
On 13/12/16 00:39, Tom Lane wrote:
> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
> of the slot happen
On 2016-12-13 01:42:48 +0100, Petr Jelinek wrote:
> On 13/12/16 01:40, Tom Lane wrote:
> > Petr Jelinek writes:
> >> On 13/12/16 00:39, Tom Lane wrote:
> >>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
> >>> of the slot happen ... is it not complete by the time the back
On 2016-12-12 19:40:37 -0500, Tom Lane wrote:
> Petr Jelinek writes:
> > Yes, I've seen. The cleanup of slots is done in ProcKill(), I wonder,
> > since it's on_shmem_exit hook, and the pgstat_beshutdown_hook is as
> > well, maybe the pgstat_beshutdown_hook is called before ProcKill and the
> > qu
On 13/12/16 01:40, Tom Lane wrote:
> Petr Jelinek writes:
>> On 13/12/16 00:39, Tom Lane wrote:
>>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
>>> of the slot happen ... is it not complete by the time the backend exits?
>
>> Yes, I've seen. The cleanup of slots is don
Petr Jelinek writes:
> On 13/12/16 00:39, Tom Lane wrote:
>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping
>> of the slot happen ... is it not complete by the time the backend exits?
> Yes, I've seen. The cleanup of slots is done in ProcKill(), I wonder,
> since it's on_
On 13/12/16 00:39, Tom Lane wrote:
> I wrote:
>> Petr Jelinek writes:
>>> Attached is the fixed test using the loop from test_extensions (and yes
>>> I would have missed the pg_stat_clear_snapshot() call without the hint,
>>> thanks :) ).
>
>> Pushed, thanks.
>
> Hm, buildfarm says this didn't f
I wrote:
> Petr Jelinek writes:
>> Attached is the fixed test using the loop from test_extensions (and yes
>> I would have missed the pg_stat_clear_snapshot() call without the hint,
>> thanks :) ).
> Pushed, thanks.
Hm, buildfarm says this didn't fix it. Where exactly does the dropping
of the s
Remove should_free arguments to tuplesort routines.
Since commit e94568ecc10f2638e542ae34f2990b821bbf90ac, the answer is
always "false", and we do not need to complicate the API by arranging
to return a constant value.
Peter Geoghegan
Discussion:
http://postgr.es/m/CAM3SWZQWZZ_N=DmmL7tKy_OUjGH_
Catversion bump for temporary replication slots.
Missed in commit a924c327e2793d2025b19e18de7917110dc8afd8.
Per Fujii Masao.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/9b3d02c2a9eb93cc4754857361abee449a3fe0cb
Modified Files
--
src/include/catalog/ca
Petr Jelinek writes:
> Yes you are correct, we tried naively to first drop another slot in
> hopes that it will give the other backend enough time to close, but
> apparently that wasn't robust enough for slower machines.
> Attached is the fixed test using the loop from test_extensions (and yes
>
Fix race condition in test_decoding "slot" test.
This test, just added in commit a924c327e, sometimes fails because
the old backend hasn't finished dropping the temporary replication slot
when the new backend looks. Borrow the previously-invented methodology
for waiting for the old process to dis
doc: Fix purported type of pg_am.amhandler to match reality.
Joel Jacobson
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/b4630e01fd4c73c195025b7307ebc13d489b9ef9
Modified Files
--
doc/src/sgml/catalogs.sgml | 2 +-
1 file changed, 1 insertion(+), 1 dele
doc: Fix purported type of pg_am.amhandler to match reality.
Joel Jacobson
Branch
--
REL9_6_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/ace0df9345c9fe61570348f2a5c3324a726fd4fa
Modified Files
--
doc/src/sgml/catalogs.sgml | 2 +-
1 file changed, 1 insertion(+),
On 12/12/16 16:55, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
>>> Add support for temporary replication slots
>
>> Some of the slower buildfarm members are failing test-decoding-check since
>> this went in. At least on prairiedog, it looks like a race condition in
>> the test:
>
>
Make the different Unix-y semaphore implementations ABI-compatible.
Previously, the "sem" field of PGPROC varied in size depending on which
kernel semaphore API we were using. That was okay as long as there was
only one likely choice per platform, but in the wake of commit ecb0d20a9,
that assumpt
psql: Fix incorrect version check for table partitining.
Table partitioning was added in 10, not 9.6.
FabrÃzio de Royes Mello, per report from Jeff Janes
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/06e184876bc07c2b1d7144957dcf02c5b4f709c2
Modified Files
---
Fix creative, but unportable, spelling of "ptr != NULL".
Or at least I suppose that's what was really meant here. But even
aside from the not-per-project-style use of "0" to mean "NULL",
I doubt it's safe to assume that all valid pointers are > NULL.
Per buildfarm member pademelon.
Branch
--
I wrote:
> Peter Eisentraut writes:
>> Add support for temporary replication slots
> Some of the slower buildfarm members are failing test-decoding-check since
> this went in. At least on prairiedog, it looks like a race condition in
> the test:
Having now looked a bit more closely, that's almo
Peter Eisentraut writes:
> Add support for temporary replication slots
Some of the slower buildfarm members are failing test-decoding-check since
this went in. At least on prairiedog, it looks like a race condition in
the test:
**
/Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/test_decoding
Add support for temporary replication slots
This allows creating temporary replication slots that are removed
automatically at the end of the session or on error.
From: Petr Jelinek
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/a924c327e2793d2025b19e18de7917110dc
Refactor the code for verifying user's password.
Split md5_crypt_verify() into three functions:
* get_role_password() to fetch user's password from pg_authid, and check
its expiration.
* md5_crypt_verify() to check an MD5 authentication challenge
* plain_crypt_verify() to check a plaintext passw
Further cleanup from the strong-random patch.
Also use the new facility for generating RADIUS authenticator requests,
and salt in chkpass extension.
Reword the error messages to be nicer. Fix bogus error code used in the
message in BackendStartup.
Branch
--
master
Details
---
http://git
Fix pgcrypto compilation with OpenSSL 1.1.0.
Was broken by the switch to using OpenSSL's EVP interface for ciphers, in
commit 5ff4a67f.
Reported by Andres Freund. Fix by Michael Paquier with some kibitzing by me.
Discussion:
https://www.postgresql.org/message-id/20161201014826.ic72tfkahmevp...@
Fix two thinkos related to strong random keys.
pg_backend_random() is used for MD5 salt generation, but it can fail, and
no checks were done on its status code.
Fix memory leak, if generating a random number for a cancel key failed.
Both issues were spotted by Coverity. Fix by Michael Paquier.
30 matches
Mail list logo
