On Fri, Oct 25, 2024 at 8:02 PM Junwang Zhao wrote:
>
> On Fri, Oct 25, 2024 at 1:19 AM Aleksander Alekseev
> wrote:
> >
> > Hi,
> >
> > > I can accept this outcome though an optional three-valued boolean sort
> > > order (ascending and descending only) I'd argue is worth keeping. null
> > > v
On Fri, Oct 25, 2024 at 10:07 PM Melanie Plageman
wrote:
> On Fri, Oct 25, 2024 at 10:29 AM Melanie Plageman
> wrote:
> >
> > Tom suggested off-list that if rs_cindex can't be zero, then it should
> > be unsigned. I checked the other scan types using the
> > HeapScanDescData, and it seems none o
> 10). In this error:
>
> +elog(ERROR, "unsupported type %d for rand_array function.",
> + datatype);
>
> "datatype" is of type Oid, which is unsigned, and so it should use
> "%u" not "%d". Also, as above, it should not end with a period, so it
> should be:
>
> +elog(E
On Thu, 2024-10-24 at 10:05 +0200, Andreas Karlsson wrote:
> Why is there no pg_locale_builtin.c?
Just that it would be a fairly small file, but I'm fine with doing
that.
> I think adding an assert to create_pg_locale() which enforces valid
> there is always a combination of ctype_is_c and casem
On Tue, 2024-09-17 at 05:02 -0400, Corey Huinker wrote:
>
> I've taken most of Jeff's work, reincorporated it into roughly the
> same patch structure as before, and am posting it now.
I have committed the import side of this patch series; that is, the
function calls that can load stats into an ex
On Thu, Oct 24, 2024 at 7:55 AM Fujii Masao wrote:
>
>
>
> On 2024/10/24 5:23, Masahiko Sawada wrote:
> >> if (xids_left > 2000 &&
> >> consumed - last_reported_at < REPORT_INTERVAL &&
> >> MyProc->subxidStatus.overflowed)
> >> {
> >>
Hi!
On Mon, 21 Oct 2024 at 17:39, Fujii Masao wrote:
>
>
>
> On 2024/10/21 18:30, Kirill Reshke wrote:
> > v4 no longer applies. It now conflicts with
> > e7834a1a251d4a28245377f383ff20a657ba8262.
> > Also, there were review comments.
> >
> > So, I decided to rebase.
>
> Thanks for the patch! Her
"Tristan Partin" writes:
> FWIW, I ran into this compiling an extension written in C++ for v15, so
> I'll throw my support for backpatching this if that is still on the
> table. Understandable if not, though.
I'm inclined to think "too late". Even if we back-patched to v15
and earlier now, you
On Fri Oct 25, 2024 at 3:04 PM CDT, Tom Lane wrote:
Christoph Berg writes:
Should the removal of "register" be backported to support that better?
Perhaps. It's early days yet, but nobody has complained that that
broke anything in v16, so I'm guessing it'd be fine.
FWIW, I ran into this com
On Fri Oct 25, 2024 at 3:19 PM CDT, Tom Lane wrote:
"Tristan Partin" writes:
FWIW, I ran into this compiling an extension written in C++ for v15, so
I'll throw my support for backpatching this if that is still on the
table. Understandable if not, though.
I'm inclined to think "too late". Ev
I wrote:
> However ... I don't like this implementation, not even a little
> bit.
I forgot to mention a third problem, which is that reassigning the
alias during subquery pullup means it doesn't happen if subquery
pullup doesn't happen. As an example, with your patch:
regression=# explain verbos
On Fri, Oct 25, 2024 at 3:54 PM Amit Kapila wrote:
>
> On Fri, Oct 25, 2024 at 12:07 PM Amit Kapila wrote:
> >
> > On Thu, Oct 24, 2024 at 8:50 PM vignesh C wrote:
> > >
> > > The v42 version patch attached at [1] has the changes for the same.
> > >
> >
> > Some more comments:
> >
>
> 1.
> +pgou
I noticed that development on the concurrent index creation for partitioned
tables feature seemed to stall a few months ago. The patch looked solid,
and there didn’t seem to be any issues with it. Has there been any further
progress? This feature would be invaluable, given the prevalence of
partiti
At commit 779972e, I got about 50% "pg_ctl: server does not shut down" from
$SUBJECT with this loop:
nti=; while date; do PGCTLTIMEOUT=4 make check-tests TESTS=reindex_catalog
PG_TEST_INITDB_EXTRA_OPTS='-cwal_level=minimal -cmax_wal_senders=0'
NO_TEMP_INSTALL=$nti; nti=1; grep abnormal src/tes
Daniil Davydov <3daniss...@gmail.com> writes:
> I noticed that TRUNCATE and ALTER commands on temporary tables of other
> sessions produce an error "cannot truncate/alter temporary tables of other
> sessions". But are there any reasons to allow us to DROP such tables?
> It seems to me that the only
Yasir writes:
> I have fixed the code to produce desired output by adding a few lines in
> pull_up_simple_subquery().
> Attached patch is divided in 2 files:
> - 001-Fix-Alias-VALUES-RTE.patch contains the actual fix.
> - 002-Fix-Alias-VALUES-RTE.patch contains the expected output changes
> agai
Hi,
When database object stats manipulation functions like pg_set_relation_stats()
are run,
they currently produce the following error and hint messages, which are
"internal"
and make it hard for users to understand the issue:
ERROR: cannot acquire lock mode ShareUpdateExclusiveLock on
On Fri, Oct 25, 2024 at 10:29 AM Melanie Plageman
wrote:
>
> Tom suggested off-list that if rs_cindex can't be zero, then it should
> be unsigned. I checked the other scan types using the
> HeapScanDescData, and it seems none of them use values of rs_cindex or
> rs_ntuples < 0. As such, here is a
Alvaro Herrera writes:
> On 2024-Oct-22, Peter Eisentraut wrote:
>> One thing I didn't realize until today is that currently C23 compilations
>> only work with meson. The autoconf version we are using doesn't support it,
>> and the configure results it produces are somehow faulty and then you get
On 2024-Oct-22, Peter Eisentraut wrote:
> One thing I didn't realize until today is that currently C23 compilations
> only work with meson. The autoconf version we are using doesn't support it,
> and the configure results it produces are somehow faulty and then you get a
> bunch of compilation er
On 2024-Oct-25, Alexander Lakhin wrote:
> I've also discovered another anomaly with a similar setup, but it's not
> related to 53af9491a.
Hmm, it may well be a preexisting problem, but I do think it involves
the same code. As far as I can tell, the value "2" here
> This script ends up with:
> E
Thanks for the review!
On Thu, Oct 24, 2024 at 3:51 PM Greg Sabino Mullane wrote:
>
> I really appreciate all the work to make vacuum better. Anything that helps
> our problem of autovacuum not scaling well for large tables is a win.
>
> I'm not overly familiar with this part of the code base, b
On Thu, Oct 24, 2024 at 9:40 AM Melanie Plageman
wrote:
>
> On Thu, Oct 24, 2024 at 12:50 AM Dilip Kumar wrote:
> >
> > On Thu, Oct 24, 2024 at 3:45 AM Melanie Plageman
> > wrote:
> >>
> >> HeapScanDescData->rs_cindex (the current index into the array of
> >> visible tuples stored in the heap s
On Fri, Oct 25, 2024 at 2:27 PM jian he wrote:
>
> /*
> * ri_GenerateQualCollation --- add a COLLATE spec to a WHERE clause
> *
> - * At present, we intentionally do not use this function for RI queries that
> - * compare a variable to a $n parameter. Since parameter symbols always have
> -
Hello Alvaro and Tender Wang,
24.10.2024 17:00, Alexander Lakhin wrote:
Please look at a new anomaly introduced with 53af9491a. When running the
following script:
CREATE TABLE t (a int, b int, PRIMARY KEY (a, b));
CREATE TABLE pt (a int, b int, FOREIGN KEY (a, b) REFERENCES t(a, b))
PARTITION B
On 2024-10-25 09:34:41 -0400, Melanie Plageman wrote:
> I noticed that CI for my fork of Postgres, which had been failing on
> docs build and on test-running on the injection points test only on
> freebsd, started working as expected again this morning. All of this
> is a bit of magic to me -- are
On Fri, Oct 25, 2024 at 4:31 AM Andres Freund wrote:
>
> On 2024-10-25 04:14:03 -0400, Andres Freund wrote:
> > On 2024-10-25 08:22:42 +0300, Thomas Munro wrote:
> > > I wonder if this will magically fix itself when the next CI image
> > > build cron job kicks off. I have no idea what time zone t
> On 14 Oct 2024, at 18:57, Bruce Momjian wrote:
> What might be acceptable would be to add an option that would make
> pg_upgrade more tolerant of problems in many areas, that is a lot more
> research and discussion.
I agree that the concept of having pg_upgrade perform (opt-in) skipping and/or
On Fri, Oct 25, 2024 at 1:19 AM Aleksander Alekseev
wrote:
>
> Hi,
>
> > I can accept this outcome though an optional three-valued boolean sort
> > order (ascending and descending only) I'd argue is worth keeping. null
> > value placement too I guess, three-valued boolean (nulls_first).
>
> Per
> On 25 Oct 2024, at 00:55, Rahila Syed wrote:
>
> While writing this email, I realized I evicted buffers for the table
> and not the index. I will perform the test again. However,
> I would like to know your opinion on whether this looks like
> a valid test.
Well, yes, kind of, you need drop
Hi Ashutosh & PG Hackers,
I have fixed the code to produce desired output by adding a few lines in
pull_up_simple_subquery().
Attached patch is divided in 2 files:
- 001-Fix-Alias-VALUES-RTE.patch contains the actual fix.
- 002-Fix-Alias-VALUES-RTE.patch contains the expected output changes
agai
On Fri, 25 Oct 2024 at 11:02, Daniil Davydov <3daniss...@gmail.com> wrote:
> But are there any reasons to allow us to DROP such tables?
>
Hi!
This topic has already been discussed in [0], I believe. I'm not sure how
it all ended and if there were any changes made in the end. But from the
user's p
On Fri, Oct 25, 2024 at 12:07 PM Amit Kapila wrote:
>
> On Thu, Oct 24, 2024 at 8:50 PM vignesh C wrote:
> >
> > The v42 version patch attached at [1] has the changes for the same.
> >
>
> Some more comments:
>
1.
+pgoutput_pubgencol_init(PGOutputData *data, List *publications,
+ RelationSyncEnt
Hello, Hayato!
> Thanks for updating the patch! While reviewing yours, I found a corner
case that
> a recently deleted tuple cannot be detected when index scan is chosen.
> This can happen when indices are re-built during the replication.
> Unfortunately, I don't have any solutions for it.
I just
On Fri, Oct 25, 2024 at 12:48 PM Alexander Korotkov
wrote:
> On Fri, Oct 25, 2024 at 11:35 AM Andres Freund wrote:
> > On 2024-10-22 20:33:24 +0300, Alexander Korotkov wrote:
> > > Thank you, Pavel! 0001 revised according to your suggestion.
> >
> > Starting with this commit CI fails.
> >
> > ht
On Fri, Oct 25, 2024 at 11:35 AM Andres Freund wrote:
> On 2024-10-22 20:33:24 +0300, Alexander Korotkov wrote:
> > Thank you, Pavel! 0001 revised according to your suggestion.
>
> Starting with this commit CI fails.
>
> https://cirrus-ci.com/task/6668851469877248
> https://api.cirrus-ci.com/v1/a
Alvaro Herrera 于2024年10月25日周五 16:30写道：
> On 2024-Oct-25, Tender Wang wrote:
>
> > Thanks for reporting. I can reproduce this memory invalid access on HEAD.
> > After debuging codes, I found the root cause.
> > In DetachPartitionFinalize(), below code:
> > att = TupleDescAttr(RelationGetDescr(par
> Here is the V5 patch set which addressed above comments.
>
Here are a couple of comments on v5 patch-set -
1) In FindMostRecentlyDeletedTupleInfo(),
+ /* Try to find the tuple */
+ while (index_getnext_slot(scan, ForwardScanDirection, scanslot))
+ {
+ Assert(tuples_equal(scanslot, searchslot, e
Hi,
On 2024-10-22 20:33:24 +0300, Alexander Korotkov wrote:
> Thank you, Pavel! 0001 revised according to your suggestion.
Starting with this commit CI fails.
https://cirrus-ci.com/task/6668851469877248
https://api.cirrus-ci.com/v1/artifact/task/6668851469877248/testrun/build/testrun/regress-ru
Hi,
On 2024-10-25 04:14:03 -0400, Andres Freund wrote:
> On 2024-10-25 08:22:42 +0300, Thomas Munro wrote:
> > I wonder if this will magically fix itself when the next CI image
> > build cron job kicks off. I have no idea what time zone this page is
> > showing but it should happen in another day
On 2024-Oct-25, Tender Wang wrote:
> Thanks for reporting. I can reproduce this memory invalid access on HEAD.
> After debuging codes, I found the root cause.
> In DetachPartitionFinalize(), below code:
> att = TupleDescAttr(RelationGetDescr(partRel),
>attmap->attn
On Thu, 2024-10-24 at 05:01 +0300, Laurenz Albe wrote:
> What you write above indicates that "relpages" = 0 and "reltuples" >
> 0
> would also be acceptable.
As Tom pointed out, that creates a risk that it's interpreted as
infinite tuple denisity.
The only functional change in my patch is to crea
On 10/15/24 8:12 AM, Peter Eisentraut wrote:
We currently have
static PG_Locale_Strategy pg_regex_strategy;
static pg_locale_t pg_regex_locale;
static Oid pg_regex_collation;
but after the recent improvements to pg_locale_t handling, we don't need
all three anymore. All the in
On Thu, Oct 24, 2024 at 8:27 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
>
> Just making an observation / thinking out loud that the requirement to
> support everything ORDER BY handles / supports (and will handle /
> support?) might make this function impractical to maintain.
>
> Pa
On 2024/10/24 11:12, Bertrand Drouvot wrote:
So, probably
we can consider that this check is already in place. If it’s still worth adding,
perhaps placing it inside the FAST_PATH_SLOT() macro could be an option...
Or current assertion check is enough? Thought?
Given that it's already done in
Junwang Zhao 于2024年10月15日周二 18:56写道：
> On Mon, Oct 14, 2024 at 6:30 PM Ilia Evdokimov
> wrote:
> >
> >
> > On 14.08.2024 09:32, Steven Niu wrote:
> > > Hi, Kirill, Junwang,
> > >
> > > I made this patch to address the refactor issue in our previous email
> > > discussion.
> > >
> https://www.pos
> On 24 Oct 2024, at 10:15, Andrey M. Borodin wrote:
>
> I've also added GiST vacuum to the patchset.
I decided to add up a SP-GiST while having launched on pgconf.eu.
Best regards, Andrey Borodin.
v7-0001-Prototype-B-tree-vacuum-streamlineing.patch
Description: Binary data
v7-0002-Use-r
On Thu, Oct 24, 2024 at 8:40 PM jian he wrote:
>
> On Wed, Oct 23, 2024 at 10:28 PM Junwang Zhao wrote:
> > PFA v7 with multi-array support.
> >
>
> if (ARR_NDIM(array) == 1)
> {
> }
> else
> {
> }
> can be simplified.
> i think beginning part of array_sort can be like the following:
> (newline e
On Thu, Oct 24, 2024 at 9:06 AM Tom Lane wrote:
> This business with a textual representation of a sort clause seems like
> over-engineering ... except that it's also under-engineered, because
> the parsing is lame and incomplete. (No USING option, and the fact
> that collation comes from somewh
I really appreciate all the work to make vacuum better. Anything that helps
our problem of autovacuum not scaling well for large tables is a win.
I'm not overly familiar with this part of the code base, but here are some
questions/ideas:
+ /*
+* Every block marked all-frozen in the
Hi,
On 2024-10-25 08:22:42 +0300, Thomas Munro wrote:
> On Fri, Oct 25, 2024 at 4:44 AM Tom Lane wrote:
> > Melanie Plageman writes:
> > > I know in the past docs builds failing with "failed to load external
> > > entity" have happened on macos. But, recently I've noticed this
> > > failure for
On 10/25/24 14:15, Kirill Reshke wrote:
On Fri, 25 Oct 2024 at 09:51, Andrei Lepikhov wrote:
It may be have made sense to lock the row of replaced index in pg_class
and pg_index until the transaction, altered it will be commmitted. But,
because ALTER TABLE is not fully MVCC-safe, it may be
Hi,
I noticed that TRUNCATE and ALTER commands on temporary tables of other
sessions produce an error "cannot truncate/alter temporary tables of other
sessions". But are there any reasons to allow us to DROP such tables?
It seems to me that the only case when we may need it is the removal of
orphan
On Fri, 2024-10-25 at 07:21 +0200, Pavel Stehule wrote:
> > > + elog(DEBUG1, "pg_session_variables start");
> >
> > I don't think that message is necessary, particularly with DEBUG1.
> > I have removed this message and the "end" message as well.
>
> removed
Thanks.
> > > +
On Thu, 24 Oct 2024 at 19:23, Alena Rybakina wrote:
>
> Hi!
>
> On 24.10.2024 16:07, hugo wrote:
>
> Hi!
>
>When looking at the partition-related code, I found that the
> ispartitioned
>
> field in CreateStmtContext is not used. It looks like we can safely remove it
> and
>
> avoid inval
On Thu, 24 Oct 2024 at 16:44, Amit Kapila wrote:
>
> On Thu, Oct 24, 2024 at 12:15 PM vignesh C wrote:
> >
> > The attached v41 version patch has the changes for the same.
> >
>
> Please find comments for the new version as follows:
> 1.
> + Generated columns may be skipped during logical re
On Fri, 25 Oct 2024 at 09:51, Andrei Lepikhov wrote:
>
> It may be have made sense to lock the row of replaced index in pg_class
> and pg_index until the transaction, altered it will be commmitted. But,
> because ALTER TABLE is not fully MVCC-safe, it may be expected (or
> acceptable) behaviour
On Wed, Oct 23, 2024 at 10:28 PM Junwang Zhao wrote:
> PFA v7 with multi-array support.
>
if (ARR_NDIM(array) == 1)
{
}
else
{
}
can be simplified.
i think beginning part of array_sort can be like the following:
(newline emitted)
--
Hello Alvaro,
22.10.2024 17:32, Alvaro Herrera wrote:
Yeah. I pushed these patches finally, thanks!
Please look at a new anomaly introduced with 53af9491a. When running the
following script:
CREATE TABLE t (a int, b int, PRIMARY KEY (a, b));
CREATE TABLE pt (a int, b int, FOREIGN KEY (a, b) R
Hi,
I know in the past docs builds failing with "failed to load external
entity" have happened on macos. But, recently I've noticed this
failure for docs build on CI (not on macos) -- docs build is one of
the jobs run under the "Compiler Warnings" task.
See an example of this on CI for the github
On Thu, Oct 24, 2024 at 7:58 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi,
>
> > It's hardly "general purpose" if it randomly refuses to
> > sort certain types. I would say it should be able to sort
> > anything that ORDER BY will handle --- and that certainly
> > includes the c
On Thu, Oct 24, 2024 at 5:44 PM Peter Smith wrote:
>
> On Thu, Oct 24, 2024 at 5:41 PM Michael Paquier wrote:
> >
> > On Thu, Oct 24, 2024 at 05:27:25PM +1100, Peter Smith wrote:
> > > Yes, well spotted -- I was aware of that. Originally I had coded a >=
> > > PG15 check for that pub_names assign
62 matches
Mail list logo
