Andrew Dunstan writes:
> On 7/9/20 3:36 PM, Tom Lane wrote:
>> Should we consider back-patching the CRLF filtering changes, ie
>> 91bdf499b + ffb4cee43? It's not really necessary perhaps, but
>> I dislike situations where the "same" test on different branches is
>> testing different things. Seem
On 7/9/20 3:36 PM, Tom Lane wrote:
> I wrote:
>> Cool, I'll go try changing all those conditions to use the msys test.
> OK, that worked: all four relevant buildfarm members are now showing
> the expected test failure. So I'll go fix the original bug.
>
> Should we consider back-patching the CRL
I wrote:
> Cool, I'll go try changing all those conditions to use the msys test.
OK, that worked: all four relevant buildfarm members are now showing
the expected test failure. So I'll go fix the original bug.
Should we consider back-patching the CRLF filtering changes, ie
91bdf499b + ffb4cee43?
Andrew Dunstan writes:
> On 7/9/20 11:04 AM, Tom Lane wrote:
>> Therefore, we either should figure out how to get msys perl to do
>> that conversion (and remove it from our code altogether), or make the
>> conversions conditional on "is it msys perl?". I am not quite sure
>> if the existing tests
On 7/9/20 11:04 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 7/9/20 10:44 AM, Tom Lane wrote:
>>> Andrew Dunstan writes:
On 7/8/20 10:40 PM, Tom Lane wrote:
> The most likely theory about that, I think, is that IPC::Run::run already
> translated any \r\n occurrences in the ps
Andrew Dunstan writes:
> On 7/9/20 10:44 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 7/8/20 10:40 PM, Tom Lane wrote:
The most likely theory about that, I think, is that IPC::Run::run already
translated any \r\n occurrences in the psql command's output to plain \n.
>> It's not
On 7/9/20 10:44 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 7/8/20 10:40 PM, Tom Lane wrote:
>>> So I did that, and the first report is from bowerbird and it's still
>>> green. Unless I'm completely misinterpreting what's happening (always
>>> a possibility), that means we're still manag
Andrew Dunstan writes:
> On 7/8/20 10:40 PM, Tom Lane wrote:
>> So I did that, and the first report is from bowerbird and it's still
>> green. Unless I'm completely misinterpreting what's happening (always
>> a possibility), that means we're still managing to remove "data"
>> occurrences of \r.
>
On 7/8/20 10:40 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> Seems reasonable. If we rip it out completely we'll have to find all the
>>> places it breaks and fix them. And we'll almost certainly get new
>>> breakage. If it's hiding a real bug we'll have to do that, but I'd be
>>>
I wrote:
> Andrew Dunstan writes:
>> Seems reasonable. If we rip it out completely we'll have to find all the
>> places it breaks and fix them. And we'll almost certainly get new
>> breakage. If it's hiding a real bug we'll have to do that, but I'd be
>> reluctant unless there's actual proof.
> H
Andrew Dunstan writes:
> On 7/8/20 5:26 PM, Tom Lane wrote:
>> However ... I put in a test case to try to expose this failure, and
>> our Windows buildfarm critters remain perfectly happy. So what's up
>> with that? After some digging around, I believe the reason is that
>> PostgresNode::psql is
On 7/8/20 5:26 PM, Tom Lane wrote:
>
> However ... I put in a test case to try to expose this failure, and
> our Windows buildfarm critters remain perfectly happy. So what's up
> with that? After some digging around, I believe the reason is that
> PostgresNode::psql is stripping the \r from pg_
[ redirecting to pghackers ]
Thomas Kellerer writes:
> Tom Lane schrieb am 08.07.2020 um 18:41:
>> Somehow, the reading file is being left in binary mode and thus it's
>> failing to convert \r\n back to plain \n.
>> Now the weird thing about that is I'd have expected "r" and "w" modes
>> to imply
>> "User was holding shared buffer pin for too long" sounds unusual to
>> me. Is this a bug? PostgreSQL version is 10.1 according to the user.
>
> Sounds normal to me. Maybe the message could use some work, but this
> is how hot standby works:
T: In a moment you should be able to reconnect to the database and repeat
> your command.
>
> "User was holding shared buffer pin for too long" sounds unusual to
> me. Is this a bug? PostgreSQL version is 10.1 according to the user.
Sorry to be the grumpy guy: This isn
T: In a moment you should be able to reconnect to the database and repeat
> your command.
>
> "User was holding shared buffer pin for too long" sounds unusual to
> me. Is this a bug? PostgreSQL version is 10.1 according to the user.
Sounds normal to me. Maybe the message
Hello
No, this is not bug.
https://www.postgresql.org/docs/10/static/hot-standby.html#HOT-STANDBY-CONFLICT
Message in DETAIL describe conflict reason.
> Application of a vacuum cleanup record from WAL conflicts with queries
> accessing the target page on the standby, whether or not the data to b
.
"User was holding shared buffer pin for too long" sounds unusual to
me. Is this a bug? PostgreSQL version is 10.1 according to the user.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
18 matches
Mail list logo
