>"were not" is typical usage when stating a contrary-to-fact hypothetical.
> If the implementation (or you) didn’t do X, then Y bad thing could happen.
Really thanks for your kindly reply and explain.
Please forgive me for my poor English. Anyway, got it.
Regards,
Tang
Hi Andrew,
On Tue, May 18, 2021 at 08:15:35AM -0500, Brian Ye wrote:
> Thanks for the reply.
> Yes I also saw that after installing 64-bit, the 32-bit "bin" and "include"
> directories were removed.
> I think the content of the "include" are common for both 32- and 64-bit.
> Windows can run both 3
I revently tried to upgrade a standby following the documentation,
but I found it hard to understand, and it took me several tries to
get it right. This is of course owing to my lack of expertise with
rsync, but I think the documentation and examples could be clearer.
I think it would be a good i
t...@sss.pgh.pa.us wrote:
> PG Doc comments form writes:
>
>> small fix in description at [1] as follows
>
>> -If that were not done interrupted code that's currently inspecting errno
>> might see the wrong value.
>> +If that was not done interrupted code that's currently inspecting errno
>> mi
PG Doc comments form writes:
> small fix in description at [1] as follows
> -If that were not done interrupted code that's currently inspecting errno
> might see the wrong value.
> +If that was not done interrupted code that's currently inspecting errno
> might see the wrong value.
The existing
Hi Michael,
Thanks for the reply.
Yes I also saw that after installing 64-bit, the 32-bit "bin" and "include"
directories were removed.
I think the content of the "include" are common for both 32- and 64-bit.
Windows can run both 32-bit and
64-bit binaries so removing these 2 directories is probabl
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/source-conventions.html
Description:
small fix in description at [1] as follows
-If that were not done interrupted code that's currently inspecting errno
might see the wrong value.
+If th
Hi Moin,
On 5/18/21 3:30 AM, Moin Akther wrote:
> Dear Team,
>
>
>
> We are facing issue whenever application is connecting to pgpool 4^th Node.
This email address is for contributing to the PostgreSQL documentation[1].
The Pgpool project provides contact information on reporting issues here
On 2021/05/18 18:23, Masahiro Ikeda wrote:
On 2021/05/18 16:01, Fujii Masao wrote:
On 2021/05/18 13:20, Masahiro Ikeda wrote:
Tid Range Scan increments the tup_returned, and
pg_stat_all_tables.seq_tup_read is also incremented. I thought it's ok because
Tid Range Scan is like sequential sca
On 2021/05/18 16:01, Fujii Masao wrote:
> On 2021/05/18 13:20, Masahiro Ikeda wrote:
>> Tid Range Scan increments the tup_returned, and
>> pg_stat_all_tables.seq_tup_read is also incremented. I thought it's ok
>> because
>> Tid Range Scan is like sequential scan.
>
> Yes, you're right. One int
Dear Team,
We are facing issue whenever application is connecting to pgpool 4th Node.
We have 4 Applications and 4 pgpool nodes, at any point of time Application can
able to connect only 3 pgpool nodes, when we are starting application services
on 4 pgpool node we are getting below error messag
On 2021/05/18 13:20, Masahiro Ikeda wrote:
On 2021/05/17 20:46, Fujii Masao wrote:
On 2021/05/17 18:58, Masahiro Ikeda wrote:
On 2021/05/17 15:32, Fujii Masao wrote:
On 2021/05/14 17:00, Masahiro Ikeda wrote:
Hi,
I worried the difference between "tup_returned" and "tup_fetched" in
12 matches
Mail list logo
