Bonjour Michaël,
I don't see why not. Perhaps this could be done for pgbench and
oid2name as well?
This is for pgbench.
I did not found a TAP test in pg_upgrade, I do not think that it is worth
creating one for that purpose. The "test.sh" script does not seem
appropriate for this kind of
On Thu, Aug 29, 2019 at 08:14:54AM +0200, Fabien COELHO wrote:
> Attached v7 does create uint64 overflow inline functions. The stuff yet is
> not moved to "common/int.c", a file which does not exists, even if
> "common/int.h" does.
Thanks for the new version. I have begun reviewing your patch, an
Michaël,
attached is a first cut that I would like to commit separately which
adds all the compatibility overflow routines to int.h for uint16, uint32
and uint64 with all the fallback implementations (int128-based method
added as well if available). I have also grouped at the top of the file
Hello Thomas,
I was doing some testing for the scenario where the undo written by a
transaction overflows to multiple undo logs. For that I've modified
the following macro:
#define UndoLogMaxSize (1024 * 1024) /* 1MB undo log size */
(I should have used the provided pg_force_switch_undo though..)
On Thu, Aug 29, 2019 at 3:17 PM Jeevan Ladhe
wrote:
> Hi Jeevan
>
> I had a look at the patch and this seems correct to me.
>
Thanks, Jeevan Ladhe.
>
> Few minor comments:
>
> + /* Check fread() error. */
> + CHECK_FREAD_ERROR(fp, pathbuf);
> +
>
> The comments above the macro call at both the
On Thu, Aug 15, 2019 at 12:48 PM Tatsuro Yamada
wrote:
>
> Hi Michael, Alvaro and Robert!
>
> On 2019/08/14 11:52, Michael Paquier wrote:
> > On Wed, Aug 14, 2019 at 11:38:01AM +0900, Tatsuro Yamada wrote:
> >> On 2019/08/13 14:40, Tatsuro Yamada wrote:
> >>> On 2019/08/02 3:43, Alvaro Herrera wro
> 30 авг. 2019 г., в 3:47, Alexander Korotkov
> написал(а):
>
> 1) Binary search in non-leaf pages instead of probing each key is much faster.
That's a neat idea, but key union breaks ordering, even for z-order.
for two sets of tuples X and Y
if for any i,o from N, Xi < Yo
does not guaranty u
Hello Andres,
Just my 0.02 €:
There's been a lot of complaints over the years about how annoying it is
to keep the out/read/copy/equalfuncs.c functions in sync with the actual
underlying structs.
There've been various calls for automating their generation, but no
actual patches that I am awar
>
> Fixed both comments in the attached patch.
>
Thanks, the patch looks good to me.
Regards,
Jeevan Ladhe
Hallo Andres,
There've been various calls for automating their generation, but no
actual patches that I am aware of.
I started something a while back
I have found this thread:
https://www.postgresql.org/message-id/flat/E1cq93r-0004ey-Mp%40gemulon.postgresql.org
It seems that comments from
Hi,
I am doing some testing on pg_basebackup and pg_combinebackup patches. I
have also tried to create tap test for pg_combinebackup by taking
reference from pg_basebackup tap cases.
Attaching first draft test patch.
I have done some testing with compression options, both -z and -Z level is
worki
Here are some comments:
+/* The reference XLOG position for the incremental backup. */
+static XLogRecPtr refptr;
As Robert already pointed we may want to pass this as parameter around
instead
of a global variable. Also, can be renamed to something like:
incr_backup_refptr.
I see in your earlie
Hi,
> > This patch has been around for some time now, the last version fails to
> > apply cleanly and in-depth reviews have happened. I am moving that to
> > the next CF, waiting on its author.
>
> Unfortunately, nothing was changed since then, so there is already some amount
> of unaddressed rev
On Fri, Aug 30, 2019 at 10:06:11AM +0200, Fabien COELHO wrote:
> Patch applies cleanly, compiles, "make check" ok, but the added functions
> are not used (yet).
Thanks.
> I think that factoring out comments is a good move.
>
> For symmetry and efficiency, ISTM that uint16 mul overflow could use
Fabien COELHO writes:
> Could we maintain coverage by adding a TAP test? See 1 liner attached.
Is this issue *really* worth expending test cycles on forevermore?
Test cycles are not free, and I see zero reason to think that a
check of this sort would ever catch any bugs. Now, if you had a
way t
Hello Tom,
Could we maintain coverage by adding a TAP test? See 1 liner attached.
Is this issue *really* worth expending test cycles on forevermore?
With this argument consistently applied, postgres code coverage is
consistently weak, with 25% of the code never executed, and 15% of
functi
Fabien COELHO writes:
>> Is this issue *really* worth expending test cycles on forevermore?
> With this argument consistently applied, postgres code coverage is
> consistently weak, with 25% of the code never executed, and 15% of
> functions never called. "psql" is abysmal, "libpq" is really we
Michaël,
For symmetry and efficiency, ISTM that uint16 mul overflow could use uint32
and uint32 could use uint64, and the division-based method be dropped in
these cases.
Yes, the division would be worse than the other. What do you think
about using the previous module I sent and measure how
Is this issue *really* worth expending test cycles on forevermore?
With this argument consistently applied, postgres code coverage is
consistently weak, with 25% of the code never executed, and 15% of
functions never called. "psql" is abysmal, "libpq" is really weak.
It's all a question of
FWIW my understanding is that the speedup comes mostly from
elimination of
the serialization to a file. That however requires savepoints to handle
aborts of subtransactions - I'm pretty sure I'd be trivial to create a
workload where this will be much slower (with many aborts of large
subtran
> Attached is a very hackish patch to implement this. It works like this:
>
> # (assuming you have a primary already running somewhere)
> initdb -D data2 --replica
> $EDITOR data2/postgresql.conf # set primary_conninfo
> pg_ctl -D data2 start
Attached is an updated patch for thi
On Thu, Aug 29, 2019 at 10:41 AM Jeevan Ladhe
wrote:
> Due to the inherent nature of pg_basebackup, the incremental backup also
> allows taking backup in tar and compressed format. But, pg_combinebackup
> does not understand how to restore this. I think we should either make
> pg_combinebackup sup
22 matches
Mail list logo
