On Sun, Apr 04, 2021 at 07:52:50PM +0200, Tomas Vondra wrote:
> On 4/4/21 7:25 AM, Jaime Casanova wrote:
> >
> > pgbench -i postgres
> > psql -c "CREATE INDEX ON pgbench_history USING brin (tid
> > int4_minmax_multi_ops);" postgres
> > pgbench -c2 -j2 -T 300 -n postgres
> >
>
> Fixed and pushed
Hi,
On 9/29/22 8:12 AM, Michael Paquier wrote:
On Wed, Sep 28, 2022 at 12:58:48PM +0200, Drouvot, Bertrand wrote:
I had a look at v5 and it does look good to me.
Okay, cool. I have spent some time today doing a last pass over it
and an extra round of tests. Things looked fine, so applied.
-
Hi hackers,
While running `make check LANC=C` with 32-bit virtual machine,
I found that it was failed at "aggregates". PSA the a1b3bca1_regression.diffs.
IIUC that part has been added by db0d67db.
I checked out the source, tested, and got same result. PSA the
db0d67db_regression.diffs
I'm not s
On Wed, Sep 28, 2022 at 11:14:53AM +0530, Bharath Rupireddy wrote:
> IMO, we can add mapping for just ERROR_INVALID_NAME which is an
> obvious error code and easy to hit, leaving others.
Okidoki. Applied the minimalistic version, then.
--
Michael
signature.asc
Description: PGP signature
On Wed, Sep 28, 2022 at 12:58:48PM +0200, Drouvot, Bertrand wrote:
> I had a look at v5 and it does look good to me.
Okay, cool. I have spent some time today doing a last pass over it
and an extra round of tests. Things looked fine, so applied.
--
Michael
signature.asc
Description: PGP signatu
Hi,
On Sep 28, 2022, 23:20 +0800, Melih Mutlu , wrote:
> 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
Looks good to me.
On Sat, Sep 24, 2022 at 1:54 AM Nathan Bossart wrote:
>
> +PGAlignedXLogBlock zbuffer;
> +
> +memset(zbuffer.data, 0, XLOG_BLCKSZ);
>
> This seems excessive for only writing a single byte.
Yes, I removed it now, instead doing pg_pwrite(fd, "\0", 1,
wal_segment_size - 1).
> +#ifde
On Wed, Sep 28, 2022 at 04:45:17PM +0900, Michael Paquier wrote:
> Good point. Thanks for the patch, this looks consistent!
Done as of 5ac9e86.
--
Michael
signature.asc
Description: PGP signature
On Tue, 27 Sept 2022 at 11:28, David Rowley wrote:
> Maybe we could remove the datumCopy() from eval_windowfunction() and
> also document that a window function when returning a non-byval type,
> must allocate the Datum in either ps_ExprContext's
> ecxt_per_tuple_memory or ecxt_per_query_memory. W
At Wed, 28 Sep 2022 16:30:37 -0400, Tom Lane wrote in
> 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
On Wed, Sep 28, 2022 at 9:59 PM David Rowley wrote:
> select b from t1 order by b offset 100;
>
> Master:
> latency average = 344.763 ms
>
> Patched:
> latency average = 268.374 ms
>
> about 28% faster.
That's more like it!
--
Peter Geoghegan
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
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
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
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, 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
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
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 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
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"
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
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
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
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
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
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
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
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 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
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
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, 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
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
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: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
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 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.
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 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
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
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()
... 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
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
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
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
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
>
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
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
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
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
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
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 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
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 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
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 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
=?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
=
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
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
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
>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
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
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;
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 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
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
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
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
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
> 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
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
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,
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
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
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
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
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
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
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,
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 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
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;
>
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 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
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: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 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 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
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
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
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
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
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?
> > >
> > > >
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 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",
>
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
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\".",
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 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
1 - 100 of 111 matches
Mail list logo
