After a MINVALUE/MAXVALUE bound, allow only more of the same.
In the old syntax, which used UNBOUNDED, we had a similar restriction,
but commit d363d42bb9a4399a0207bd3b371c966e22e06bd3, which changed the
syntax, eliminated it. Put it back.
Patch by me, reviewed by Dean Rasheed.
Discussion:
htt
After a MINVALUE/MAXVALUE bound, allow only more of the same.
In the old syntax, which used UNBOUNDED, we had a similar restriction,
but commit d363d42bb9a4399a0207bd3b371c966e22e06bd3, which changed the
syntax, eliminated it. Put it back.
Patch by me, reviewed by Dean Rasheed.
Discussion:
htt
src/test/ldap: Fix test function in Linux port
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c29145f00df2aa873672ab9f1b3fc4ec6a0ec05d
Modified Files
--
src/test/ldap/t/001_auth.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
Sent via
On Sat, Sep 16, 2017 at 7:07 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2017-09-15 10:33:37 -0400, Tom Lane wrote:
>>> I don't much like your proposed comment; the only way that this code
>>> is even approximately correct is if we're exiting the process and
>>> will never touch the RecordC
On 2017-09-15 15:07:14 -0400, Tom Lane wrote:
> It's moot as long as we're not reusing workers, anyway: nothing is
> going to touch any of the record-tupdesc data before process exit.
Right - I'm ok with the end-result, I was just a bit confused about the
justification, because neither before nor
Andres Freund writes:
> On 2017-09-15 10:33:37 -0400, Tom Lane wrote:
>> I don't much like your proposed comment; the only way that this code
>> is even approximately correct is if we're exiting the process and
>> will never touch the RecordCacheArray again. (Otherwise, it risks
>> reassigning a
Apply pg_get_serial_sequence() to identity column sequences as well
Bug: #14813
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3012061b8653a57a098c85f06f1f80ec9576711b
Modified Files
--
doc/src/sgml/func.sgml | 37 --
Apply pg_get_serial_sequence() to identity column sequences as well
Bug: #14813
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f830183492d3a3b74cbd33645db19b8b5b5a2622
Modified Files
--
doc/src/sgml/func.sgml | 37 +++
On 2017-09-15 10:33:37 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Yeah. The regress tests in d36f7efb39e1b9613193b2e12717dbe2418ddae5
> > tested this stuff in parallel mode, but only a happy case to
> > demonstrate blessed RECORD types travelling through tqueue.c correctly
> > before and a
On 2017-09-15 00:59:35 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Rebased on your fix.
>
> Ah, yet a different issue :-(. Pushed that too.
Thanks for pushing the fixes - I'd waited till the first few animals
came back green, and then went to somebody's birthday
celebrations. Didn't wait
Add LDAP authentication test suite
Like the SSL test suite, this will not be run by default.
Reviewed-by: Thomas Munro
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f0e60ee4bc04fd4865dbaf2139d50d6fe71c1bc3
Modified Files
--
src/test/Makefile
Thomas Munro writes:
> The attached patch fixes the problem
> by getting rid of the code that accesses shmem in the detach hook.
> With this patch applied installcheck survives on a cluster with
> force_parallel_worker=regress.
In hopes of getting the buildfarm back to green, I went ahead and pus
Get rid of shared_record_typmod_registry_worker_detach; it doesn't work.
This code is unsafe, as proven by buildfarm failures, because it tries
to access shared memory that might already be gone. It's also unnecessary,
because we're about to exit the process anyway and so the record type cache
sh
Thomas Munro writes:
> Yeah. The regress tests in d36f7efb39e1b9613193b2e12717dbe2418ddae5
> tested this stuff in parallel mode, but only a happy case to
> demonstrate blessed RECORD types travelling through tqueue.c correctly
> before and after ripping out the remapping stuff. The problem here
Test coverage for CREATE/ALTER FOREIGN DATA WRAPPER .. HANDLER.
Amit Langote, per a suggestion from Mark Dilger. Reviewed by
Marc Dilger and Ashutosh Bapat.
Discussion:
http://postgr.es/m/cafjfprel0oen7scpnsepbqjhb2bp1wnh1uvbof_w6keuv6z...@mail.gmail.com
Branch
--
master
Details
---
h
15 matches
Mail list logo