On Wed, Mar 10, 2021 at 8:14 PM Thomas Munro wrote:
> On Wed, Mar 10, 2021 at 8:10 PM Michael Paquier wrote:
> > On Wed, Mar 10, 2021 at 04:52:01AM +, Thomas Munro wrote:
> > > pgbench: Refactor thread portability support.
> > >
> > > Instead of maintaining an incomplete emulation of POSIX th
Small debug message tweak
This makes the wording of the delete case match the update case.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/1657b37d7cce5c35e4c1d500f0a2f3736a087d82
Modified Files
--
src/backend/replication/logical/worker.c | 2 +-
1 file
On Wed, Mar 10, 2021 at 8:10 PM Michael Paquier wrote:
> On Wed, Mar 10, 2021 at 04:52:01AM +, Thomas Munro wrote:
> > pgbench: Refactor thread portability support.
> >
> > Instead of maintaining an incomplete emulation of POSIX threads for
> > Windows, let's use an extremely minimalist macro-
Hi Thomas,
On Wed, Mar 10, 2021 at 04:52:01AM +, Thomas Munro wrote:
> pgbench: Refactor thread portability support.
>
> Instead of maintaining an incomplete emulation of POSIX threads for
> Windows, let's use an extremely minimalist macro-based abstraction for
> now. A later patch will exte
Hi Thomas,
On Wed, Mar 10, 2021 at 04:52:01AM +, Thomas Munro wrote:
> pgbench: Improve time logic.
>
> Instead of instr_time (struct timespec) and the INSTR_XXX macros,
> introduce pg_time_usec_t and use integer arithmetic. Don't include the
> connection time in TPS unless using -C mode, bu
Move tablespace path re-creation from the makefiles to pg_regress
Moving this logic into pg_regress fixes a potential failure with
parallel tests when pg_upgrade and the main regression test suite both
trigger the makefile rule that cleaned up testtablespace/ under
src/test/regress. Even if pg_up
pgbench: Improve time logic.
Instead of instr_time (struct timespec) and the INSTR_XXX macros,
introduce pg_time_usec_t and use integer arithmetic. Don't include the
connection time in TPS unless using -C mode, but report it separately.
Author: Fabien COELHO
Reviewed-by: Kyotaro Horiguchi
Revi
pgbench: Synchronize client threads.
Wait until all pgbench threads are connected before benchmarking begins.
This fixes a problem where some connections could take a very long time
to be established because of lock contention from earlier connections,
making results unstable and bogus with high c
pgbench: Refactor thread portability support.
Instead of maintaining an incomplete emulation of POSIX threads for
Windows, let's use an extremely minimalist macro-based abstraction for
now. A later patch will extend this, without the need to supply more
complicated pthread emulation code. (There
Add missing pthread_barrier_t.
Supply a simple implementation of the missing pthread_barrier_t type and
functions, for macOS.
Discussion:
https://postgr.es/m/20200227180100.zyvjwzcpiokfsqm2%40alap3.anarazel.de
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/44bf3d
Fix valgrind issue in commit 05c8482f7f.
Initialize other newly added variables in max_parallel_hazard_context via
is_parallel_safe() because we don't check the parallel-safety of target
relations in that function.
Reported-by: Tom Lane as per buildfarm
Author: Amit Kapila
Discussion: https://pos
Amit Kapila writes:
> Enable parallel SELECT for "INSERT INTO ... SELECT ...".
skink (valgrind) is unhappy:
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ==4085668== VALGRINDERROR-BEGIN
==4085668== Conditional jump or move depend
Enable parallel SELECT for "INSERT INTO ... SELECT ...".
Parallel SELECT can't be utilized for INSERT in the following cases:
- INSERT statement uses the ON CONFLICT DO UPDATE clause
- Target table has a parallel-unsafe: trigger, index expression or
predicate, column default expression or check
On Tue, Mar 09, 2021 at 05:45:56PM -0500, Tom Lane wrote:
> I have no objection to the backend-side changes, since we can be sure
> those won't affect people until they do a major-version upgrade to v14.
> But the situation is squishier on the client side, and I don't really
> see that pulling out
Revert changes for SSL compression in libpq
This partially reverts 096bbf7 and 9d2d457, undoing the libpq changes as
it could cause breakages in distributions that share one single libpq
version across multiple major versions of Postgres for extensions and
applications linking to that.
Note that
Michael Paquier writes:
> On Tue, Mar 09, 2021 at 10:58:21AM -0500, Tom Lane wrote:
>> In short, I think I'm a vote for reverting to the v13 behavior.
> The libpq part is a good point, as it could be annoying for people to
> get a changing behavior once the libpq version changes for anything
> us
On Tue, Mar 09, 2021 at 10:58:21AM -0500, Tom Lane wrote:
> I'm fairly distressed by this patch series, and this proposed change in
> particular, because it seems to be going in very much the wrong direction.
> The objective ought to be simplification, but you're doing exactly the
> opposite.
Yeah
> On 9 Mar 2021, at 16:58, Tom Lane wrote:
> In short, I think I'm a vote for reverting to the v13 behavior.
Ok, then let us just go ahead and do that.
--
Daniel Gustafsson https://vmware.com/
Daniel Gustafsson writes:
> Having tried a number of different ways to fix this I think the least
> intrusive
> fix is to teach pg_upgrade and dblink about sslcompression, like how've
> already
> taught it about other options. Building any infrastructure to handle
> deprecated options and exten
Fix vague comment in jsonb documentation
The sample query fails because of an attempt to update the key of a numeric.
But the comment says it's just because of the missing object key. That's not
correct because jsonb subscription automatically adds missing keys.
Reported-by: Nikita Konev
Branch
> On 9 Mar 2021, at 12:19, Michael Paquier wrote:
>
> On Tue, Mar 09, 2021 at 12:26:15PM +0900, Michael Paquier wrote:
>> It looks like it is not that much a good idea to define it as a debug
>> option after all. So I guess that the attached would fix the failure,
>> where FDW servers can still
libpq: Remove deprecated connection parameters authtype and tty
The authtype parameter was deprecated and made inactive in commit
d5bbe2aca55bc8, but the environment variable was left defined and thus
tested with a getenv call even though the value is of no use. Also,
if it would exist it would b
On Tue, Mar 09, 2021 at 12:19:41PM +0100, Daniel Gustafsson wrote:
> While not pretty, I think that might be the least invasive option right now.
crake has turned back to green just now. Let's discuss that a bit
more, even if it does not feel like an issue we absolutely have to
address in this re
On Tue, Mar 09, 2021 at 12:26:15PM +0900, Michael Paquier wrote:
> It looks like it is not that much a good idea to define it as a debug
> option after all. So I guess that the attached would fix the failure,
> where FDW servers can still pass down the parameter at will for
> backward-compatibilit
> On 9 Mar 2021, at 04:26, Michael Paquier wrote:
> It looks like it is not that much a good idea to define it as a debug
> option after all. So I guess that the attached would fix the failure,
> where FDW servers can still pass down the parameter at will for
> backward-compatibility, and where
Switch back sslcompression to be a normal input field in libpq
Per buildfarm member crake, any servers including a postgres_fdw server
with this option set would fail to do a pg_upgrade properly as the
option got hidden in f9264d1 by becoming a debug option, making the
restore of the FDW server fa
26 matches
Mail list logo
