On Fri, Jul 2, 2021 at 8:16 PM Robert Haas wrote:
>
> On Wed, Jun 30, 2021 at 11:46 PM Greg Nancarrow wrote:
> > I personally think "(b) provide an option to the user to specify
> > whether inserts can be parallelized on a relation" is the preferable
> > option.
> > There seems to be too many
Hello Tatsuo-san,
So overall gain by the patch is around 15%, whereas the last test before
the commit was 14%. It seems the patch is still beneficial after the
commit.
Yes, that's good!
I had a quick look again, and about the comment:
/*
* If partitioning is not enabled and server
On Fri, Jul 2, 2021 at 2:32 PM John Naylor wrote:
> I suspect if we experiment on two extremes of type "heaviness" (accessing and
> comparing trivial or not), such as uint32 and tuplesort, we'll have a pretty
> good idea what the parameters should be, if anything different. I'll do some
>
On Sat, Jul 3, 2021 at 10:03 PM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > The patch basically looks good to me except a minor comment to have a
> > local variable for var->varattno which makes the code shorter.
>
> Here's a restructured version that uses rangetable data for the
>
On Thu, Jun 3, 2021 at 8:36 AM Greg Nancarrow wrote:
>
> On Fri, May 21, 2021 at 2:46 PM Greg Nancarrow wrote:
> >
> > On Thu, May 20, 2021 at 2:45 PM Ivan Panchenko wrote:
> > >
> > > I have upgraded the patch for the 14th version.
> > >
> >
> > I have some feedback on the patch:
> >
>
> I've
On Wed, Apr 7, 2021 at 12:13 PM osumi.takami...@fujitsu.com
wrote:
>
> Hi
>
>
> Mainly affected by a commit 9de9294,
> I've fixed minor things to rebase the patch.
> All modifications I did are cosmetic changes and
> a little bit of documentation updates.
> Please have a look at attached v09.
>
After this commit:
https://git.postgresql.org/pg/commitdiff/8e03eb92e9ad54e2f1ed8b5a73617601f6262f81
I was worried about that the benefit of COPY FREEZE patch is somewhat
reduced or gone. So I ran a pgbench test again.
Current master:
$ pgbench -i -s 100 test
:
:
done in 20.23 s (drop tables
Hi Simon,
>> Hello Simon,
>>
>> Indeed.
>>
>> There is already a "ready" patch in the queue, see:
>>
>> https://commitfest.postgresql.org/33/3034/
>
> Ah, my bad. I withdraw this patch, apologies Tatsuo-san.
No problem at all. Thank you for looking into the issue.
--
Tatsuo Ishii
SRA
Hi,
I was looking at :
Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).
In check_safe_enum_use():
+ if (!TransactionIdIsInProgress(xmin) &&
+ TransactionIdDidCommit(xmin))
+ return;
Since the condition would be true only when TransactionIdDidCommit()
returns
I wrote:
> Andrew Dunstan writes:
>> Seems reasonable. I don't have a CCA animal any more, but I guess I
>> could set up a test.
> I can run a test here --- I'll commandeer sifaka for awhile,
> since that's the fastest animal I have.
Done, and here's the results:
Traditional way
Noah Misch writes:
> On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
>> What I'm now thinking about is restricting the test to only be run on
>> platforms where use of foo.a libraries is deprecated, so that we can
>> be pretty sure that we won't hit this situation. Even if we only
>>
On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
> I'd imagined leaving, e.g., psprintf.c out of libpgcommon_shlib.a.
> But if someone mistakenly introduced a psprintf call into libpq,
> it'd still compile just fine; the symbol would be resolved against
> psprintf in the calling
> On 28 Jun 2021, at 16:45, Daniel Gustafsson wrote:
>
>> On 28 Jun 2021, at 16:02, Tom Lane wrote:
>
>> Ugh. Shouldn't we instead modify the format to read not more than
>> two characters? Even if this is safe on non-malicious input, it
>> doesn't seem like good style.
>
> No disagreement,
On Sat, 2021-07-03 at 14:06 +0500, Andrey Borodin wrote:
> > But until you've disabled sync rep, the primary will essentially be
> > down for writes whether using this new feature or not. Even if you
> > can
> > terminate some backends to try to free space, the application will
> > just
> > make
On Thu, Jul 1, 2021 at 9:23 PM Bruce Momjian wrote:
> Agreed. Please remove them or I can do it.
Done, and also changed next release to "15".
--
John Naylor
EDB: http://www.enterprisedb.com
Bharath Rupireddy writes:
> The patch basically looks good to me except a minor comment to have a
> local variable for var->varattno which makes the code shorter.
Here's a restructured version that uses rangetable data for the
simple-relation case too. I also modified the relevant test cases
so
Bharath Rupireddy writes:
> Isn't it better to have the below comment before
> slot_store_error_callback, similar to what's there before
> conversion_error_callback in v7-0002.
> * Note that this function mustn't do any catalog lookups, since we are in
> * an already-failed transaction.
Not
Le 01/07/2021 à 18:47, Tom Lane a écrit :
> Nicolas CHAHWEKILIAN writes:
>> As far as I am concerned, I am totally awaiting for this kind of feature
>> exposed here, for one single reason at this time : the extension
>> pg_statement_rollback will be much more valuable with the ability of
>>
1. PostgreSQL source uses `uint64` and `uint32`, but not
`uint64_t`/`uint32_t`
Indeed you are right. Attached v6 does that as well.
--
Fabien.diff --git a/contrib/file_fdw/file_fdw.c b/contrib/file_fdw/file_fdw.c
index 2c2f149fb0..146b524076 100644
--- a/contrib/file_fdw/file_fdw.c
+++
Hello Yura,
1. PostgreSQL source uses `uint64` and `uint32`, but not
`uint64_t`/`uint32_t`
2. I don't see why pg_prng_state could not be `typedef uint64
pg_prng_state[2];`
It could, but I do not see that as desirable. From an API design point of
view we want something clean and abstract,
I wrote:
> Hmmm ... mine is 8.4.1.
> I'm about to go out to dinner, but will check into this with some
> newer gcc versions later.
Tried --enable-coverage on Fedora 34 (with gcc 11.1.1) and sure
enough there's an exit() call being inserted. I've pushed a fix
to just disable the check altogether
On 12.03.21 08:51, Peter Eisentraut wrote:
On 11.03.21 11:41, Daniel Gustafsson wrote:
.. and apply the padding changes as proposed in a patch upthread like
this (these
work for all OpenSSL versions I've tested, and I'm rather more puzzled
as to
why we got away with not having them in the
I wrote:
> I'm now wondering about applying the test to *.o in libpq,
> as well as libpgport_shlib.a and libpgcommon_shlib.a.
> The latter would require some code changes, and it would make
> the prohibition extend further than libpq alone. On the bright
> side, we could reinstate the check for
Yura Sokolov writes:
> 2. I don't see why pg_prng_state could not be `typedef uint64
> pg_prng_state[2];`
Please no. That sort of typedef behaves so weirdly that it's
a foot-gun.
regards, tom lane
Noah Misch writes:
> On Fri, Jul 02, 2021 at 11:20:17AM -0400, Tom Lane wrote:
>> Ugh. What in the world is producing those references?
> Those come from a statically-linked libldap_r:
Blech! I wonder if there is some way to avoid counting that.
It's not really hard to imagine that such a
Hi:
I'd start to work on UniqueKey again, it would be great that we can target
it
to PG 15. The attached patch is just for the notnull_attrs. Since we can't
say
a column is nullable or not without saying in which resultset, so I think
attaching
it to RelOptInfo is unavoidable. Here is how my
On 21.06.21 07:22, Thomas Munro wrote:
I'm not personally against the proposed change. I'll admit there is
something annoying about Apple's environment working in a way that
doesn't suit traditional configure macros that have been the basis of
portable software for a few decades, but when all's
On 21.06.21 13:32, Greg Nancarrow wrote:
On Mon, Jun 21, 2021 at 8:32 PM David Rowley wrote:
It might be worth putting in a comment to mention that the check is
not needed. Just in case someone looks again one day and thinks the
checks are missing.
Probably best to put this in the July
On 04.06.21 17:09, Aleksander Alekseev wrote:
I decided to add the patch to the nearest commitfest.
With respect to the commit fest submission, I don't think there is
consensus right now to add this. I think people would prefer that this
dictionary facility be somehow made available in the
Fabien COELHO wrote 2021-07-03 11:45:
And a v5 where an unused test file does also compile if we insist.
About patch:
1. PostgreSQL source uses `uint64` and `uint32`, but not
`uint64_t`/`uint32_t`
2. I don't see why pg_prng_state could not be `typedef uint64
pg_prng_state[2];`
3. Then
Attached is a more complete patch, with updated docs and tests.
I chose to allow the scale to be in the range -1000 to 1000, which, to
some extent, is quite arbitrary. The upper limit of 1000 makes sense,
because nearly all numeric computations (other than multiply, add and
subtract) have that as
> 3 июля 2021 г., в 01:15, Jeff Davis написал(а):
>
> On Fri, 2021-07-02 at 11:39 +0500, Andrey Borodin wrote:
>> If the failover happens due to unresponsive node we cannot just turn
>> off sync rep. We need to have some spare connections for that (number
>> of stuck backends will skyrocket
Here is a v4, which:
- moves the stuff to common and fully removes random/srandom (Tom)
- includes a range generation function based on the bitmask method (Dean)
but iterates with splitmix so that the state always advances once (Me)
And a v5 where an unused test file does also compile if
Hello Dean & Tom,
Here is a v4, which:
- moves the stuff to common and fully removes random/srandom (Tom)
- includes a range generation function based on the bitmask method (Dean)
but iterates with splitmix so that the state always advances once (Me)
--
Fabien.diff --git
34 matches
Mail list logo
