When reverse-compiling a query, ruleutils.c has some complicated code to
handle the join output columns of a JOIN USING join. There used to be
no way to qualify those columns, and so if there was a naming conflict
anywhere in the query, those output columns had to be renamed to be
unique throu
Hi Andres,
Are you talking about this scenario - what if the logical replication
slot on the publisher is dropped, but is being referenced by the
standby where the slot is synchronized? Should the redo function for
the drop replication slot have the capability to drop it on standby
and its subscri
On Mon, Jan 31, 2022 at 11:50 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 17 Jan 2022 09:27:14 +0530, Dilip Kumar wrote
> in
>
> me> Mmm. The size of the array cannot be larger than the numbers the
> me> *Connt() functions return. Thus we cannot attach the oversized array
> me> to ->subxip. (I don
At Fri, 4 Feb 2022 17:06:53 +, Jacob Champion wrote
in
> That works a lot better than what I had in my head. Done that way in
> v4. Thanks!
Thanks!
0002:
+#define PGSQL_AF_INET (AF_INET + 0)
+#define PGSQL_AF_INET6 (AF_INET + 1)
..
-#define PGSQL_AF_INET (AF_INET + 0)
-#define PGSQL_AF_
Thanks for your review!
On Sun, Jan 30, 2022 at 7:24 PM Tom Lane wrote:
> Actually, that code has got worse problems than that. I tried to improve
> our regression tests to exercise that code path, as attached. What I got
> was
>
> +SELECT point(x,x), (SELECT circle_center(f1) FROM gcircle_tbl
On Mon, Feb 7, 2022 at 1:21 PM Peter Smith wrote:
>
> 5. src/backend/commands/publicationcmds.c - IsRowFilterSimpleExpr (Simple?)
>
> +/*
> + * Is this a simple Node permitted within a row filter expression?
> + */
> +static bool
> +IsRowFilterSimpleExpr(Node *node)
> +{
>
> A lot has changed in t
Hello, Fujii-san,
On Fri, 4 Feb 2022 09:08:22 +0900
Fujii Masao wrote:
>
>
> On 2022/02/04 1:46, Yugo NAGATA wrote:
> > Hello,
> >
> > I found a old parameter name 'heapRelation' in the comment
> > of CheckIndexCompatible. This parameter was removed by 5f173040.
> >
> > Attached is a patch t
Hello,
I noticed that referential integrity checks aren't currently
parallelized. Is it on purpose?
From the documentation [1], the planner will not generate a parallel
plan for a given query if any of the following are true:
1) The system is running in single-user mode.
2) max_parallel_wor
On Tue, Feb 01, 2022 at 04:20:14PM +0100, Peter Eisentraut wrote:
> This patch adds to database objects the same version tracking that collation
> objects have.
This version conflicts with 87669de72c2 (Some cleanup for change of collate and
ctype fields to type text), so I'm attaching a simple reb
Significant changes:
* don't run TestUpgrade if TAP tests are present in |src/bin/pg_upgrade|
* Add proposed new location of |pg_upgrade| logs in TestUpgrade module
* Use an HMAC over the whole content as the signature.
* Quote |PROVE_FLAGS |in case there are multiple settings
* tighten
On 2022/01/28 14:07, r.takahash...@fujitsu.com wrote:
I think %c of log_line_prefix (Session ID) is also useful for
postgres_fdw.application_name.
Therefore, how about adding both %c (Session ID) and %C (cluster_name)?
+1
Attached is the updated version of the patch. It adds those escape se
On Fri, Feb 4, 2022 at 10:21 PM Greg Stark wrote:
> By far the majority of anti-wraparound vacuums are triggered by tables
> that are very large and so don't trigger regular vacuums for "long
> periods" of time and consistently hit the anti-wraparound threshold
> first.
That's interesting, becaus
On Fri, Feb 4, 2022 at 10:45 PM Peter Geoghegan wrote:
> > While I've seen all the above cases triggering anti-wraparound cases
> > by far the majority of the cases are not of these pathological forms.
>
> Right - it's practically inevitable that you'll need an
> anti-wraparound VACUUM to advance
On Sun, Feb 6, 2022 at 12:24 PM Tom Lane wrote:
> Joe Conway writes:
> > I'd like to pick this patch up and see it through to commit/push.
> > Presumably that will include back-patching to all supported pg versions.
> > Before I go through the effort to back-patch, does anyone want to argue
> > t
Dear all
May I kindly ask your insight about a question I posted 1 month ago and for
which I never received any answer ?
Many thanks
On Thu, Jan 6, 2022 at 4:05 PM Esteban Zimanyi
wrote:
> Dear all
>
> When ingesting mobility (IoT) data into MobilityDB
> https://mobilitydb.com/
> we transform
On 07.02.22 11:29, Julien Rouhaud wrote:
- there should be a mention to the need for a catversion bump in the message
comment
done
- there is no test
Suggestions where to put it? We don't really have tests for the
collation-level versioning either, do we?
- it's missing some updates
On 04.02.22 23:12, Tom Lane wrote:
Right. We've looked into that before --- when I made pg_namespace,
I called it that because I thought we might be able to support
nested namespaces --- but it'd really create a mess. In particular,
the SQL standard says what a three-part name means, and this
On 05.02.22 00:55, Chapman Flack wrote:
I'm thinking plhandler.sgml is the only place that really needs to be
said; readers looking up CREATE TRANSFORM and using an existing PL that
supports it don't need to know how the sausage is made. (Maybe it is
worth mentioning there, though, that it isn't
On 2/6/22 19:39, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Feb 06, 2022 at 08:32:59AM -0500, Andrew Dunstan wrote:
>>> But the commit really shouldn't have happened until we know that most
>>> buildfarm owners have installed it. It should have waited wait not just
>>> for the release
On Mon, Feb 7, 2022 at 8:44 AM Esteban Zimanyi
wrote:
> May I kindly ask your insight about a question I posted 1 month ago and
> for which I never received any answer ?
>
-hackers really isn't the correct place for usage questions like this -
even if you are creating a custom type (why you are
On Mon, Feb 07, 2022 at 04:44:24PM +0100, Peter Eisentraut wrote:
> On 07.02.22 11:29, Julien Rouhaud wrote:
>
> > - there is no test
>
> Suggestions where to put it? We don't really have tests for the
> collation-level versioning either, do we?
There's so limited testing in collate.* regressio
On Mon, Feb 7, 2022 at 12:26 AM Dilip Kumar wrote:
> I have splitted the patch into multiple patches which can be
> independently committable and easy to review. I have explained the
> purpose and scope of each patch in the respective commit messages.
Hmm. The parts of this I've looked at seem re
On 2/7/22 10:35, Robert Haas wrote:
On Sun, Feb 6, 2022 at 12:24 PM Tom Lane wrote:
Joe Conway writes:
> I'd like to pick this patch up and see it through to commit/push.
> Presumably that will include back-patching to all supported pg versions.
> Before I go through the effort to back-patch,
On 2022/02/02 21:59, torikoshia wrote:
This may cause users to misunderstand that pg_log_query_plan() fails
while the target backend is holding *any* locks? Isn't it better to
mention "page-level locks", instead? So how about the following?
--
Note that the request to
On 2/2/22 14:50, Daniel Gustafsson wrote:
>> On 2 Feb 2022, at 17:09, Andrew Dunstan wrote:
>> On 2/2/22 08:26, Daniel Gustafsson wrote:
>>> Thoughts? I'm fairly sure there are many crimes against Perl in this patch,
>>> I'm happy to take pointers on how to improve that.
>> It feels a bit odd to
On Mon, Feb 7, 2022 at 9:42 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 12:26 AM Dilip Kumar wrote:
> > I have splitted the patch into multiple patches which can be
> > independently committable and easy to review. I have explained the
> > purpose and scope of each patch in the respective co
On Mon, Feb 07, 2022 at 11:00:22AM -0500, Andrew Dunstan wrote:
>
> On 2/6/22 19:39, Tom Lane wrote:
> >
> > I note, though, that there's still not been any email to the buildfarm
> > owners list about this update.
>
> The announcement was held up in list moderation for 20 hours or so.
I've cert
On Fri, Feb 4, 2022 at 4:12 PM Peter Geoghegan wrote:
> I had imagined that we'd
> want to do heap vacuuming in the same way as today with the dead TID
> conveyor belt stuff -- it just might take several VACUUM operations
> until we are ready to do a round of heap vacuuming.
I am trying to unders
On Mon, Feb 7, 2022 at 10:08 AM Robert Haas wrote:
> But ... if I'm not mistaken, in the kind of case that Greg is
> describing, relfrozenxid will be advanced exactly as often as it is
> today.
But what happens today in a scenario like Greg's is pathological,
despite being fairly common (common i
On Mon, Feb 7, 2022 at 11:31 AM Dilip Kumar wrote:
> For RelFileNode also we need to use 2, 32-bit integers so that we do
> not add extra alignment padding because there are a few more
> structures that include RelFileNode e.g. xl_xact_relfilenodes,
> RelFileNodeBackend, and many other structures.
Many thanks for your prompt reply David. Allow me then to restate the
questions, hoping that this better fits this mailing list.
MobilityDB is a time-series extension to PostgreSQL/PostGIS in which
time-varying attributes (e.g., gear, GPS location of a car) are
semantically grouped into "units" (e
[ cc'ing Alvaro for pipeline questions ]
Fabien COELHO writes:
>> It is annoying that some of the text is duplicated in the second
>> report, but in the end that's cosmetic, and I'm not sure we can
>> improve it without breaking other things. In particular, we
>> can't just think about what come
On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> Easily worked around with one additional level of role:
Interesting.
> > But in the absence of that, it seems clearly better for predefined
> > roles to disregard INHERIT and just always grant the rights they are
> > intended to give. Because i
On Mon, Feb 7, 2022 at 9:58 AM Esteban Zimanyi
wrote:
>
> As suggested by David, this goes beyond the "traditional" usage of
> PostgreSQL. Therefore my questions are
> * What is the suggested strategy to splitting these 2K attributes into
> vertically partitioned tables where the tables are linke
On Mon, Feb 07, 2022 at 10:10:53AM -0700, David G. Johnston wrote:
> On Mon, Feb 7, 2022 at 9:58 AM Esteban Zimanyi
> wrote:
>
> >
> > As suggested by David, this goes beyond the "traditional" usage of
> > PostgreSQL. Therefore my questions are
> > * What is the suggested strategy to splitting th
On Mon, Feb 7, 2022 at 11:43 AM Peter Geoghegan wrote:
> > That's because, if VACUUM is only ever getting triggered by XID
> > age advancement and not by bloat, there's no opportunity for your
> > patch set to advance relfrozenxid any sooner than we're doing now.
>
> We must distinguish between:
>
On Mon, Feb 7, 2022 at 12:09 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> > Easily worked around with one additional level of role:
>
> Interesting.
>
> > > But in the absence of that, it seems clearly better for predefined
> > > roles to disregard INHERIT and jus
Dear David
There are two approaches for storing temporal information in a relational
database, explored since the 1980s following the work of Richard Snodgrass
http://www2.cs.arizona.edu/~rts/publications.html
tuple-timestamping vs attribute-timestamping. The SQL standard used the
tuple-timestamp
On Mon, Feb 7, 2022 at 12:21 PM Robert Haas wrote:
>
> On Mon, Feb 7, 2022 at 11:43 AM Peter Geoghegan wrote:
> > > That's because, if VACUUM is only ever getting triggered by XID
> > > age advancement and not by bloat, there's no opportunity for your
> > > patch set to advance relfrozenxid any s
On 2022/02/07 14:35, Etsuro Fujita wrote:
0001 patch failed to be applied. Could you rebase the patch?
Done. Attached is an updated version of the patch set.
Thanks for updating the patch! Here are the review comments for 0001 patch.
I got the following compiler warning.
[16:58:07.120]
Yes, that's what I meant. That's always how I thought that it would work,
for over a year now. I might have jumped to the conclusion that that's what
you had in mind all along. Oops.
Although this design is simpler, which is an advantage, that's not really
the point. The point is that it makes se
Hi,
On 2022-02-07 08:44:00 +0530, Amit Kapila wrote:
> Right, and it is getting changed. We are just printing the first 200
> characters (by using SQL [1]) from the decoded tuple so what is shown
> in the results is the initial 200 bytes.
Ah, I knew I must have been missing something.
> The com
Hi,
I've been wondering whether we should try to have the generated pg_config.h
look as similar as possible to autoconf/autoheader's, or not. And whether the
way autoconf/autoheader define symbols makes sense when not using either
anymore.
To be honest, I do not really understand the logic behind
On 02/07/22 10:59, Peter Eisentraut wrote:
> On 05.02.22 00:55, Chapman Flack wrote:
>> I'm thinking plhandler.sgml is the only place that really needs to be
>> ...
>> worth mentioning there, though, that it isn't possible to develop
>> transforms for an arbitrary PL unless that PL applies transfor
Hi!
On Mon, Feb 7, 2022 at 11:42 AM Aliaksandr Kalenik wrote:
> Thanks for your review!
>
> On Sun, Jan 30, 2022 at 7:24 PM Tom Lane wrote:
> > Actually, that code has got worse problems than that. I tried to improve
> > our regression tests to exercise that code path, as attached. What I got
Hi,
On 2022-02-07 13:38:38 +0530, Ashutosh Sharma wrote:
> Are you talking about this scenario - what if the logical replication
> slot on the publisher is dropped, but is being referenced by the
> standby where the slot is synchronized?
It's a bit hard to say, because neither in this thread nor
Hi,
On 2022-01-03 14:46:52 +0100, Peter Eisentraut wrote:
> +static void
> +ApplyLauncherStartSlotSync(TimestampTz *last_start_time, long *wait_time)
> +{
> [...]
> +
> + foreach(lc, slots)
> + {
> + WalRecvReplicationSlotData *slot_data = lfirst(lc);
> + LogicalRep
Andres Freund writes:
> I've been wondering whether we should try to have the generated pg_config.h
> look as similar as possible to autoconf/autoheader's, or not. And whether the
> way autoconf/autoheader define symbols makes sense when not using either
> anymore.
> To be honest, I do not really
On 10/05/21 14:00, Chapman Flack wrote:
> On 10/05/21 13:47, Tom Lane wrote:
>>> An alternative I've sometimes used elsewhere is to typedef the function
>>> type itself, and use the * when declaring a pointer to it:
>>> typedef void Furbinator(char *furbee);
>>
>> Is that legal C? I doubt that it
Unless I'm misreading this code I think the nevents in
WaitLatchOrSocket should really be 4 not 3. At least there are 4 calls
to AddWaitEventToSet in it and I think it's possible to trigger all 4.
I guess it's based on knowing that nobody would actually set
WL_EXIT_ON_PM_DEATH and WL_POSTMASTER_DE
Peter Eisentraut writes:
> I've been struggling to make progress on this. First, throwing the
> Python exception suggested in #1 above would require a significant
> amount of new code. (We have code to create an exception out of
> ErrorData, but no code to make one up from nothing.) This wou
Hi,
Thank you for your updating the patch.
I'll quote one of the past discussions
in order to make this thread go forward or more active.
On Friday, August 13, 2021 8:01 PM Ajin Cherian wrote:
> On Mon, Aug 2, 2021 at 7:20 PM Amit Kapila
> wrote:
> >
> > On Fri, Jul 23, 2021 at 3:39 PM Ajin Ch
Hi!
On 02/07/22 00:59, Böszörményi Zoltán wrote:
> UPDATE ... WHERE OFFSET n IN cursor;
If added to UPDATE, should this be added to DELETE also?
Regards,
-Chap
On 2022/02/08 7:00, Greg Stark wrote:
Unless I'm misreading this code I think the nevents in
WaitLatchOrSocket should really be 4 not 3. At least there are 4 calls
to AddWaitEventToSet in it and I think it's possible to trigger all 4.
Good catch! I think you're right.
As the quick test, I c
On Tue, Feb 8, 2022 at 1:48 PM Fujii Masao wrote:
> On 2022/02/08 7:00, Greg Stark wrote:
> > Unless I'm misreading this code I think the nevents in
> > WaitLatchOrSocket should really be 4 not 3. At least there are 4 calls
> > to AddWaitEventToSet in it and I think it's possible to trigger all 4.
Chapman Flack writes:
> On 02/07/22 00:59, Böszörményi Zoltán wrote:
>> UPDATE ... WHERE OFFSET n IN cursor;
> If added to UPDATE, should this be added to DELETE also?
FWIW, I think this is a really horrid hack. For one thing, it's not
robust against not-strictly-linear FETCH/MOVE of the cursor
Hi,
I was trying to fix a few perl embedding oddities in the meson
patchset.
Whenever I have looked at the existing code, I've been a bit confused about
the following
code/comment in perl.m4:
# PGAC_CHECK_PERL_EMBED_LDFLAGS
# -
# We are after Embed's ldopts, but with
Hi,
On 2022-02-07 16:30:53 -0500, Tom Lane wrote:
> > A second aspect that I'm wondering about is whether we should try to split
> > pg_config.h output a bit:
>
> TBH I can't get excited about that. I do not think that rebuilding
> with different options is a critical path. ccache already does
Andres Freund writes:
> What is the reason behind subtracting ccdlflags?
It looks like the coding actually originated here:
commit f5d0c6cad5bb2706e0e63f3f8f32e431ea428100
Author: Bruce Momjian
Date: Wed Jun 20 00:26:06 2001 +
Apparently, on some systems, ExtUtils::Embed and MakeMake
On 2/6/22 10:20 PM, Justin Pryzby wrote:
On Sun, Feb 06, 2022 at 08:01:02PM -0500, Jonathan S. Katz wrote:
Hi,
Attached is a draft for the release announcement for the 2022-02-10
cumulative update release.
Please review for technical accuracy or if you believe any items should be
added/removed
On Sun, Feb 06, 2022 at 09:04:14PM -0600, Justin Pryzby wrote:
> Your test is checking that stuff in sample.conf is actually a GUC and not
> marked NOT_IN_SAMPLE. But those are both unlikely mistakes to make.
Yeah, you are right. Still, I don't see any reason to not include both.
> I'd first pa
Hi,
During the last commit fest, some new contributors mentioned me that they were
having trouble to find patch to review.
And indeed, the commit fest app doesn't provide any kind of information about
the patch difficulty (which is different from the patch size, so you can't even
try to estimate
I wrote:
> Andres Freund writes:
>> What is the reason behind subtracting ccdlflags?
> It looks like the coding actually originated here:
> commit f5d0c6cad5bb2706e0e63f3f8f32e431ea428100
Ah, here's the thread leading up to that:
https://www.postgresql.org/message-id/flat/200106191206.f5JC6R108
On Mon, Feb 07, 2022 at 02:00:25PM -0500, Tom Lane wrote:
> Not too surprisingly, these patches broke during the commitfest.
> Here's a rebased version.
>
> I'm not sure that anyone wants to review these in detail ...
> should I just go ahead and push them?
I don't see anything shocking after a q
On Sat, Jan 28, 2022 at 19:36 PM Fabrice Chapuis
wrote:
> shouldn't we use receiver_timeout in place of wal_sender_timeout because de
> problem comes from the consummer.
Thanks for your review.
IMO, because it is a bug fix on the publisher-side, and the keepalive message
is sent based on wal_sen
On Wed, Jan 26, 2022 at 11:37 AM I wrote:
> On Sat, Jan 22, 2022 at 7:12 PM Amit Kapila wrote:
> > Now, one idea to solve this problem could be that whenever we skip
> > sending any change we do try to update the plugin progress via
> > OutputPluginUpdateProgress(for walsender, it will invoke
> >
On Tue, Feb 08, 2022 at 10:44:07AM +0900, Michael Paquier wrote:
> What do you think about the updated version attached? I have applied
> the addition of config_data() separately.
Looks fine
> + # Check if this line matches a GUC parameter.
> + if ($line =~ m/^#?([_[:alpha:]]+) (= .*|[^
Hi,
On 2022-02-07 20:42:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > What is the reason behind subtracting ccdlflags?
>
> It looks like the coding actually originated here:
>
> commit f5d0c6cad5bb2706e0e63f3f8f32e431ea428100
> Author: Bruce Momjian
> Date: Wed Jun 20 00:26:06 2001 +00
Hi all,
(Added Bruce and Julien in CC)
While testing installcheck with various server configurations to see
how the main regression test suites could break, I found that loading
pg_stat_statements into the backend is enough to break installcheck
as compute_query_id = auto, the default, lets the de
Hi,
On Tue, Feb 08, 2022 at 12:38:46PM +0900, Michael Paquier wrote:
>
> While testing installcheck with various server configurations to see
> how the main regression test suites could break, I found that loading
> pg_stat_statements into the backend is enough to break installcheck
> as compute_
On Tue, Feb 08, 2022 at 11:48:15AM +0800, Julien Rouhaud wrote:
> That's already been discussed in [1] and rejected, as it would also mean
> losing
> the ability to have pg_stat_statements (or any similar extension) coverage
> using the regression tests. I personally rely on regression tests for
On 2022/02/08 9:51, Thomas Munro wrote:
an index instead of a pointer...) or, since it's a bit silly to add
both of those events, maybe we should do:
- if ((wakeEvents & WL_POSTMASTER_DEATH) && IsUnderPostmaster)
- AddWaitEventToSet(set, WL_POSTMASTER_DEATH, PGINVALID_SOCK
On Mon, Feb 07, 2022 at 09:07:28PM -0600, Justin Pryzby wrote:
> I think this is the regex I wrote to handle either "name = value" or "name
> value", which was needed between f47ed79cc..4d7c3e344. See skip_equals.
Yes, I took it from there, noticing that it was working just fine for
this purpose
On Tue, Feb 08, 2022 at 12:56:59PM +0900, Michael Paquier wrote:
> On Tue, Feb 08, 2022 at 11:48:15AM +0800, Julien Rouhaud wrote:
> > That's already been discussed in [1] and rejected, as it would also mean
> > losing
> > the ability to have pg_stat_statements (or any similar extension) coverage
Thank you for the comments!
if (FullTransactionIdFollows(fxid1, fxid2))
PG_RETURN_FULLTRANSACTIONID(fxid1);
else
PG_RETURN_FULLTRANSACTIONID(fxid2);
Isn't it better to use '0x'::xid8 instead of
'18446744073709551615'::xid8, to more easily understand that this test
use
On 2022/02/08 13:23, Ken Kato wrote:
Thank you for the comments!
if (FullTransactionIdFollows(fxid1, fxid2))
PG_RETURN_FULLTRANSACTIONID(fxid1);
else
PG_RETURN_FULLTRANSACTIONID(fxid2);
Isn't it better to use '0x'::xid8 instead of
'18446744073709551615'::xid8, to m
Hello!
On 26.01.2022 16:43, Andrei Zubkov wrote:
>>
>> If you're worried about some external table having a NOT NULL
>> constraint for
>> those fields, how about returning NaN instead? That's a valid value
>> for a
>> double precision data type.
>
> I don't know for sure what we can expect to b
On Tue, Feb 8, 2022 at 12:48 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-07 08:44:00 +0530, Amit Kapila wrote:
> > Right, and it is getting changed. We are just printing the first 200
> > characters (by using SQL [1]) from the decoded tuple so what is shown
> > in the results is the initial 200
At Mon, 7 Feb 2022 13:51:31 +0900, Fujii Masao
wrote in
>
>
> On 2022/02/07 12:02, Kyotaro Horiguchi wrote:
> > - If any later checkpoint/restartpoint has been established, just skip
> >remaining task then return false. (!chkpt_was_latest)
> >(I'm not sure this can happen, though.)
> >
79 matches
Mail list logo