Support SSE2 intrinsics where available
SSE2 vector instructions are part of the spec for the 64-bit x86
architecture. Until now we have relied on the compiler to autovectorize
in some limited situations, but some useful coding idioms can only be
expressed explicitly via compiler intrinsics. To th
On Wed, Aug 3, 2022 at 11:02 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > Yeah, that can happen for bug fixes but may not be a big problem as it
> > just avoids duplicate code. If you and others want we can back this
> > now or otherwise, we can do it later if we really see the difficulty
> > l
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
Commit fac1b470a thought we could check for set-returning functions
by testing only the top-level node in an expression tree. This is
wrong in itself, and to make matters worse it encouraged others
to make the same mistake, by export
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
Commit fac1b470a thought we could check for set-returning functions
by testing only the top-level node in an expression tree. This is
wrong in itself, and to make matters worse it encouraged others
to make the same mistake, by export
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
Commit fac1b470a thought we could check for set-returning functions
by testing only the top-level node in an expression tree. This is
wrong in itself, and to make matters worse it encouraged others
to make the same mistake, by export
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
Commit fac1b470a thought we could check for set-returning functions
by testing only the top-level node in an expression tree. This is
wrong in itself, and to make matters worse it encouraged others
to make the same mistake, by export
Add another old commit to git-blame-ignore-revs.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/bc76f5ac483a08fe2a699ce82d31a9a07520d502
Modified Files
--
.git-blame-ignore-revs | 3 +++
1 file changed, 3 insertions(+)
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Reduce test runtime of src/test/modules/snapshot_too_old.
The sto_using_cursor and sto_using_select tests were coded to exercise
every permutation of their test steps, but AFAICS there is no value in
exercising more than one. This matters because each permutation costs
about six seconds, thanks t
Amit Kapila writes:
> Yeah, that can happen for bug fixes but may not be a big problem as it
> just avoids duplicate code. If you and others want we can back this
> now or otherwise, we can do it later if we really see the difficulty
> later.
IMO we've seldom regretted back-patching testing infra
On Wed, Aug 3, 2022 at 4:15 PM Alvaro Herrera wrote:
>
> On 2022-Aug-03, Amit Kapila wrote:
>
> > The new function wait_for_subscription_sync() can be used to replace the
> > above code. This eliminates duplicated code and makes it easier to write
> > future tests.
>
> Hmm, if you don't backpatch
On 2022-Aug-03, Amit Kapila wrote:
> The new function wait_for_subscription_sync() can be used to replace the
> above code. This eliminates duplicated code and makes it easier to write
> future tests.
Hmm, if you don't backpatch this, it might become a hurdle if we later
backpatch tests that use
Add wait_for_subscription_sync for TAP tests.
The TAP tests for logical replication in src/test/subscription are using
the following code in many places to make sure that the subscription is
synchronized with the publisher:
$node_publisher->wait_for_catchup('tap_sub');
$node_subscriber->poll_
18 matches
Mail list logo
