Instead of defining the same set of macros several times, define it once
in an appropriate header file. In passing, convert to inline functions.From 11227ec513c9f6fd05d8286156c63ebc9c200017 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 6 Feb 2023 10:48:32 +0100
Subject: [PATCH] Cons
I'm writing my own patch for this problem. While playing around with
it, I noticed this:
struct Command {
PQExpBufferDatalines;/* 024 */
char * first_line; /*24 8 */
inttype;
On 06/02/2023 11:54, Peter Eisentraut wrote:
Instead of defining the same set of macros several times, define it once
in an appropriate header file. In passing, convert to inline functions.
Looks good to me. Did you consider moving PG_GETARG_ITEMPOINTER and
PG_RETURN_ITEMPOINTER, too? They're
Hi,
while reading the code, I noticed that in pa_send_data() we set wait event
to WAIT_EVENT_LOGICAL_PARALLEL_APPLY_STATE_CHANGE while sending the
message to the queue. Because this state is used in multiple places, user might
not be able to distinguish what they are waiting for. So It seems we'd
Hi,
> > So we're really quite surprised that it has got so little feedback. We've
> > got
> > some opinions on approach but there is no any general one on the approach
> > itself except doubts about the TOAST mechanism needs revision at all.
>
> The problem for me is that what you've been posting
> > > Here is first version of my patch using the
> > > @extschema:extensionname@ syntax you proposed.
> > >
> > > This patch includes:
> > > 1) Changes to replace references of @extschema:extensionname@ with
> > > the schema of the required extension
> > > 2) Documentation for the feature
> > > 3)
Dear Hou,
> while reading the code, I noticed that in pa_send_data() we set wait event
> to WAIT_EVENT_LOGICAL_PARALLEL_APPLY_STATE_CHANGE while sending
> the
> message to the queue. Because this state is used in multiple places, user
> might
> not be able to distinguish what they are waiting for
On 2023-Feb-06, Nikita Malakhov wrote:
> Currently we're busy revising the whole Pluggable TOAST API to make it
> available as an extension and based on hooks to minimize changes in
> the core. It will be available soon.
Hmm, I'm not sure why would PGDG want to accept such a thing. I read
"minim
Corey Huinker wrote:
> Manually testing confirms that it works, at least for the connected state. I
> don't actually know how get psql to invoke DISCONNECT, so I killed the dev
> server and can confirm
Maybe something like this could be used, with no external action:
postgres=# \echo :
On Monday, February 6, 2023 6:34 PM Kuroda, Hayato
wrote:
> > while reading the code, I noticed that in pa_send_data() we set wait
> > event to WAIT_EVENT_LOGICAL_PARALLEL_APPLY_STATE_CHANGE while
> sending
> > the message to the queue. Because this state is used in multiple
> > places, user migh
On Mon, Feb 6, 2023 at 12:36 PM Takamichi Osumi (Fujitsu)
wrote:
>
I have made a couple of changes in the attached: (a) changed a few
error and LOG messages; (a) added/changed comments. See, if these look
good to you then please include them in the next version.
--
With Regards,
Amit Kapila.
On Tue, Jan 24, 2023 at 5:02 AM Euler Taveira wrote:
>
>
> - elog(DEBUG2, "sending feedback (force %d) to recv %X/%X, write %X/%X,
> flush %X/%X in-delayed: %d",
> + elog(DEBUG2, "sending feedback (force %d) to recv %X/%X, write %X/%X,
> flush %X/%X, apply delay: %s",
> force,
>
I wrote:
> > In the varlistentry, I suggest we add "This variable is unset when the
> > connection is lost." after "but can be changed or unset.
>
> Personally I'd much rather have BACKEND_PID set to 0 rather than being unset
> when not connected. For one thing it allows safely using \if
On Monday, February 6, 2023 8:51 PM Amit Kapila wrote:
> On Mon, Feb 6, 2023 at 12:36 PM Takamichi Osumi (Fujitsu)
> wrote:
> >
>
> I have made a couple of changes in the attached: (a) changed a few error and
> LOG messages; (a) added/changed comments. See, if these look good to you
> then pleas
Hi,
On Monday, February 6, 2023 8:57 PM Amit Kapila wrote:
> On Tue, Jan 24, 2023 at 5:02 AM Euler Taveira wrote:
> >
> >
> > - elog(DEBUG2, "sending feedback (force %d) to recv %X/%X,
> write %X/%X, flush %X/%X in-delayed: %d",
> > + elog(DEBUG2, "sending feedback (force %d) to recv %X/%X,
Hi!
Existing TOAST has several very painful drawbacks - lack of UPDATE
operation, bloating of TOAST tables, and limits that are implicitly implied
on base tables by their TOAST tables, so it is seems not fair to say that
Pluggable TOAST does not solve any problems but just introduces new
ones.
Th
Hi,
> > So to clarify, are we talking about tuple-level compression? Or
> > perhaps page-level compression?
>
> Tuple level.
>
> What I think we should do is basically this:
>
> When we compress datums, we know the table being targeted. If there's a
> pg_attribute parameter indicating we should, w
po 6. 2. 2023 v 13:03 odesílatel Daniel Verite
napsal:
> I wrote:
>
> > > In the varlistentry, I suggest we add "This variable is unset when the
> > > connection is lost." after "but can be changed or unset.
> >
> > Personally I'd much rather have BACKEND_PID set to 0 rather than being
>
Hi,
> The main reason behind this decision is that keeping the first implementation
> on the side of the vanilla (I mean rebasing it) over time is very difficult
> due
> to the very invasive nature of this solution.
>
> So we decided to reduce changes in the core to the minimum necessary
> to mak
On Sat, Feb 4, 2023 at 12:37 PM Tom Lane wrote:
> But it's not clear to me why you're allergic to the perl wrapper?
> It's not like that's the only perl infrastructure in our build process.
> Also, whether or not we could push some of what it does into pg_bsd_indent
> proper, I can't see pushing a
Robert Haas writes:
> I don't mind that there is a script. I do mind that it's not that good
> of a script. There have been some improvements for which I am
> grateful, like removing the thing where the first argument was taken
> as a typedefs file under some circumstances. But there are still som
On Mon, 6 Feb 2023 at 15:03, Aleksander Alekseev
wrote:
>
> Hi,
>
> I see your point regarding the fact that creating dictionaries on a
> training set is too beneficial to neglect it. Can't argue with this.
>
> What puzzles me though is: what prevents us from doing this on a page
> level as sugges
On 2023-02-06 Mo 09:40, Robert Haas wrote:
On Sat, Feb 4, 2023 at 12:37 PM Tom Lane wrote:
But it's not clear to me why you're allergic to the perl wrapper?
It's not like that's the only perl infrastructure in our build process.
Also, whether or not we could push some of what it does into pg_b
Alvaro Herrera writes:
> I'm writing my own patch for this problem. While playing around with
> it, I noticed this:
> struct Command {
> /* size: 2168, cachelines: 34, members: 11 */
> /* sum members: 2164, holes: 1, sum holes: 4 */
> /* last cacheline: 56 bytes */
> };
I think the
On Mon, Feb 6, 2023 at 10:16 AM Tom Lane wrote:
> I'll just note that adding features like those to a Perl script
> is going to be a ton easier than doing it inside pg_bsd_indent.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
> Good suggestions. 1 and 3 seem fairly straightforward. I'll start on those,
> and look into 2.
Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branches.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enter
On Thu, Feb 2, 2023 at 11:22 PM Bharath Rupireddy
wrote:
> I took the v4 patch, added some comments and attached it as the v7
> patch here. Please find it.
Committed and back-patched to v15.
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas writes:
> On Thu, Feb 2, 2023 at 11:22 PM Bharath Rupireddy
> wrote:
>> I took the v4 patch, added some comments and attached it as the v7
>> patch here. Please find it.
> Committed and back-patched to v15.
Umm ... is this really the sort of patch to be committing on a
release wrap
On Mon, Feb 6, 2023 at 11:07 AM Tom Lane wrote:
> Umm ... is this really the sort of patch to be committing on a
> release wrap day?
Oh, shoot, I wasn't thinking about that. Would you like me to revert
it in v15 for now?
--
Robert Haas
EDB: http://www.enterprisedb.com
Andrew Dunstan writes:
> I recently moved crake to a new machine running Fedora 36, which has
> OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
> than release 13, so I propose to backpatch commit f0d2c65f17 to the
> release 11 and 12 branches.
Hmm ... according to that com
Robert Haas writes:
> On Mon, Feb 6, 2023 at 11:07 AM Tom Lane wrote:
>> Umm ... is this really the sort of patch to be committing on a
>> release wrap day?
> Oh, shoot, I wasn't thinking about that. Would you like me to revert
> it in v15 for now?
Yeah, seems like the safest course. I wouldn'
On Sat, Feb 4, 2023 at 11:29 PM jack...@gmail.com wrote:
> When I use 'select * from t where a = 1'; And I debug to find where the 'a =
> 1' is used,
> when I arrive ExecScan in src/backend/executor/execScan.c, line 158, where
> this 'a = 1' is
> stored in?
It depends somewhat on what query pla
On 2022/10/19 13:25, Tatsuo Ishii wrote:
Thanks. the v6 patch pushed to master branch.
Since this commit, make_etags has started failing to generate
tags files with the following error messages, on my MacOS.
$ src/tools/make_etags
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeD
Hi,
The cfbot on "Windows - Server 2019, VS 2019 - Meson & ninja" is failing
the regression tests with the error:
ERROR: unsupported XML feature
DETAIL: This functionality requires the server to be built with libxml
support.
Is there anything I can do to enable libxml to run my regression
On Wed, Feb 1, 2023 at 3:37 PM Jacob Champion wrote:
> > I'm not an expert on this stuff, but to me that feels like a weak and
> > fuzzy concept. If the client is going to tell the server something,
> > I'd much rather have it say something like "i'm proxying a request
> > from my local user rhaas
On Mon, Feb 6, 2023 at 11:15 AM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Feb 6, 2023 at 11:07 AM Tom Lane wrote:
> >> Umm ... is this really the sort of patch to be committing on a
> >> release wrap day?
>
> > Oh, shoot, I wasn't thinking about that. Would you like me to revert
> > it i
Jim Jones writes:
> The cfbot on "Windows - Server 2019, VS 2019 - Meson & ninja" is failing
> the regression tests with the error:
> ERROR: unsupported XML feature
> DETAIL: This functionality requires the server to be built with libxml
> support.
> Is there anything I can do to enable libx
James Coleman wrote:
> On Sat, Jan 21, 2023 at 10:07 PM James Coleman wrote:
> > ...
> > While working through Tomas's comment about a conditional in the
> > max_parallel_hazard_waker being guaranteed true I realized that in the
> > current version of the patch the safe_param_ids tracking in
> >
On Sun, Feb 5, 2023 at 6:28 AM Andres Freund wrote:
> On the other hand, it also just seems risky from a code writing perspective.
> It's not immediate obvious that it'd be unsafe to create an on-stack Numeric
> by assigning *ptr. But it is.
Well, I think that is pretty obvious: we have lots of
Robert Haas writes:
> I do not really know exactly how to do that, though. Our usual pattern
> is to just have a struct and end with a variable-length array, or
> alternatively add a comment says "other stuff follows!" at the end of
> the struct definition, without doing anything that C knows abou
On 2023-02-06 Mo 10:36, Robert Haas wrote:
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
Good suggestions. 1 and 3 seem fairly straightforward. I'll start on those, and
look into 2.
Thanks!
Here's a quick patch for 1 and 3. Would also need to adjust the docco.
cheers
andrew
-
On 02.02.23 07:40, Tom Lane wrote:
Noah Misch writes:
Regarding the concern about a pre-receive hook blocking an emergency push, the
hook could approve every push where a string like "pgindent: no" appears in a
commit message within the push. You'd still want to make the tree clean
sometime th
Em seg., 6 de fev. de 2023 às 10:59, Erik Wienhold
escreveu:
> > On 06/02/2023 12:20 CET Marcos Pegoraro wrote:
> >
> > I was just playing with some random timestamps for a week, for a month,
> > for a year ...
> >
> > select distinct current_date+((random()::numeric)||'month')::interval
> from
>> And yes, probably you need to change the way you reply to email on
>> this list. Top-posting is generally avoided. See
>> https://wiki.postgresql.org/wiki/Mailing_Lists.
>Thanks for bringing this into the discussion :)
Thinking these days more about this topic, subscriber name is not a bad
ide
On 2023-02-06 Mo 12:03, Andrew Dunstan wrote:
On 2023-02-06 Mo 10:36, Robert Haas wrote:
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
Good suggestions. 1 and 3 seem fairly straightforward. I'll start on those, and
look into 2.
Thanks!
Here's a quick patch for 1 and 3. Would al
On 06.02.23 17:23, Tom Lane wrote:
Your patch needs to also update expected/xml_1.out to match the output
the test produces when run without --with-libxml.
Thanks a lot! It seems to do the trick.
xml_1.out updated in v4.
Best, Jim
From ced9fccddc033de98709a6e93dc6530ce68149db Mon Sep 17 00:00
Hi,
Attached is a draft of the announcement for the 2023-02-09 update release.
Please review and provide corrections, notable omissions, and
suggestions no later than 2023-02-09 0:00 AoE.
Thanks!
Jonathan
The PostgreSQL Global Development Group has released an update to all supported
version
Hi
On 2023-02-06 11:42:57 -0500, Robert Haas wrote:
> On Sun, Feb 5, 2023 at 6:28 AM Andres Freund wrote:
> > On the other hand, it also just seems risky from a code writing
> > perspective. It's not immediate obvious that it'd be unsafe to create an
> > on-stack Numeric by assigning *ptr. But
Hi,
On 2023-02-06 11:55:40 -0500, Tom Lane wrote:
> I am, however, very dubious that Andres is correct that there's a
> problem here. Given that two of the variants of union NumericChoice
> are structs ending with a flexible array, any compiler that thinks
> it knows the size of the union precise
On Fri, Jan 27, 2023 at 12:34 PM Jeff Davis wrote:
> It is non-deterministic, but I tried with two generated files, and got
> similar results.
Jeff and I coordinated off-list. It turned out that the
nondeterministic nature of the program to generate test data was
behind my initial inability to re
On 1/29/23 19:08, Tomas Vondra wrote:
>
>
> On 1/29/23 18:53, Andres Freund wrote:
>> Hi,
>>
>> On 2023-01-29 18:39:05 +0100, Tomas Vondra wrote:
>>> Will do, but I'll wait for another lockup to see how frequent it
>>> actually is. I'm now at ~90 runs total, and it didn't happen again yet.
>>> So
On Mon, Feb 6, 2023 at 1:28 PM Andres Freund wrote:
> Perhaps something like
Yeah, that'd work. You'd want a big ol' warning comment here:
> typedef struct NumericData
> {
> int32 vl_len_;/* varlena header (do not
> touch directly!) */
> NumericBase dat
On Fri, Feb 3, 2023 at 3:47 AM Andres Freund wrote:
> On 2023-02-02 09:28:03 -0500, Robert Haas wrote:
> > I don't know what you mean by this. DML doesn't confer privileges. If
> > code gets executed and runs with the replication user's credentials,
> > that could lead to privilege escalation, but
Hi,
On 2023-02-06 14:07:39 -0500, Robert Haas wrote:
> On Fri, Feb 3, 2023 at 3:47 AM Andres Freund wrote:
> > On 2023-02-02 09:28:03 -0500, Robert Haas wrote:
> > > I don't know what you mean by this. DML doesn't confer privileges. If
> > > code gets executed and runs with the replication user's
Hi,
On 2023-02-06 19:51:19 +0100, Tomas Vondra wrote:
> > No. The only thing the machine is doing is
> >
> > while /usr/bin/true; do
> > make check
> > done
> >
> > I can't reduce the workload further, because the "join" test is in a
> > separate parallel group (I cut down parallel_sched
On Fri, Jan 27, 2023 at 12:29 PM Jeff Davis wrote:
> I am using these GUCs for testing the various collation paths in my
> collation refactoring branch.
Speaking of testing, has anyone ever tried porting Tom's random test
program[1] to ICU?
[1] https://www.postgresql.org/message-id/31913.1458747
Hi,
On 2023-02-06 16:38:01 +0300, Nikita Malakhov wrote:
> So we decided to reduce changes in the core to the minimum necessary
> to make it available through the hooks, because the hooks part is very
> lightweight and simple to keep rebasing onto the vanilla core.
At least I don't think we shoul
Hi,
On 2023-02-06 16:16:41 +0100, Matthias van de Meent wrote:
> On Mon, 6 Feb 2023 at 15:03, Aleksander Alekseev
> wrote:
> >
> > Hi,
> >
> > I see your point regarding the fact that creating dictionaries on a
> > training set is too beneficial to neglect it. Can't argue with this.
> >
> > What
On Mon, Feb 6, 2023 at 2:18 PM Andres Freund wrote:
> It's decidedly not great, yes. I don't know if it's quite a CVE type issue,
> after all, the same is true for any other type of query the superuser
> executes. But at the very least the documentation needs to be better, with a
> big red box mak
On 2/6/23 03:00, Andrey Borodin wrote:
> On Sun, Feb 5, 2023 at 5:51 PM Tomas Vondra
> wrote:
>>
>> On 2/5/23 19:36, Andrey Borodin wrote:
>>> On Fri, Jan 6, 2023 at 10:02 PM Andrey Borodin
>>> wrote:
Hello! Please find attached v8.
>>>
>>> I got some interesting feedback from some
On Mon, 6 Feb 2023 at 20:24, Andres Freund wrote:
>
> Hi,
>
> On 2023-02-06 16:38:01 +0300, Nikita Malakhov wrote:
> > So we decided to reduce changes in the core to the minimum necessary
> > to make it available through the hooks, because the hooks part is very
> > lightweight and simple to keep
On Mon, 6 Feb 2023 at 15:38, Aleksander Alekseev
wrote:
> I would like to point out however that there were several other pieces
> of feedback that could have been missed:
>
> * No one wants to see this as an extension. This was my original
> proposal (adding ZSON to /contrib/) and it was rejected
On Mon, Feb 6, 2023 at 11:57 AM Tomas Vondra
wrote:
>
> I wonder what that means for the patch. I haven't investigated this at
> all, but it seems as if the optimization means we fail to find a match,
> producing a tad larger output. That may be still be a good tradeoff, as
> long as the output is
Hi,
It'll be great to see more opinions on the approach as a whole.
>The problem that I see being raised here, is that there was little
>discussion and no observed community consensus about the design of
>this complex feature *before* this patch with high complexity was
>provided.
>The next actio
Hi,
> From 098f37c0a17fc32a94bff43817414e01fcfb234f Mon Sep 17 00:00:00 2001
> From: Rishu Bagga
> Date: Thu, 15 Sep 2022 00:55:25 +
> Subject: [PATCH] slru to buffercache + page headers + upgrade
>
> ---
> contrib/amcheck/verify_nbtree.c |2 +-
> [...]
> 65 files changed,
Hi,
On 2023-02-06 12:23:54 +0530, Amit Kapila wrote:
> On Mon, Feb 6, 2023 at 10:33 AM Andres Freund wrote:
> > Smart shutdown is practically unusable. I don't think it makes sense to tie
> > behavior of walsender to it in any way.
> >
>
> So, we have the following options: (a) do nothing for t
Hi,
On 2023-02-04 11:10:55 -0800, Peter Geoghegan wrote:
> On Sat, Feb 4, 2023 at 2:57 AM Andres Freund wrote:
> > Is there a good way to make breakage in the page recycling mechanism
> > visible with gist? I guess to see corruption, I'd have to halt a scan
> > before a page is visited with gdb,
On 2023-02-06 Mo 12:17, Peter Eisentraut wrote:
On 02.02.23 07:40, Tom Lane wrote:
Noah Misch writes:
Regarding the concern about a pre-receive hook blocking an emergency
push, the
hook could approve every push where a string like "pgindent: no"
appears in a
commit message within the push.
On 04.02.23 14:41, Daniel Verite wrote:
However it still leaves "daticurules" empty in the destination db,
because of an actual bug in the current patch.
Looking at createdb() in commands.c, it creates this variable:
@@ -711,6 +714,7 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
On 2023-02-06 Mo 11:13, Tom Lane wrote:
Andrew Dunstan writes:
I recently moved crake to a new machine running Fedora 36, which has
OpenSSL 3.0.0. This causes the SSL tests to fail on branches earlier
than release 13, so I propose to backpatch commit f0d2c65f17 to the
release 11 and 12 branche
Hi,
On 2023-02-06 18:17:02 +0100, Peter Eisentraut wrote:
> First, as a matter of principle, it would introduce another level of
> gatekeeping power. Right now, the committers are as a group in charge of
> what gets into the tree. Adding commit hooks that are installed
> somewhere(?) by someone(
Andres Freund writes:
> On 2023-02-06 18:17:02 +0100, Peter Eisentraut wrote:
>> First, as a matter of principle, it would introduce another level of
>> gatekeeping power. Right now, the committers are as a group in charge of
>> what gets into the tree. Adding commit hooks that are installed
>>
On Wed, Feb 1, 2023 at 2:44 PM Thomas Munro wrote:
> OK, I pushed that. Third time lucky?
I pulled down logs for a week of Windows CI, just over ~1k builds.
The failure rate was a few per day before, but there are no failures
like that after that went in. There are logs that contain the
"Direct
Hi,
On February 6, 2023 1:51:20 PM PST, Thomas Munro wrote:
>Next up: the new "running" tests, spuriously failing around 8.8% of CI
>builds on FreeBSD. I'll go and ping that thread...
Is that rate unchanged? I thought I fixed the main issue last week?
Greetings,
Andres
--
Sent from my Andro
Andrew Dunstan writes:
> On 2023-02-06 Mo 11:13, Tom Lane wrote:
>> So presumably, changing this test would break it for OpenSSL 0.9.8,
>> which is still nominally supported in those branches. On the other
>> hand, this test isn't run by default, so users would likely never
>> notice anyway.
> P
On Tue, Feb 7, 2023 at 10:57 AM Andres Freund wrote:
> On February 6, 2023 1:51:20 PM PST, Thomas Munro
> wrote:
> >Next up: the new "running" tests, spuriously failing around 8.8% of CI
> >builds on FreeBSD. I'll go and ping that thread...
>
> Is that rate unchanged? I thought I fixed the main
On Tue, Feb 7, 2023 at 11:03 AM Thomas Munro wrote:
> On Tue, Feb 7, 2023 at 10:57 AM Andres Freund wrote:
> > On February 6, 2023 1:51:20 PM PST, Thomas Munro
> > wrote:
> > >Next up: the new "running" tests, spuriously failing around 8.8% of CI
> > >builds on FreeBSD. I'll go and ping that t
Hi,
On 2023-02-07 11:03:18 +1300, Thomas Munro wrote:
> On Tue, Feb 7, 2023 at 10:57 AM Andres Freund wrote:
> > On February 6, 2023 1:51:20 PM PST, Thomas Munro
> > wrote:
> > >Next up: the new "running" tests, spuriously failing around 8.8% of CI
> > >builds on FreeBSD. I'll go and ping that
I notice that Michael's new BF animal gokiburi is failing in
all the pre-v15 branches, though it's fine in v15 and HEAD.
It's evidently dying from ASLR effects because it's trying
to build with EXEC_BACKEND on Linux: there's lots of
2023-02-06 06:07:02.131 GMT [1503972] FATAL: could not reattach
On Mon, Feb 06, 2023 at 06:27:50PM -0500, Tom Lane wrote:
> Is it time to back-patch that commit? The alternative would be
> to run the animal with an ASLR-disabling environment variable.
> On the whole I think testing that f3e78069d works is more
> useful than working around lack of it.
Yes, thi
Hi,
On 2023-02-05 15:30:57 -0800, Andres Freund wrote:
> Hm, I suspect the problem is that we didn't shut down the server due to
> the error, so the log file was changing while cirrus was trying to
> upload.
Pushed a fix for that.
Greetings,
Andres Freund
On 2023-02-06 14:14:22 -0800, Andres Freund wrote:
> On 2023-02-07 11:03:18 +1300, Thomas Munro wrote:
> > What I see is that there were 1254 FreeBSD tasks run in that window, of
> > which 163 failed, and (more interestingly) 111 of those failures succeeded
> > on every other platform. And clickin
Michael Paquier writes:
> On Mon, Feb 06, 2023 at 06:27:50PM -0500, Tom Lane wrote:
>> Is it time to back-patch that commit?
> Yes, this is my intention as of this message from last week, once this
> week's release is tagged:
> https://www.postgresql.org/message-id/y9smhxo51hrxa...@paquier.xyz
D
On 2/6/23 20:20, Andres Freund wrote:
> Hi,
>
> On 2023-02-06 19:51:19 +0100, Tomas Vondra wrote:
>>> No. The only thing the machine is doing is
>>>
>>> while /usr/bin/true; do
>>> make check
>>> done
>>>
>>> I can't reduce the workload further, because the "join" test is in a
>>> separ
On Tue, Feb 7, 2023 at 12:46 PM Tomas Vondra
wrote:
> No, I left the workload as it was for the first lockup, so `make check`
> runs everything as is up until the "join" test suite.
Wait, shouldn't that be join_hash?
On 2/7/23 00:48, Thomas Munro wrote:
> On Tue, Feb 7, 2023 at 12:46 PM Tomas Vondra
> wrote:
>> No, I left the workload as it was for the first lockup, so `make check`
>> runs everything as is up until the "join" test suite.
>
> Wait, shouldn't that be join_hash?
No, because join_hash does not e
On Tue, Feb 7, 2023 at 1:06 PM Tomas Vondra
wrote:
> On 2/7/23 00:48, Thomas Munro wrote:
> > On Tue, Feb 7, 2023 at 12:46 PM Tomas Vondra
> > wrote:
> >> No, I left the workload as it was for the first lockup, so `make check`
> >> runs everything as is up until the "join" test suite.
> >
> > Wai
On Sun, Feb 05, 2023 at 07:40:57PM +0900, Michael Paquier wrote:
> Comments or objections are welcome, of course.
Done this part.
> (FWIW, I'd like to think that there is an argument to normalize the
> A_Const nodes for a portion of the DDL queries, by ignoring their
> values in the query jumblin
Here are my review comments for v29-0001.
==
Commit Message
1.
Discussion:
https://postgr.es/m/CAB-JLwYOYwL=xtyaxkih5ctm_vm8kjkh7aaitckvmch4rzr...@mail.gmail.com
tmp
~
What's that "tmp" doing there? A typo?
==
doc/src/sgml/catalogs.sgml
2.
+
+
+ subminapplydelay int
Hi,
On 2022-12-08 16:36:07 -0800, Andres Freund wrote:
> On 2022-12-08 16:15:11 -0800, Andres Freund wrote:
> > Unfortunately cfbot shows that that doesn't work entirely reliably.
> >
> > The most frequent case is postgres_fdw, which somewhat regularly fails with
> > a
> > regression.diff like th
Dear Hou,
> I think PARALLEL_APPLY_MAIN waits for two kinds of event: 1) wait for new
> message from the queue 2) wait for the partial file state to be set. So, I
> think introducing a new general event for them is better and it is also
> consistent with the WAIT_EVENT_LOGICAL_APPLY_MAIN which is
On Thu, Feb 2, 2023 11:48 AM shveta malik wrote:
>
> On Wed, Feb 1, 2023 at 5:42 PM Melih Mutlu
> wrote:
> >
> > Hi Shveta,
> >
> > shveta malik , 1 Şub 2023 Çar, 15:01 tarihinde
> şunu yazdı:
> >>
> >> On Wed, Feb 1, 2023 at 5:05 PM Melih Mutlu
> wrote:
> >> 2) I found a crash in the previous
Dear Peter,
Thank you for reviewing! PSA new version.
> ==
> Commit Message
>
> 1.
> Discussion:
> https://postgr.es/m/CAB-JLwYOYwL=XTyAXKiH5CtM_Vm8KjKh7aaitCKvmCh4r
> zr...@mail.gmail.com
>
> tmp
>
> ~
>
> What's that "tmp" doing there? A typo?
Removed. It was a typo.
I used `git rebase
In deconstruct_distribute_oj_quals, when we've identified a commutable
left join which provides join clause with flexible semantics, we try to
generate multiple versions of the join clause. Here we have the logic
that puts back any ojrelids that were removed from its min_righthand.
/*
On Mon, Feb 6, 2023 at 3:43 PM houzj.f...@fujitsu.com
wrote:
>
> while reading the code, I noticed that in pa_send_data() we set wait event
> to WAIT_EVENT_LOGICAL_PARALLEL_APPLY_STATE_CHANGE while sending the
> message to the queue. Because this state is used in multiple places, user
> might
> n
Hi,
On 2023-02-06 17:53:00 -0800, Andres Freund wrote:
> WRT the fdw_retry_check: I wonder if we should increase the log level of
> a) pgfdw_inval_callback deciding to disconnect
> b) ReceiveSharedInvalidMessages() deciding to reset
>
> to DEBUG1, at least temporarily?
>
> Alternatively we could a
On Tue, Feb 7, 2023 at 2:04 AM Andres Freund wrote:
>
> On 2023-02-06 12:23:54 +0530, Amit Kapila wrote:
> > On Mon, Feb 6, 2023 at 10:33 AM Andres Freund wrote:
> > > Smart shutdown is practically unusable. I don't think it makes sense to
> > > tie behavior of walsender to it in any way.
> > >
On Tue, Feb 7, 2023 at 6:03 AM Peter Smith wrote:
>
> 5.
> +defGetMinApplyDelay(DefElem *def)
> +{
> + char*input_string;
> + int result;
> + const char *hintmsg;
> +
> + input_string = defGetString(def);
> +
> + /*
> + * Parse given string as parameter which has millisecond unit
> + */
> + if
On Fri, Feb 3, 2023 at 6:58 PM houzj.f...@fujitsu.com
wrote:
>
...
> > Right, I think that case could be addressed by Tom's patch to some extent
> > but
> > I am thinking we should also try to analyze if we can completely avoid the
> > need
> > to remove origins from both processes. One idea cou
1 - 100 of 123 matches
Mail list logo
