One of the things I notice which comes up in a profile of a pgbench -S
test is the generation of the command completion tag.
At the moment, this is done by a snprintf() call, namely:
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
tag == CMDTAG_INSERT ?
"%s 0 " UINT64_FORMAT : "%s "
On Tue, Dec 6, 2022 at 11:53 AM shiy.f...@fujitsu.com
wrote:
>
> Hi hackers,
>
> In logical decoding, when logical_decoding_work_mem is exceeded, the changes
> are
> sent to output plugin in streaming mode. But there is a restriction that the
> minimum value of logical_decoding_work_mem is 64kB.
On Wed, Dec 7, 2022 at 5:16 AM Peter Smith wrote:
+1 for the idea
>
> There is potential for lots of developer GUCs for testing/debugging in
> the area of logical replication but IMO it might be better to keep
> them all separated. Putting everything into a single
> 'logical_replication_mode'
On Fri, Dec 09, 2022 at 07:55:45PM -0800, Nathan Bossart wrote:
> Indeed. Patch attached.
Yep, thanks. I have exactly the same thing brewing in one of my
staging branches.
--
Michael
signature.asc
Description: PGP signature
.On Mon, 5 Dec 2022 at 23:18, John Naylor wrote:
>
>
> On Mon, Dec 5, 2022 at 3:02 PM David Rowley wrote:
> > Going by [2], the instructions are very different with each method, so
> > other machines with different latencies on those instructions might
> > show something different. I attached
On Fri, Dec 09, 2022 at 09:43:56PM -0500, Tom Lane wrote:
> Presumably it could be silenced by removing the semicolons after
> the new macro calls:
> The backslash after the last right brace means that the line
> following that is part of the macro body. This does no harm as
> long as said line
On Fri, Dec 09, 2022 at 09:43:56PM -0500, Tom Lane wrote:
> Presumably it could be silenced by removing the semicolons after
> the new macro calls:
>
> /* pg_stat_get_analyze_count */
> PG_STAT_GET_RELENTRY_INT64(analyze_count);
>
> /* pg_stat_get_autoanalyze_count */
>
Recently, buildfarm member elver has started spewing literally
thousands of $SUBJECT:
elver | 2022-12-10 01:17:29 | ../../src/include/utils/float.h:223:33:
warning: due to lvalue conversion of the controlling expression, association of
type 'volatile float' will never be selected
This series of patches has caused buildfarm member wrasse to
start complaining about "empty declarations":
wrasse| 2022-12-09 21:08:33 |
"/export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/pgstatfuncs.c",
line 56: warning: syntax error: empty
Andrew Dunstan writes:
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
>> As I said, I'll take a look at the datetime area. Do we
>> have any volunteers for other input functions?
> I am currently looking at the json types. I think that will be enough to
> let us rework the sql/json patches as
Hi,
On 2022-12-09 11:55:07 +0100, Daniel Gustafsson wrote:
> Our current hardcoded value for iteration count is 4096, which is based on a
> recommendation from RFC 7677. This is however the lower end of the scale, and
> is related to computing power in 2015 generation handheld devices. The
>
On Fri, Dec 09, 2022 at 05:50:00PM +0200, Heikki Linnakangas wrote:
>> The attached introduces a scram_iteration_count GUC with a default of 15000
>> (still conservative, from RFC7677) and a minimum of 4096. Since the
>> iterations
>> are stored per secret it can be altered with backwards
> On Dec 9, 2022, at 9:17 AM, Paul Ramsey wrote:
>
>
>> On Dec 8, 2022, at 8:29 PM, Michael Paquier wrote:
>>
>> On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
>>> Final tme, with fixes from cirrusci.
>>
>> Well, why not. Seems like you would use that a lot with PostGIS.
>>
On Fri, Dec 9, 2022 at 11:17 AM Amul Sul wrote:
> On Fri, Dec 9, 2022 at 9:08 PM Andrew Dunstan wrote:
> >
> >
> > On 2022-12-09 Fr 10:16, Tom Lane wrote:
> > > Andrew Dunstan writes:
> > >> On 2022-12-08 Th 21:59, Tom Lane wrote:
> > >>> Yeah, I was planning to take a look at that before
> On Dec 9, 2022, at 11:10 AM, Paul Ramsey wrote:
>
>
>
>> On Dec 9, 2022, at 11:01 AM, Joe Conway wrote:
>>
>> On 12/9/22 13:51, Paul Ramsey wrote:
On Dec 9, 2022, at 10:39 AM, Mark Dilger
wrote:
> On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
> Just a utility
> On Dec 9, 2022, at 11:01 AM, Joe Conway wrote:
>
> On 12/9/22 13:51, Paul Ramsey wrote:
>>> On Dec 9, 2022, at 10:39 AM, Mark Dilger
>>> wrote:
On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
Just a utility function to generate random numbers from a normal
distribution. I
On 12/9/22 13:51, Paul Ramsey wrote:
On Dec 9, 2022, at 10:39 AM, Mark Dilger wrote:
On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
Just a utility function to generate random numbers from a normal
distribution. I find myself doing this several times a year, and I am
sure I must not be the
> On Dec 9, 2022, at 10:39 AM, Mark Dilger wrote:
>
>> On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
>>
>> Just a utility function to generate random numbers from a normal
>> distribution. I find myself doing this several times a year, and I am
>> sure I must not be the only one.
>
>
On Fri, Dec 09, 2022 at 10:40:55AM -0800, Nathan Bossart wrote:
> On Fri, Dec 09, 2022 at 01:36:03PM +0900, Michael Paquier wrote:
>> On Thu, Dec 08, 2022 at 09:15:03AM -0800, Nathan Bossart wrote:
>>> The main idea behind this work is breaking out privileges into more
>>> granular pieces. If I
On Fri, Dec 09, 2022 at 01:36:03PM +0900, Michael Paquier wrote:
> On Thu, Dec 08, 2022 at 09:15:03AM -0800, Nathan Bossart wrote:
>> The main idea behind this work is breaking out privileges into more
>> granular pieces. If I want to create a role that only runs VACUUM on some
>> tables on the
> On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
>
> Just a utility function to generate random numbers from a normal
> distribution. I find myself doing this several times a year, and I am
> sure I must not be the only one.
Thanks for the patch. What do you think about these results?
+--
Hi,
TImescale makes use of inheritance in its partitioning implementation,
so we can't make use of the publish_via_partition_root publication
option during logical replication. We don't guarantee that the exact
same partitions exist on both sides, so that's a major roadblock for
our implementing
Hi,
On Wed, Dec 7, 2022 at 9:20 PM Peter Smith wrote:
> On Thu, Dec 8, 2022 at 10:49 AM samay sharma
> wrote:
> >
> ...
>
> > Thanks for the changes. See a few points of feedback below.
> >
>
> Patch v7 addresses this feedback. PSA.
>
> > > +
> > > + For logical replication,
>
> On Dec 8, 2022, at 8:29 PM, Michael Paquier wrote:
>
> On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
>> Final tme, with fixes from cirrusci.
>
> Well, why not. Seems like you would use that a lot with PostGIS.
>
> #include /* for ldexp() */
> +#include
Hi,
On 2022-12-09 14:53:10 +0100, Juan José Santamaría Flecha wrote:
> I've added an entry [1] in the commitfest so we don't miss this subject.
I indeed had forgotten. Pushed now.
Greetings,
Andres Freund
On Fri, Dec 9, 2022 at 9:08 PM Andrew Dunstan wrote:
>
>
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On 2022-12-08 Th 21:59, Tom Lane wrote:
> >>> Yeah, I was planning to take a look at that before walking away from
> >>> this stuff. (I'm sure not volunteering to
Hello hackers,
Is there a way to use exported snapshots in autocommit mode ?
Either something similar to defaults
in default_transaction_deferrable, default_transaction_isolation,
default_transaction_read_only
Or something that could be set in the function's SET part.
Context: I am working on
On 09/12/2022 12:55, Daniel Gustafsson wrote:
In the thread about user space SCRAM functions [0] I mentioned that it might be
wise to consider raising our SCRAM iteration count. The iteration count is an
important defence against brute-force attacks.
Our current hardcoded value for iteration
On 2022-12-09 Fr 10:16, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-12-08 Th 21:59, Tom Lane wrote:
>>> Yeah, I was planning to take a look at that before walking away from
>>> this stuff. (I'm sure not volunteering to convert ALL the input
>>> functions, but I'll do the datetime
Andrew Dunstan writes:
> On 2022-12-08 Th 21:59, Tom Lane wrote:
>> Yeah, I was planning to take a look at that before walking away from
>> this stuff. (I'm sure not volunteering to convert ALL the input
>> functions, but I'll do the datetime code.)
> Awesome. Perhaps if there are no more
On Tue, 2022-12-06 at 10:32 -0800, Andres Freund wrote:
> Hi,
>
> On 2022-11-26 22:22:15 -0500, Reid Thompson wrote:
> > rebased/patched to current master && current pg-stat-activity-
> > backend-memory-allocated
>
> This version fails to build with msvc, and builds with warnings on
> other
>
Hi,
On Friday, December 9, 2022 3:38 PM Kuroda, Hayato/黒田 隼人
wrote:
> Thanks for reporting! I have analyzed the problem and found the root cause.
>
> This feature seemed not to work on 32-bit OSes. This was because the
> calculation of delay_time was wrong. The first argument of this should
Hi!
I have looked at your patch and have a few questions.
110: static bool SafeCopying(CopyFromState cstate, ExprContext *econtext,
111: TupleTableSlot *myslot);
---
636: bool
637: SafeCopying(CopyFromState cstate, ExprContext *econtext,
TupleTableSlot *myslot)
Why is there no static keyword in
On Fri, 9 Dec 2022 at 16:54, adherent postgres <
adherent_postg...@hotmail.com> wrote:
> Hi Aleksander Alekseev
> I think the xids 32bit transformation project has been dragged on for too
> long. Huawei's openGauss referenced this patch to implement xids 64bit, and
> Postgrespro also implemented
Hi Pavel Borisov
Now the disk performance has been improved many times, and the capacity has
also been increased many times,The wal log already supports lz4 and zstd
compression, I think each XLOG record size will increase at least by 4 bytes
which is not a big problem.What about your
Hi, Adherent!
On Fri, 9 Dec 2022 at 17:54, adherent postgres
wrote:
>
> Hi Aleksander Alekseev
> I think the xids 32bit transformation project has been dragged on for too
> long. Huawei's openGauss referenced this patch to implement xids 64bit, and
> Postgrespro also implemented xids 64bit,
> So I'd vote for an evolutionary approach and give my +1 for
> undertaking efforts to first committing [1] to 16.
>
> [1]:
> https://www.postgresql.org/message-id/CAFiTN-uudj2PY8GsUzFtLYFpBoq_rKegW3On_8ZHdxB1mVv3-A%40mail.gmail.com
>
> Kind regards,
> Pavel Borisov,
> Supabase.
>
+1 Totally
Hi Aleksander Alekseev
I think the xids 32bit transformation project has been dragged on for too
long. Huawei's openGauss referenced this patch to implement xids 64bit, and
Postgrespro also implemented xids 64bit, which is enough to prove that their
worries are redundant.I think postgresql has
On Thu, Nov 17, 2022 at 3:35 AM Michael Paquier wrote:
>
> Ah, thanks. I was not following this point. Adding the host
> information for consistency makes sense, indeed.
>
I've added an entry [1] in the commitfest so we don't miss this subject.
[1] https://commitfest.postgresql.org/41/4057/
On Sun, 2022-12-04 at 13:09 -0600, Justin Pryzby wrote:
>
> This beavior is fixed. I re-factored and re-implented to use
> DefineIndex() for building indexes concurrently rather than
> reindexing.
> That makes the patch smaller, actually, and has the added benefit of
> splitting off the
Hi, Robert!
> Lest we miss the forest for the trees, there is an aspect of this
> patch that I find to be an extremely good idea and think we should try
> to get committed even if the rest of the patch set ends up in the
> rubbish bin. Specifically, there are a couple of patches in here that
>
On Fri, Dec 9, 2022 at 5:53 PM John Naylor wrote:
>
>
> On Fri, Dec 9, 2022 at 8:20 AM Masahiko Sawada wrote:
>
> > In the meanwhile, I've been working on vacuum integration. There are
> > two things I'd like to discuss some time:
> >
> > The first is the minimum of maintenance_work_mem, 1 MB.
On 2022-12-08 Th 21:59, Tom Lane wrote:
> Andres Freund writes:
>> On 2022-12-08 17:57:09 -0500, Tom Lane wrote:
>>> Given that this additional experimentation didn't find any holes
>>> in the API design, I think this is pretty much ready to go.
>> One interesting area is timestamp / datetime
Dear PostgreSQL Hackers,
Some time ago we faced a small issue in libpq regarding connections
configured in the pg_hba.conf as type *hostssl* and using *md5* as
authentication method.
One of our users placed the client certificates in ~/.postgresql/
(*postgresql.crt,**postgresql.key*), so
Hi adherent,
> Robertmhaas said that the project Zheap is
> dead（https://twitter.com/andy_pavlo/status/1590703943176589312）, which means
> that we cannot use Zheap to deal with the issue of xid wraparound and dead
> tuples in tables. The dead tuple issue is not a big deal because I can
On Thu, Dec 1, 2022 at 8:46 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> What is the status of this now? I think the other issue has been
> addressed?
>
Yes, that's addressed for MSVC builds. I think there are a couple of
pending issues for MinGW, but those should have
Hi Chris Travers
Robertmhaas said that the project Zheap is
dead（https://twitter.com/andy_pavlo/status/1590703943176589312）, which means
that we cannot use Zheap to deal with the issue of xid wraparound and dead
tuples in tables. The dead tuple issue is not a big deal because I can still
On Fri, Dec 9, 2022 at 2:57 PM Pavel Borisov wrote:
> > > Pushed, thanks to everyone!
> >
> > Thank you!
> > I've found a minor thing that makes the new test fail on sifaka and
> > longfin build farm animals. If role names in regression don't start
> > with "regress_" this invokes a warning. I've
Hi, Alexander!
> Hi, Alexander!
> > Pushed, thanks to everyone!
>
> Thank you!
> I've found a minor thing that makes the new test fail on sifaka and
> longfin build farm animals. If role names in regression don't start
> with "regress_" this invokes a warning. I've consulted in other
> modules
Hi, Alexander!
> Pushed, thanks to everyone!
Thank you!
I've found a minor thing that makes the new test fail on sifaka and
longfin build farm animals. If role names in regression don't start
with "regress_" this invokes a warning. I've consulted in other
modules regression tests e.g. in
On 2022-Dec-09, Amit Langote wrote:
> Pruning will be done afresh on every fetch of a given cached plan when
> CheckCachedPlan() is called on it, so the part_prune_results_list part
> will be discarded and rebuilt as many times as the plan is executed.
> You'll find a description around
On Fri, Dec 9, 2022 at 7:49 PM Alvaro Herrera wrote:
> On 2022-Dec-09, Amit Langote wrote:
> > On Fri, Dec 9, 2022 at 6:52 PM Alvaro Herrera
> > wrote:
> > > Remind me again why is part_prune_results_list not part of struct
> > > CachedPlan then? I tried to understand that based on comments
In the thread about user space SCRAM functions [0] I mentioned that it might be
wise to consider raising our SCRAM iteration count. The iteration count is an
important defence against brute-force attacks.
Our current hardcoded value for iteration count is 4096, which is based on a
recommendation
On 2022-Dec-09, Amit Langote wrote:
> On Fri, Dec 9, 2022 at 6:52 PM Alvaro Herrera wrote:
> > Remind me again why is part_prune_results_list not part of struct
> > CachedPlan then? I tried to understand that based on comments upthread,
> > but I was unable to find anything.
>
> It used to be
On Fri, Dec 9, 2022 at 8:57 AM li jie wrote:
>
> It is worth considering whether temporary objects, such as tables,
> indexes, and sequences,
> should be replicated to the subscriber side.
>
> Like temp tables, different sessions create their own temp tables.
> If they are all transferred to the
On Fri, Dec 9, 2022 at 6:52 PM Alvaro Herrera wrote:
> On 2022-Dec-09, Amit Langote wrote:
> > On Wed, Dec 7, 2022 at 4:00 AM Alvaro Herrera
> > wrote:
> > > I find the API of GetCachedPlans a little weird after this patch.
>
> > David, in his Apr 7 reply on this thread, also sounded to suggest
Thanks for the review!
On 12/8/22 12:19, Melih Mutlu wrote:
Hi Christoph,
I just took a quick look at your patch.
Some suggestions:
+ else if (Matches("ALTER", "VIEW", MatchAny, "SET", "("))
+ COMPLETE_WITH_LIST(view_optional_parameters);
+ /* ALTER VIEW xxx RESET ( yyy
On Wed, Dec 7, 2022 at 4:36 PM Alexander Korotkov wrote:
> On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov wrote:
> > On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov
> > wrote:
> > >
> > > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> > > wrote:
> > > > On Mon, Dec 5, 2022 at 8:18 PM Tom
On Fri, 9 Dec 2022 at 10:02, Alvaro Herrera wrote:
>
> On 2022-Dec-08, Nathan Bossart wrote:
>
> > On Thu, Dec 08, 2022 at 03:26:52PM +, Dean Rasheed wrote:
> > > While testing MERGE, I noticed that it supports inheritance
> > > hierarchies and the ONLY keyword, but that isn't documented.
On 2022-Dec-08, Nathan Bossart wrote:
> On Thu, Dec 08, 2022 at 03:26:52PM +, Dean Rasheed wrote:
> > While testing MERGE, I noticed that it supports inheritance
> > hierarchies and the ONLY keyword, but that isn't documented. Attached
> > is a patch to merge.sgml, borrowing text from
On Fri, Dec 9, 2022 at 2:47 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> 0003-Move-some-static-assertions-to-better-places.patch
>
> This moves some that I thought were suboptimally placed but it could be
> debated or refined.
+ * We really want ItemPointerData to be
On 2022-Dec-09, Amit Langote wrote:
> On Wed, Dec 7, 2022 at 4:00 AM Alvaro Herrera wrote:
> > I find the API of GetCachedPlans a little weird after this patch.
> David, in his Apr 7 reply on this thread, also sounded to suggest
> something similar.
>
> Hmm, I was / am not so sure if
If we intend to generate a memoize node atop a path, we need some kind
of cache key. Currently we search the path's parameterized clauses and
its parent's lateral_vars for that. ISTM this is not sufficient because
their might be lateral references derived from PlaceHolderVars, which
can also act
Hi,
WALRead() currently reads WAL from the WAL file on the disk, which
means, the walsenders serving streaming and logical replication
(callers of WALRead()) will have to hit the disk/OS's page cache for
reading the WAL. This may increase the amount of read IO required for
all the walsenders put
On Fri, Dec 9, 2022 at 8:20 AM Masahiko Sawada
wrote:
> In the meanwhile, I've been working on vacuum integration. There are
> two things I'd like to discuss some time:
>
> The first is the minimum of maintenance_work_mem, 1 MB. Since the
> initial DSA segment size is 1MB
On 09.12.2022 09:46, Pavel Stehule wrote:
I don't like the idea about possible replacement of INTO STRICT by INTO
+ extra warnings.
Handling exceptions is significantly more expensive than in Oracle, and
using INTO without STRICT with the next test IF NOT FOUND THEN can save
one safepoint
Thanks for the review.
On Wed, Dec 7, 2022 at 4:00 AM Alvaro Herrera wrote:
> I find the API of GetCachedPlans a little weird after this patch. I
> think it may be better to have it return a pointer of a new struct --
> one that contains both the CachedPlan pointer and the list of pruning
>
On Fri, Dec 9, 2022 at 3:05 PM Amit Kapila wrote:
>
> On Fri, Dec 9, 2022 at 7:45 AM Peter Smith wrote:
> >
> > On Thu, Dec 8, 2022 at 7:43 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 8, 2022 at 4:42 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Dec 8, 2022 at 12:42 PM
68 matches
Mail list logo
