Allow concurrent-safe open() and fopen() in frontend code for Windows
PostgreSQL uses a custom wrapper for open() and fopen() which is
concurrent-safe, allowing multiple processes to open and work on the
same file. This has a couple of advantages:
- pg_test_fsync does not handle O_DSYNC correctly
On Sat, Sep 15, 2018 at 07:49:39AM +0900, Michael Paquier wrote:
> I would be fine to get that into v11 though, as that is not released
> yet. You will have to wait for a couple of days though, there is a long
> week-end here away from laptops and electronic devices ;)
OK, REL_11_STABLE has been
Michael Paquier writes:
> OK, REL_11_STABLE has been patched as well, after doing a couple of
> extra tests on Windows.
BTW, I'm a bit concerned by the fact that bowerbird has failed its
last couple of HEAD runs at the pgbench step. The first such
failure was here:
https://buildfarm.postgresql.
On Mon, Sep 17, 2018 at 09:41:37AM -0400, Tom Lane wrote:
> BTW, I'm a bit concerned by the fact that bowerbird has failed its
> last couple of HEAD runs at the pgbench step. The first such
> failure was here:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-09-15%201
Michael Paquier writes:
> On Mon, Sep 17, 2018 at 09:41:37AM -0400, Tom Lane wrote:
>> Looking at the set of commits between the prior run and that one,
>> it's hard to see anything that could have triggered the test failures
>> other than this patch --- but I also don't see how this patch would'v
On 09/17/2018 10:48 AM, Tom Lane wrote:
Michael Paquier writes:
On Mon, Sep 17, 2018 at 09:41:37AM -0400, Tom Lane wrote:
Looking at the set of commits between the prior run and that one,
it's hard to see anything that could have triggered the test failures
other than this patch --- but I a
Fix pgbench lexer's "continuation" rule to cope with Windows newlines.
Our general practice in frontend code is to accept input with either
Unix-style newlines (\n) or DOS-style (\r\n). pgbench was mostly down
with that, but its rule for line continuations (backslash-newline) was
not. This had b
Fix pgbench lexer's "continuation" rule to cope with Windows newlines.
Our general practice in frontend code is to accept input with either
Unix-style newlines (\n) or DOS-style (\r\n). pgbench was mostly down
with that, but its rule for line continuations (backslash-newline) was
not. This had b
Fix pgbench lexer's "continuation" rule to cope with Windows newlines.
Our general practice in frontend code is to accept input with either
Unix-style newlines (\n) or DOS-style (\r\n). pgbench was mostly down
with that, but its rule for line continuations (backslash-newline) was
not. This had b
Andrew Dunstan writes:
> On 09/17/2018 10:48 AM, Tom Lane wrote:
>> We've got a bit of a timing problem because we want to wrap 11beta4/rc1
>> (still TBD) in a few hours. I'll take a look and see if I can push a
>> quick fix before that.
> When you do I'll start a bowerbird run to check it.
Pus
Remove dead code from pop_next_work_item().
The pref_non_data heuristic has been dead code for nearly ten years,
and as far as I can tell was dead code even when it was first committed.
I'm tired of silencing Coverity complaints about it, so get rid of it.
If anyone is ever interested in pursuing
Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT ...)).
The original coding for XMLTABLE thought it could represent a default
namespace by a T_String Value node with a null string pointer. That's
not okay, though; in particular outfuncs.c/readfuncs.c are not on board
with such a rep
Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT ...)).
The original coding for XMLTABLE thought it could represent a default
namespace by a T_String Value node with a null string pointer. That's
not okay, though; in particular outfuncs.c/readfuncs.c are not on board
with such a rep
Fix parsetree representation of XMLTABLE(XMLNAMESPACES(DEFAULT ...)).
The original coding for XMLTABLE thought it could represent a default
namespace by a T_String Value node with a null string pointer. That's
not okay, though; in particular outfuncs.c/readfuncs.c are not on board
with such a rep
On 09/17/2018 12:13 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/17/2018 10:48 AM, Tom Lane wrote:
We've got a bit of a timing problem because we want to wrap 11beta4/rc1
(still TBD) in a few hours. I'll take a look and see if I can push a
quick fix before that.
When you do I'll start
Andrew Dunstan writes:
> On 09/17/2018 12:13 PM, Tom Lane wrote:
>> Pushed, please test.
> Tests are still running, but it's past the pgbench stage on HEAD, so I
> think we're good.
I was more concerned about whether any of the post-pgbench steps would
show a failure; but it looks like HEAD's g
Stamp 11beta4.
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/3d65e406d1ea82060ad13a7bc41178ed22c599d1
Modified Files
--
configure | 18 +-
configure.in | 2 +-
doc/bug.template |
Refactor routines for subscription and publication lookups
Those routines gain a missing_ok argument, allowing a caller to get a
NULL result instead of an error if set to true. This is part of a
larger refactoring effort for objectaddress.c where trying to check for
non-existing objects does not
18 matches
Mail list logo
