> "Looks like"?
I cannot find the reference, but I've read a while back that a well-known
company from Redwood uses it for their in-memory columnar storage. That might
have just been a rumor or might have been research only - not sure. It does not
really matter anyways.
> SortTuples are curren
Hi,
On 9/28/22 7:52 AM, Michael Paquier wrote:
On Fri, Aug 26, 2022 at 10:43:43AM +0200, Drouvot, Bertrand wrote:
During the work in [1] we created a new TAP test to test the SYSTEM_USER
behavior with peer authentication.
It turns out that there is currently no TAP test for the peer
authentica
On Wed, Sep 28, 2022 at 09:12:57AM +0200, Drouvot, Bertrand wrote:
> Maybe the variable name should be system_user instead or should we use
> another way to get the "SYSTEM_USER" to be used in the map?
Hmm, indeed. It would be more reliable to rely on the contents
returned by getpeereid()/getpwui
On Wed, Sep 28, 2022 at 04:47:09AM +, kuroda.hay...@fujitsu.com wrote:
> PSA fix patch. Note that PromptInterruptContext.enabled was also fixed
> because it is substituted from sigint_interrupt_enabled.
Good point. Thanks for the patch, this looks consistent!
--
Michael
signature.asc
Descri
On Wed, Sep 28, 2022 at 1:18 PM John Naylor
wrote:
> [stuff about size classes]
I kind of buried the lede here on one thing: If we only have 4 kinds
regardless of the number of size classes, we can use 2 bits of the pointer
for dispatch, which would only require 4-byte alignment. That should make
On Tue, Sep 27, 2022 at 9:50 AM Kyotaro Horiguchi
wrote:
> Regarding the the patch, pg_rewind starts reading segments from the
> divergence point back to the nearest checkpoint, then moves foward
> during rewinding. So, the fact that SimpleXLogPageRead have read a
> segment suggests that the segm
On Wed, Sep 28, 2022 at 11:30 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 27 Sep 2022 12:19:35 +0200, Alvaro Herrera
> wrote in
> > Yeah, since you're changing another word in that line, it's ok to move
> > the parameter line off-string. (If you were only changing the parameter
> > to %s and there
Just rebased.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 8c0d5bd7b519149059d1b2b86a93ffe509e09b9b Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Tue, 19 Jul 2022 13:23:01 +0900
Subject: [PATCH v24 1/2] In-place table persistence change
Even though ALTER TABLE S
On Wed, Sep 28, 2022 at 9:40 AM Dilip Kumar wrote:
>
> On Wed, Sep 28, 2022 at 2:59 AM Tom Lane wrote:
> >
> > ... also, lapwing's not too happy [1]. The alter_table test
> > expects this to yield zero rows, but it doesn't:
>
> By looking at regression diff as shown below, it seems that we are
>
On Tues, Sep 27, 2022 at 16:45 PM Peter Smith wrote:
> Here are my review comments for the HEAD_v11-0001 patch:
Thanks for your comments.
> ==
>
> 1. General - Another related bug?
>
> In [1] Hou-san wrote:
>
> For another case you mentioned (via_root used when publishing child)
> CREATE
Hi!
I think, this patch was marked as "Waiting on Author", probably, by
mistake. Since recent changes were done without any significant code
changes and CF bot how happy again.
I'm going to move it to RfC, could I? If not, please tell why.
--
Best regards,
Maxim Orlov.
On Wed, Sep 28, 2022 at 9:23 AM Thomas Munro wrote:
>
> Hi Dilip,
>
> I am very happy to see these commits. Here's some belated review for
> the tombstone-removal patch.
>
> > v7-0004-Don-t-delay-removing-Tombstone-file-until-next.patch
>
> More things you can remove:
>
> * sync_unlinkfiletag in
Hi hackers,
> I think, this patch was marked as "Waiting on Author", probably, by mistake.
> Since recent changes were done without any significant code changes and CF
> bot how happy again.
>
> I'm going to move it to RfC, could I? If not, please tell why.
I restored the "Ready for Committer"
On 2022-Sep-28, Amit Kapila wrote:
> On Wed, Sep 28, 2022 at 11:30 AM Kyotaro Horiguchi
> wrote:
> > It looks tome that the errmsg and errordetail are reversed. Isn't the
> > following order common?
> >
> > >errmsg("schemas cannot be added to or dropped from publication
> > > \"%s\".",
At Wed, 28 Sep 2022 10:09:05 +0200, Polina Bungina wrote in
> On Tue, Sep 27, 2022 at 9:50 AM Kyotaro Horiguchi
> wrote:
>
> > Regarding the the patch, pg_rewind starts reading segments from the
> > divergence point back to the nearest checkpoint, then moves foward
> > during rewinding. So, the
At Wed, 28 Sep 2022 13:47:25 +0530, Amit Kapila wrote
in
> On Wed, Sep 28, 2022 at 11:30 AM Kyotaro Horiguchi
> wrote:
> > I'm fine with that. By the way, related to the area, I found the
> > following error messages.
> >
> > >errmsg("publication \"%s\" is defined as FOR ALL TABLES",
>
On Wed, Sep 28, 2022 at 10:09 AM Bharath Rupireddy
wrote:
>
> Here's what I think - for backup functions, we
> can have the new memory context child of TopMemoryContext and for
> perform_base_backup(), we can have the memory context child of
> CurrentMemoryContext. With PG_TRY()-PG_FINALLY()-PG_EN
At Wed, 28 Sep 2022 10:46:41 +0200, Alvaro Herrera
wrote in
> On 2022-Sep-28, Amit Kapila wrote:
>
> > On Wed, Sep 28, 2022 at 11:30 AM Kyotaro Horiguchi
> > wrote:
>
> > > It looks tome that the errmsg and errordetail are reversed. Isn't the
> > > following order common?
> > >
> > > >
Hi,
While reviewing the “Fast COPY FROM based on batch insert" patch, I
noticed this comment introduced in commit b663a4136:
/*
* If a certain number of tuples have already been accumulated, or
* a tuple has come for a different relation than that for the
On Wed, Sep 28, 2022 at 9:26 PM Dilip Kumar wrote:
> It was a silly mistake, I used the F_OIDEQ function instead of
> F_INT8EQ. Although this was correct on the 0003 patch where we have
> removed the tablespace from key, but got missed in this :(
>
> I have locally reproduced this in a 32 bit mach
Am 26.09.22 um 22:16 schrieb Tom Lane:
With our current PRNG infrastructure it doesn't cost much to have
a separate PRNG for every purpose. I don't object to having
array_shuffle() and array_sample() share one PRNG, but I don't
think it should go much further than that.
Thanks for your thoug
Hi,
On 9/28/22 5:28 AM, Michael Paquier wrote:
On Tue, Sep 27, 2022 at 03:38:49PM -0700, Jacob Champion wrote:
On 9/26/22 06:29, Drouvot, Bertrand wrote:
Since there are only internal clients to the API, I'd argue this makes
more sense as an Assert(authn_id != NULL), but I don't think it's a
de
On Wed, Sep 28, 2022 at 11:57 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > Btw, I think the reason for the bus error on wrasse is the same as
> > what is creating failure on longfin[1], I mean this unaligned access
> > is causing Bus error during startup, IMHO.
>
> Maybe, but there's not a lot
On Tue, Sep 27, 2022 at 7:34 PM Robert Haas wrote:
> On Tue, Sep 27, 2022 at 2:53 AM Rushabh Lathia
> wrote:
> > Yes, I was also thinking to avoid the duplicate logic but couldn't found
> > a way. I did the quick testing with the patch, and reported test is
> working
> > fine. But "make chec
On Wed, Sep 28, 2022 at 1:48 AM Thomas Munro wrote:
> FTR CI reported that cpluspluscheck failure and more[1], so perhaps we
> just need to get clearer agreement on the status of CI, ie a policy
> that CI had better be passing before you get to the next stage. It's
> still pretty new...
Yeah, I
On 2022-09-20 15:15, bt22nakamorit wrote:
I edited the documentation for ON_ERROR_STOP.
Any other suggestions?
Thanks for the patch!
if (result == 127 || result == -1)
{
pg_log_error("\\!: failed");
return false;
}
else if (result != 0) {
pg_log_error("comman
On Wed, Sep 28, 2022 at 1:15 AM Tom Lane wrote:
> Dilip Kumar writes:
> > wrasse is also failing with a bus error,
>
> Yeah. At this point I think it's time to call for this patch
> to get reverted. It should get tested *off line* on some
> non-Intel, non-64-bit, alignment-picky architectures b
With our current PRNG infrastructure it doesn't cost much to have
a separate PRNG for every purpose. I don't object to having
array_shuffle() and array_sample() share one PRNG, but I don't
think it should go much further than that.
Thanks for your thoughts, Tom. I have a couple of questions.
On Tue, Sep 27, 2022 at 5:29 PM Tom Lane wrote:
> ... also, lapwing's not too happy [1]. The alter_table test
> expects this to yield zero rows, but it doesn't:
>
> SELECT m.* FROM filenode_mapping m LEFT JOIN pg_class c ON c.oid = m.oid
> WHERE c.oid IS NOT NULL OR m.mapped_oid IS NOT NULL;
>
On Tue, Sep 27, 2022 at 5:50 PM Tom Lane wrote:
> Maybe it wouldn't have any great impact. I don't know, but I don't
> think it's incumbent on me to measure that. You or the patch author
> should have had a handle on that question *before* committing.
I agree. I should have gone through and che
Hi,
Attached is a draft of the PostgreSQL 15 RC 1 release announcement.
Please provide feedback no later than 2022-09-29 0:00 AoE.
Thanks,
Jonathan
The PostgreSQL Global Development Group announces that the first release
candidate of PostgreSQL 15 is now available for download. As a release
c
On Wed, Sep 28, 2022 at 9:16 AM Robert Haas wrote:
> I agree. I should have gone through and checked that every place where
> RelFileLocator got embedded in some larger struct, there was no
> problem with making it bigger and increasing the alignment
> requirement. I'll go back and do that as soon
Hi all,
The patch needed a rebase due to recent changes on pg_buffercache.
You can find the updated version attached.
Best,
Melih
v12-0001-Added-pg_buffercache_summary-function.patch
Description: Binary data
Fabien COELHO writes:
>> Thanks for your thoughts, Tom. I have a couple of questions. Should we
>> introduce a new seed function for the new PRNG state, used by
>> array_shuffle()
>> and array_sample()? What would be a good name? Or should those functions use
>> pg_global_prng_state? Is it saf
Regards,
Zhang Mingli
On Sep 28, 2022, 21:50 +0800, Melih Mutlu , wrote:
> Hi all,
>
> The patch needed a rebase due to recent changes on pg_buffercache.
> You can find the updated version attached.
>
> Best,
> Melih
>
>
```
+
+ if (buffers_used != 0)
+ usagecount_avg = usagecount_avg / buff
Zhang Mingli , 28 Eyl 2022 Çar, 17:31 tarihinde şunu
yazdı:
> Why compute usagecount_avg twice?
>
I should have removed the first one, but I think I missed it.
Nice catch.
Attached an updated version.
Thanks,
Melih
v13-0001-Added-pg_buffercache_summary-function.patch
Description: Binary data
Etsuro Fujita writes:
> I think the “or a tuple has come for a different relation than that
> for the accumulated tuples" part in the comment is a leftover from an
> earlier version of the patch [1]. As the code shows, we do not handle
> that case anymore, so I think we should remove that part fr
Hi,
xlog.c currently has ~9000 LOC, out of which ~700 LOC is backup
related, making the file really unmanageable. The commit
7d708093b7400327658a30d1aa1d5e284d37622c added new files
xlogbackup.c/.h for hosting all backup related code eventually. I
propose to move all the backp related code from xl
On Wed, Sep 28, 2022 at 8:21 AM Rushabh Lathia wrote:
> On Tue, Sep 27, 2022 at 7:34 PM Robert Haas wrote:
>> On Tue, Sep 27, 2022 at 2:53 AM Rushabh Lathia
>> wrote:
>> > Yes, I was also thinking to avoid the duplicate logic but couldn't found
>> > a way. I did the quick testing with the patc
Hi,
On Sep 28, 2022, 22:41 +0800, Melih Mutlu , wrote:
>
>
> Zhang Mingli , 28 Eyl 2022 Çar, 17:31 tarihinde şunu
> yazdı:
> > Why compute usagecount_avg twice?
>
> I should have removed the first one, but I think I missed it.
> Nice catch.
>
> Attached an updated version.
>
> Thanks,
> Melih
>
H
> For one example of where the semantics get fuzzy, it's not
> very clear how the extra-baggage columns ought to participate in
> CASCADE updates. Currently, if we have
>CREATE TABLE foo (a integer PRIMARY KEY, b integer);
> then an update that changes only foo.b doesn't need to update
> refer
On Wed, Sep 28, 2022 at 5:30 AM Bharath Rupireddy
wrote:
> I'm attaching the v2 patch designed as described above. Please review it.
>
> I've added an entry in CF - https://commitfest.postgresql.org/40/3915/
This looks odd to me. In the case of a regular backend, the
sigsetjmp() handler in src/ba
Hi,
Seems like the commit a448e49bcbe40fb72e1ed85af910dd216d45bad8 reverts the
changes on pg_buffercache.
Why compute usagecount_avg twice?
>
Then, I'm going back to v11 + the fix for this.
Thanks,
Melih
v14-0001-Added-pg_buffercache_summary-function.patch
Description: Binary data
Nathan Bossart writes:
> On Mon, Sep 26, 2022 at 06:05:34PM -0400, Tom Lane wrote:
>> Yeah. Whether it's efficient or not, seems like it should *work*.
>> I'm a bit inclined to call this a bug-fix and backpatch it.
> LGTM. I have no opinion on back-patching.
I had second thoughts about back-pa
We have discussed the problems caused by the use of pg_stat_reset() and
pg_stat_reset_shared(), specifically the removal of information needed
by autovacuum. I don't see these risks documented anywhere. Should we
do that? Are there other risks?
--
Bruce Momjian https://momjian.us
On Wed, Sep 28, 2022 at 11:45 AM Bruce Momjian wrote:
> We have discussed the problems caused by the use of pg_stat_reset() and
> pg_stat_reset_shared(), specifically the removal of information needed
> by autovacuum. I don't see these risks documented anywhere. Should we
> do that?
+1.
> Are
Hi hackers,
With PG 15 (rc1 or beta4), I'm observing an interesting memory pattern. I
have not seen a similar discussion on the mailing list. If I missed that,
please refer me there. The problem that I'm going to explain does not
happen on PG 13/14.
It seems like there is a memory leak(?) with $t
On Tue, Sep 27, 2022 at 6:14 PM Masahiko Sawada wrote:
> No. Since cluster_name is PGC_POSTMATER, we leak a little postmaster
> memory only once when starting up. application_name is PGC_USERSET but
> since we normally allocate memory in PortalMemoryContext we eventually
> can free it.
Oh, I see;
On Wed, Sep 28, 2022 at 6:48 AM Robert Haas wrote:
> On second thought, I'm going to revert the whole thing. There's a
> bigger mess here than can be cleaned up on the fly. The
> alignment-related mess in ParseCommitRecord is maybe something for
> which I could just hack a quick fix, but what I've
>CREATE TABLE t1 (a text);
>CREATE TABLE t2 (a text);
>-- make the text a little large by adding 1000
>INSERT INTO t1 SELECT (1000+i%1000)::text FROM
>generate_series(0,1000) i;
>-- make the text a little large by adding 1000
>INSERT INTO t2 SELECT (1000+i%1000
Hi hackers,
The proposed patch removes the redundant `fixOwner` argument.
"""
The fixOwner bool argument ended up always being true, so it doesn't do much
anymore. Removing it doesn't necessarily affect the performance a lot, but at
least improves the readability. The procedure is static thus the
Hi,
Thanks for replying so quickly!
I run your test here with a fix attached.
>
> Can you retake your test with the patch attached?
>
>
> Unfortunately, with the patch, I still see the memory usage increase and
get the OOMs
Thanks,
Onder KALACI
Em qua., 28 de set. de 2022 às 14:24, Önder Kalacı
escreveu:
> Hi,
>
> Thanks for replying so quickly!
>
> I run your test here with a fix attached.
>>
>> Can you retake your test with the patch attached?
>>
>>
>> Unfortunately, with the patch, I still see the memory usage increase and
> get the
=?UTF-8?B?w5ZuZGVyIEthbGFjxLE=?= writes:
> With PG 15 (rc1 or beta4), I'm observing an interesting memory pattern.
Yup, that is a leak. valgrind'ing it blames this call chain:
==00:00:16:12.228 4011013== 790,404,056 bytes in 60,800,312 blocks are
definitely lost in loss record 1,108 of 1,108
=
On Thu, Sep 22, 2022 at 11:12:32PM +0200, Matthias van de Meent wrote:
> On Thu, 8 Sept 2022 at 23:24, Tom Lane wrote:
> >
> > Matthias van de Meent writes:
> > > Please find attached a patch that adds the CommandId of the inserting
> > > transaction to heap (batch)insert, update and delete recor
I wrote:
> and bisecting fingers this commit as the guilty party:
> commit 91e9e89dccdfdf4216953d3d8f5515dcdef177fb
> Author: David Rowley
> Date: Thu Jul 22 14:03:19 2021 +1200
> Make nodeSort.c use Datum sorts for single column sorts
After looking at that for a little while, I wonder if
On Tue, Sep 20, 2022 at 09:31:26PM -0700, Nathan Bossart wrote:
> I bet a more pressing concern is the calls to aclmask() since checking
> privileges is probably done more frequently than updating them. That
> appears to use a linear search, too, so maybe sorting the aclitem arrays is
> actually w
Greetings,
On Wed, Sep 28, 2022 at 14:50 Nathan Bossart
wrote:
> On Tue, Sep 20, 2022 at 09:31:26PM -0700, Nathan Bossart wrote:
> > I bet a more pressing concern is the calls to aclmask() since checking
> > privileges is probably done more frequently than updating them. That
> > appears to use
On 2022-Sep-28, Peter Geoghegan wrote:
> It would be useful if there were generic tests that caught issues like
> this. There are various subtle effects related to how struct layout
> can impact WAL record size that might easily be missed. It's not like
> there are a huge number of truly critical
On 2022-Sep-28, Robert Haas wrote:
> The number of buildfarm failures that I would have avoided by checking
> CI is less than the number of extra things I had to fix to keep CI
> happy, and the serious problems were caught by the buildfarm, not by
> CI. [...] So I guess the way you're supposed to
On Thu, Sep 29, 2022 at 1:27 AM Robert Haas wrote:
> ... Here's a
> list of the follow-up fixes I've so far committed:
>
> 1. headerscheck
> 2. typos
> 3. pg_buffercache's meson.build
> 4. compiler warning
> 5. alignment problem
> 6. F_INTEQ/F_OIDEQ problem
>
> CI caught (1), (3), and (4). The bui
Hi,
On 2022-09-27 19:27:24 -0700, Andres Freund wrote:
> Stared too long at the screen to figure all of this out. Food next. I'll clean
> the patches up later tonight or tomorrow morning.
Attached:
0001 - meson: windows: Normalize slashes in prefix
0002 - meson: pg_regress: Define a HOST_TUPLE s
Thanks for investigating this and finding the guilty commit.
On Thu, 29 Sept 2022 at 07:34, Tom Lane wrote:
> After looking at that for a little while, I wonder if we shouldn't
> fix this by restricting the Datum-sort path to be used only with
> pass-by-value data types. That'd require only a mi
On Wed, Sep 28, 2022 at 12:32 PM Thomas Munro wrote:
> I don't agree with this. The build farm clearly has more ways to
> break than CI, because it has more CPUs, compilers, operating systems,
> combinations of configure options and rolls of the timing dice, but CI
> now catches a lot and, import
David Rowley writes:
> I'm wondering if the best way to fix it if doing it that way would be
> to invent tuplesort_getdatum_nocopy() which would be the same as
> tuplesort_getdatum() except it wouldn't do the datumCopy for byref
> types.
Yeah, perhaps. We'd need a clear spec on how long the Datu
Robert Haas writes:
> Yeah, I suppose I have to get in the habit of looking at CI before
> committing anything. It's sort of annoying to me, though. Here's a
> list of the follow-up fixes I've so far committed:
> 1. headerscheck
> 2. typos
> 3. pg_buffercache's meson.build
> 4. compiler warning
>
On Wed, Sep 28, 2022 at 03:09:46PM -0400, Stephen Frost wrote:
> On Wed, Sep 28, 2022 at 14:50 Nathan Bossart
> wrote:
>> I've been testing aclmask() with long aclitem arrays (2,000 entries is
>> close to the limit for pg_class entries), and I haven't found any
>> significant impact from bumping A
On Wed, Sep 28, 2022 at 12:20 PM Alvaro Herrera wrote:
> What do you think would constitute a test here?
I would start with something simple. Focus on the record types that we
know are the most common. It's very skewed towards heap and nbtree
record types, plus some transaction rmgr types.
> Say
Kyotaro Horiguchi writes:
> Okay. the points you brought up above are sufficient grounds for not
> doing so. Now they are in the following format.
> LOG: terminating process 16034 to release replication slot "rep1"
> because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes
This see
... oh, one other point is that using %ld to print an int64 is entirely
not portable, as indeed the cfbot is complaining about.
I think our best practice on that is to put %lld in the format string
and explicitly cast the corresponding argument to "long long".
regards, tom
OK, so the recent commit and revert of the 56-bit relfilenode patch
revealed a few issues that IMHO need design-level input. Let me try to
surface those here, starting a new thread to separate this discussion
from the clutter:
1. Commit Record Alignment. ParseCommitRecord() and ParseAbortRecord()
On Wed, Sep 28, 2022 at 08:14:23PM +0300, Aleksander Alekseev wrote:
> + ResourceOwnerForgetBuffer(CurrentResourceOwner, b);
> +
> /* not moving as we're likely deleting it soon anyway */
> ref = GetPrivateRefCountEntry(b, false);
> Assert(ref != NULL);
> -
> - i
On Wed, Sep 28, 2022 at 9:40 PM Dilip Kumar wrote:
> Thanks, Thomas, these all look fine to me. So far we have committed
> the patch to make relfilenode 56 bits wide. The Tombstone file
> removal patch is still pending to be committed, so when I will rebase
> that patch I will accommodate all th
Nathan Bossart writes:
> Thanks for the suggestion. I used it in v4 of the patch.
I reviewed this and made some changes, some cosmetic some less so.
Notably, I was bemused that of the four calls of
pgstat_fetch_stat_local_beentry, three tested for a NULL result even
though they cannot get one,
On Thu, 29 Sept 2022 at 08:57, Tom Lane wrote:
>
> David Rowley writes:
> > I'm wondering if the best way to fix it if doing it that way would be
> > to invent tuplesort_getdatum_nocopy() which would be the same as
> > tuplesort_getdatum() except it wouldn't do the datumCopy for byref
> > types.
On Wed, Sep 28, 2022 at 12:57 PM Tom Lane wrote:
> David Rowley writes:
> > I'm wondering if the best way to fix it if doing it that way would be
> > to invent tuplesort_getdatum_nocopy() which would be the same as
> > tuplesort_getdatum() except it wouldn't do the datumCopy for byref
> > types.
On Wed, Sep 28, 2022 at 4:00 PM Peter Geoghegan wrote:
> I am reminded of the discussion that led to bugfix commit c2d4eb1b
> some years back.
Also potentially relevant: the 2017 commit fa117ee4 anticipated adding
a "copy" argument to tuplesort_getdatum() (the same commit added such
a "copy" argu
Robert Haas writes:
> 3. Sinval Message Size. Sinval messages are 16 bytes right now.
> They'll have to grow to 20 bytes if we do this. There's even less room
> for bit-squeezing here than there is for the WAL stuff. I'm skeptical
> that this really matters, but Tom seems concerned.
As far as tha
On Wed, Sep 28, 2022 at 4:08 PM Tom Lane wrote:
> As far as that goes, I'm entirely prepared to accept a conclusion
> that the benefits of widening relfilenodes justify whatever space
> or speed penalties may exist there. However, we cannot honestly
> make that conclusion if we haven't measured s
On Thu, Sep 29, 2022 at 11:58:17AM +1300, David Rowley wrote:
> I've just pushed the disable byref Datums patch I posted earlier. I
> only made a small adjustment to make use of the TupleDescAttr() macro.
> Önder, thank you for the report.
Wouldn't it be better to have 3a58176 reflect the non-opti
Michael Paquier writes:
> Wouldn't it be better to have 3a58176 reflect the non-optimization
> path in the EXPLAIN output of a new regression test if none of the
> existing tests are able to show any difference?
This decision is not visible in EXPLAIN in any case.
regards
On Thu, 29 Sept 2022 at 12:30, Michael Paquier wrote:
>
> On Thu, Sep 29, 2022 at 11:58:17AM +1300, David Rowley wrote:
> > I've just pushed the disable byref Datums patch I posted earlier. I
> > only made a small adjustment to make use of the TupleDescAttr() macro.
> > Önder, thank you for the re
On Wed, Sep 28, 2022 at 07:35:07PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> Wouldn't it be better to have 3a58176 reflect the non-optimization
>> path in the EXPLAIN output of a new regression test if none of the
>> existing tests are able to show any difference?
>
> This decision is n
HI,
On Sep 29, 2022, 05:08 +0800, Nathan Bossart , wrote:
> On Wed, Sep 28, 2022 at 08:14:23PM +0300, Aleksander Alekseev wrote:
> > + ResourceOwnerForgetBuffer(CurrentResourceOwner, b);
> > +
> > /* not moving as we're likely deleting it soon anyway */
> > ref = GetPrivateRefCountEntry(b, false);
On Thu, 29 Sept 2022 at 12:07, Peter Geoghegan wrote:
> Also potentially relevant: the 2017 commit fa117ee4 anticipated adding
> a "copy" argument to tuplesort_getdatum() (the same commit added such
> a "copy" argument to tuplesort_gettupleslot()). I see that that still
> hasn't happened to tuples
On Wed, Sep 28, 2022 at 6:13 PM David Rowley wrote:
> Master:
> latency average = 313.197 ms
>
> Patched:
> latency average = 304.335 ms
>
> So not a very impressive speedup there (about 3%)
Worth a try, at least. Having a more consistent interface is valuable
in itself too.
--
Peter Geoghegan
Hi,
The max size for the shmem hash table name is SHMEM_INDEX_KEYSIZE - 1.
but when the caller uses a longer hash table name, it doesn't report any error,
instead
it just uses the first SHMEM_INDEX_KEYSIZE -1 chars as the hash table name.
I created some shmem hash tables with the same prefix whi
Hi,
On 2022-09-28 16:07:13 -0400, Tom Lane wrote:
> Robert Haas writes:
> > And like the existing buildfarm, it's severely under-documented.
>
> That complaint I agree with. A wiki page is a pretty poor substitute
> for in-tree docs.
I assume we're talking about CI?
What would you like to see
Andres Freund writes:
> On 2022-09-28 16:07:13 -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> And like the existing buildfarm, it's severely under-documented.
>> That complaint I agree with. A wiki page is a pretty poor substitute
>> for in-tree docs.
> I assume we're talking about CI?
I w
2022-09-28 21:49 に torikoshia さんは書きました:
if (result == 127 || result == -1)
{
pg_log_error("\\!: failed");
return false;
}
else if (result != 0) {
pg_log_error("command failed");
return false;
Since it would be hard to understand the cause of failures from
On Wed, Sep 28, 2022 at 06:56:20PM -0400, Tom Lane wrote:
> I reviewed this and made some changes, some cosmetic some less so.
Thanks for the detailed review.
> A point that still bothers me a bit about pg_stat_get_backend_idset is
> that it could miss or duplicate some backend IDs if the user ca
On Wed, Sep 28, 2022 1:49 PM Kyotaro Horiguchi wrote:
>
> At Wed, 28 Sep 2022 14:14:01 +1000, Peter Smith
> wrote in
> > On Tue, Sep 27, 2022 at 8:28 PM shiy.f...@fujitsu.com
> > wrote:
> > >
> > > Hi hackers,
> > >
> > > I saw a problem when using tab-complete for "GRANT", "TABLES IN
> SCHEMA"
Hi,
On 2022-09-28 22:14:11 -0400, Tom Lane wrote:
> I was thinking of meson when I wrote that ... but re-reading it,
> I think Robert meant CI.
FWIW, I had planned to put the "translation table" between autoconf and meson
into the docs, but Peter E. argued that the wiki is better for that. Happy
At Thu, 29 Sep 2022 11:29:40 +0900, bt22nakamorit
wrote in
> 2022-09-28 21:49 に torikoshia さんは書きました:
> >>if (result == 127 || result == -1)
> >>{
> >>pg_log_error("\\!: failed");
> >>return false;
> >>}
> >>else if (result != 0) {
> >>pg_log_error("command
Hi,
On 2022-09-28 21:22:26 +0200, Alvaro Herrera wrote:
> I have an additional, unrelated complaint about CI, which is that we
> don't have anything for past branches. I have a partial hack(*), but
> I wish we had something we could readily use.
>
> (*) I just backpatched the commit that added t
On Thu, Aug 4, 2022 at 1:05 PM Amit Langote wrote:
> On Wed, Jul 13, 2022 at 8:59 PM Amit Langote wrote:
> > That bit came in to make DETACH CONCURRENTLY produce sane answers for
> > RI queries in some cases.
> >
> > I guess my comment should really have said something like:
> >
> > HACK: find_in
At Thu, 29 Sep 2022 12:35:04 +0900 (JST), Kyotaro Horiguchi
wrote in
> > Thank you for the feedback!
> > I agree that the messages should be more clear.
> > \\!: command was not executed
> > \\!: command failed
> > Would these two messages be enough to describe the two cases?
>
> FWIW, I would
On Thu, Sep 29, 2022 at 1:43 AM Jacob Champion wrote:
>
> On Tue, Sep 27, 2022 at 6:14 PM Masahiko Sawada wrote:
> > No. Since cluster_name is PGC_POSTMATER, we leak a little postmaster
> > memory only once when starting up. application_name is PGC_USERSET but
> > since we normally allocate memor
On Thu, 29 Sept 2022 at 14:32, Peter Geoghegan wrote:
>
> On Wed, Sep 28, 2022 at 6:13 PM David Rowley wrote:
> > Master:
> > latency average = 313.197 ms
> >
> > Patched:
> > latency average = 304.335 ms
> >
> > So not a very impressive speedup there (about 3%)
>
> Worth a try, at least. Having
We originally did this in 91e9e89dc, but a memory leak was discovered
as I neglected to pfree the datum which is freshly allocated in
tuplesort_getdatum. Because that was discovered late in the PG15
cycle, we opted to just disable the datum sort optimisation for byref
types in 3a5817695.
As was me
1 - 100 of 111 matches
Mail list logo
