On Tue, Apr 23, 2024 at 11:42:41AM +0700, Andrei Lepikhov wrote:
> On 23/4/2024 11:16, Imseih (AWS), Sami wrote:
>> + pgstat_report_query_id(linitial_node(Query,
>> psrc->query_list)->queryId, true);
>> set_ps_display("BIND");
>> @@ -2146,6 +2147,7 @@ exec_execute_message(const
On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> On 22/04/2024 10:19, Michael Paquier wrote:
>> As a whole, I can get behind a unique GUC that forces the use of
>> direct. Or, we could extend the existing "ssl" GUC with a new
>> "direct" value to accept only direct
Hi,
I'm proposing a patch that making COPY format extendable:
https://www.postgresql.org/message-id/20231204.153548.2126325458835528809.kou%40clear-code.com
https://commitfest.postgresql.org/48/4681/
It's based on the discussion at:
On Mon, Apr 22, 2024 at 09:25:15AM -0400, Robert Haas wrote:
> That's long been my feeling about this. So, if we revert this for now,
> what we ought to do is put it back right ASAP after feature freeze and
> then clean all that up.
In the 85 backtraces I can find in the tests, we have a mixed
Hi,
On Mon, Apr 22, 2024 at 03:00:00PM +0300, Alexander Lakhin wrote:
> 22.04.2024 13:52, Bertrand Drouvot wrote:
> >
> > That's weird, I just launched it several times with the patch applied and
> > I'm not
> > able to see the seg fault (while I can see it constently failing on the
> > master
Hi all,
While analyzing the use of internal error codes in the code base, I've
some problems, and that's a mixed bag of:
- Incorrect uses, for errors that can be triggered by users with
vallid cases.
- Expected error cases, wanted by the tests like corruption cases or
just to keep some code
On 23/4/2024 11:16, Imseih (AWS), Sami wrote:
FWIW, I'd like to think that we could improve the situation, requiring
a mix of calling pgstat_report_query_id() while feeding on some query
IDs retrieved from CachedPlanSource->query_list. I have not in
details looked at how much could be achieved,
> FWIW, I'd like to think that we could improve the situation, requiring
> a mix of calling pgstat_report_query_id() while feeding on some query
> IDs retrieved from CachedPlanSource->query_list. I have not in
> details looked at how much could be achieved, TBH.
I was dealing with this today and
jian he writes:
> if (nrows > MAXIMUM_ROWCOUNT || isnan(nrows))
> nrows = MAXIMUM_ROWCOUNT;
> else if (nrows <= 1.0)
> nrows = 1.0;
> else
> nrows = rint(nrows);
> The comments say `Avoid infinite and NaN`
> but actually we only avoid NaN.
Really? The IEEE float arithmetic standard
Jeff Davis writes:
> On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
>> Loading data without stats, and hoping
>> that auto-analyze will catch up sooner not later, is exactly the
>> current behavior that we're doing all this work to get out of.
> That's the disconnect, I think. For me, the
On Mon, Apr 22, 2024 at 7:04 PM Masahiko Sawada wrote:
>
> On Mon, Apr 22, 2024 at 9:02 PM shveta malik wrote:
> >
> > Thanks for the patch, the changes look good Amit. Please find the merged
> > patch.
> >
>
> I've reviewed the patch and have some comments:
>
> ---
> /*
> -* Early
hi.
/*
* clamp_row_est
* Force a row-count estimate to a sane value.
*/
double
clamp_row_est(double nrows)
{
/*
* Avoid infinite and NaN row estimates. Costs derived from such values
* are going to be useless. Also force the estimate to be at least one
* row, to make explain output look
On Sun, Mar 31, 2024 at 8:12 PM Andrey M. Borodin wrote:
>
>
>
> > On 15 Aug 2023, at 07:38, Peter Smith wrote:
> >
> > A rebase was needed due to a recent push [1].
> >
> > PSA v3.
>
>
> > On 14 Jan 2024, at 10:43, vignesh C wrote:
> >
> > I have changed the status of the patch to "Waiting on
On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
> Loading data without stats, and hoping
> that auto-analyze will catch up sooner not later, is exactly the
> current behavior that we're doing all this work to get out of.
That's the disconnect, I think. For me, the main reason I'm excited
about
Hi,
On 2024-04-22 18:10:17 -0400, Robert Haas wrote:
> cfbot is giving me a bunch of green check marks, so I plan to commit
> this version, barring objections.
Makes sense.
> I shall leave redesign of the symlink mess as a matter for others to
> ponder; I'm not in love with what we have, but I
On Mon, Apr 22, 2024 at 06:46:27PM +0200, Matthias van de Meent wrote:
> On Mon, 22 Apr 2024 at 17:41, Tom Lane wrote:
>> Matthias van de Meent writes:
>>> 0002/0004 remove fields in ExecRowMark which were added for FDWs to
>>> use, but there are no FDWs which use this: I could only find two
On Tue, May 24, 2016 at 03:01:13PM -0400, Tom Lane wrote:
> Also, I notice another problem in vac_truncate_clog() now that I'm looking
> at it: it's expecting that the pg_database datfrozenxid and datminmxid
> values will hold still while it's looking at them. Since
> vac_update_datfrozenxid
On Mon, Apr 22, 2024 at 03:40:01PM +0200, Majid Garoosi wrote:
> Any news, comments, etc. about this thread?
FWIW, I'd still be in favor of doing a GUC-ification of this part, but
at this stage I'd need more time to do a proper study of a case where
this shows benefits to prove your point, or
On 22/04/2024 10:47, Heikki Linnakangas wrote:
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we
Hi!
On Thu, Apr 18, 2024 at 1:57 PM Alexander Korotkov wrote:
> Thank you for the fixes you've proposed. I didn't look much into
> details yet, but I think the main concern Tom expressed in [1] is
> whether the feature is reasonable at all. I think at this stage the
> most important thing is
On Mon, Apr 22, 2024 at 5:16 PM Thomas Munro wrote:
> On Tue, Apr 23, 2024 at 8:05 AM Robert Haas wrote:
> > I reworked the test cases so that they don't (I think) rely on
> > symlinks working as they do on normal platforms.
>
> Cool.
cfbot is giving me a bunch of green check marks, so I plan
Any thoughts?
On Thu, Jan 25, 2024 at 1:59 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Hey,
>
> In a nearby user complaint email [1] some missing information regarding
> ownership reassignment came to light. I took that and went a bit further
> to add what I felt was further
Hi,
On 2024-04-23 09:15:27 +1200, Thomas Munro wrote:
> I find myself wondering if symlinks should go on the list of "things
> we pretended Windows had out of convenience, that turned out to be
> more inconvenient than we expected, and we'd do better to tackle
> head-on with a more portable
Thoughts anyone?
On Thu, Feb 1, 2024 at 3:47 PM David G. Johnston
wrote:
> Motivated by a recent complaint [1] I found the hostssl related material
> in our docs quite verbose and even repetitive. Some of that is normal
> since we have both an overview/walk-through section as well as a
On Mon, 22 Apr 2024 at 16:26, Robert Haas wrote:
> That's a fair point, but I'm still not seeing much practical
> advantage. It's unlikely that a client is going to set a random bit in
> a format parameter for no reason.
I think you're missing an important point of mine here. The client
wouldn't
On Tue, Apr 23, 2024 at 8:05 AM Robert Haas wrote:
> I reworked the test cases so that they don't (I think) rely on
> symlinks working as they do on normal platforms.
Cool.
(It will remain a mystery for now why perl readlink() can't read the
junction points that PostgreSQL creates (IIUC), but
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
> ... were you going to look at it? I can take a whack if it's too far down
> your priority list.
Yeah, I’m working on a patchset right now.
./daniel
Nathan Bossart writes:
> On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
>> I think the actual plan now is that we'll sync the in-tree copy
>> with the buildfarm's results (and then do a tree-wide pgindent)
>> every so often, probably shortly before beta every year.
> Okay. Is this
On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
> I think the actual plan now is that we'll sync the in-tree copy
> with the buildfarm's results (and then do a tree-wide pgindent)
> every so often, probably shortly before beta every year.
Okay. Is this just to resolve the delta between
Jeff Davis writes:
> Would it make sense to have a new SECTION_STATS?
Perhaps, but the implications for pg_dump's API would be nontrivial,
eg would we break any applications that know about the current
options for --section. And you still have to face up to the question
"does --data-only
Nathan Bossart writes:
> I used to do this step when I first started hacking on Postgres because
> that's what it says to do, but I've only ever used the in-tree one for many
> years now, and I'm not aware of any scenario where I might need to download
> a new version from the buildfarm. I see
I reworked the test cases so that they don't (I think) rely on
symlinks working as they do on normal platforms.
Here's a patch. I'll go create a CommitFest entry for this thread so
that cfbot will look at it.
...Robert
v1-0001-Try-again-to-add-test-coverage-for-pg_combineback.patch
I used to do this step when I first started hacking on Postgres because
that's what it says to do, but I've only ever used the in-tree one for many
years now, and I'm not aware of any scenario where I might need to download
a new version from the buildfarm. I see that the in-tree copy wasn't
Hey,
The attached patch addresses four somewhat related aspects of the create
table reference page that bother me.
This got started with Bug# 15954 [1] (unlogged on a partitioned table
doesn't make sense) and I've added a paragraph under "unlogged" to address
it.
While doing that, it seemed
On Tue, Apr 16, 2024 at 7:20 PM Jeff Davis wrote:
> We maintain the invariant:
>
>XLogCtl->logFlushResult <= XLogCtl->logWriteResult
>
> and the non-shared version:
>
>LogwrtResult.Flush <= LogwrtResult.Write
>
> and that the requests don't fall behind the results:
I had missed the fact
I noticed that there are some existing examples of this sort of thing in
pg_dump (e.g., commit d5e8930), so I adjusted the patch to match the
surrounding style a bit better.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 80dd3233730422298ffe3b4523a7c58d7e9b55b9 Mon Sep 17
On Thu, Apr 18, 2024 at 3:25 PM Daniel Gustafsson wrote:
> > On 18 Apr 2024, at 20:11, Robert Haas wrote:
> > 2. As (1), but make check_control_files() emit a warning message when
> > the problem case is detected.
>
> Being in the post-freeze part of the cycle, this seems like the best option.
On Mon, Apr 22, 2024 at 11:13 AM Peter Geoghegan wrote:
> I'm pretty sure that I could fix this by simply removing the
> assertion. But I need to think about it a bit more before I push a
> fix.
>
> The test case you've provided proves that _bt_preprocess_keys's
> new no-op path isn't just used
On Wed, 2024-04-17 at 11:50 -0500, Nathan Bossart wrote:
> It looks like the problem is that the ACLs are getting dumped in the
> data
> section when we are also dumping stats. I'm able to get the tests to
> pass
> by moving the call to dumpRelationStats() that's in dumpTableSchema()
> to
>
Hi,
On 2024-04-19 13:57:41 -0400, Robert Haas wrote:
> Have others seen this? Is there something we can/should do about it?
Yes, I've also seen this - but never quite reproducible enough to properly
tackle it.
The first thing I'd like to do is to make the wait_for_catchup routine
regularly log
On Thu, Apr 18, 2024 at 5:39 AM Tomas Vondra
wrote:
>
> On 4/18/24 09:10, Michael Paquier wrote:
> > On Sun, Apr 07, 2024 at 10:54:56AM -0400, Melanie Plageman wrote:
> >> I've added an open item [1], because what's one open item when you can
> >> have two? (me)
> >
> > And this is still an open
On Mon, 22 Apr 2024 at 17:41, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > 0002/0004 remove fields in ExecRowMark which were added for FDWs to
> > use, but there are no FDWs which use this: I could only find two FDWs
> > who implement RefetchForeignRow, one being BlackHoleFDW, and the
On Mon, Apr 15, 2024 at 11:17:54AM +0530, Amit Kapila wrote:
> On Thu, Apr 11, 2024 at 6:58 PM Kirill Reshke wrote:
> >
> > While working on [0] i have noticed this comment in
> > TerminateOtherDBBackends function:
> >
> > /*
> > * Check whether we have the necessary rights to terminate other
> >
jian he writes:
> set work_mem to '1kB';
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> .. 2147483647)
> should it be
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> kB .. 2147483647 kB)
> ?
> since the units for work_mem are { "B", "kB", "MB",
Matthias van de Meent writes:
> 0001 removes two old fields that are not in use anywhere anymore, but
> at some point these were used.
+1. They're not being initialized, so they're useless and confusing.
> 0002/0004 remove fields in ExecRowMark which were added for FDWs to
> use, but there are
Hi,
While working on the 'reduce nodeToString output' patch, I noticed
that my IDE marked one field in the TidScanState node as 'unused'.
After checking this seemed to be accurate, and I found a few more such
fields in Node structs.
PFA some patches that clean this up: 0001 is plain removal of
On Mon, Apr 22, 2024 at 4:00 AM Alexander Lakhin wrote:
> Please look at another case, where a similar Assert (but this time in
> _bt_preprocess_keys()) is triggered:
> CREATE TABLE t (a text, b text);
> INSERT INTO t (a, b) SELECT 'a', repeat('b', 100) FROM generate_series(1,
> 500) g;
> CREATE
On Sat Apr 20, 2024 at 10:42 AM CDT, Peter Eisentraut wrote:
3. We leave it out of PG17 and consider a new AIX port for PG18 on its
own merits.
Note that such a "new" port would probably require quite a bit of
development and research work, to clean up all the cruft that had
accumulated
On Thu, Apr 18, 2024 at 5:36 PM Jelte Fennema-Nio wrote:
> To clarify: My proposed approach is to use a protocol extension
> parameter for to enable the new messages that the server can send
> (like Peter is doing now). And **in addition to that** gate the new
> Bind format type behind a feature
Dear Hayato,
On Monday, April 22, 2024 15:54 MSK, "Hayato Kuroda (Fujitsu)"
wrote:
> Dear Vitaly,
>
> > I looked at the patch and realized that I can't try it easily in the near
> > future
> > because the solution I'm working on is based on PG16 or earlier. This patch
> > is
> > not easily
On Fri, Apr 19, 2024 at 4:29 PM Nathan Bossart wrote:
> I certainly don't want to hold up $SUBJECT for a larger rewrite of
> autovacuum scheduling, but I also don't want to shy away from a larger
> rewrite if it's an idea whose time has come. I'm looking forward to
> hearing your ideas in your
Hi,
On Mon, 22 Apr 2024 at 11:44, jian he wrote:
>
> hi.
> minor issue in guc.c.
>
> set work_mem to '1kB';
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> .. 2147483647)
> should it be
> ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
> kB ..
On Sun, Apr 21, 2024 at 8:47 PM David Steele wrote:
> > I figured that wouldn't be particularly meaningful, and
> > that's pretty much the only kind of validation that's even
> > theoretically possible without a bunch of extra overhead, since we
> > compute checksums on entire files rather than,
Hi,
On Thu, Apr 4, 2024 at 9:23 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 4, 2024 at 4:35 PM Amit Kapila wrote:
> >
> > > Thanks for the changes. v34-0001 LGTM.
> >
> > I was doing a final review before pushing 0001 and found that
> > 'inactive_since' could be set twice during startup after
Hey folks,
Any news, comments, etc. about this thread?
Best regards
Majid Garoosi
On Mon, 12 Feb 2024 at 01:10, Michael Paquier wrote:
> On Sun, Feb 11, 2024 at 04:32:20PM +0330, Majid Garoosi wrote:
> > On Fri, 9 Feb 2024 at 22:33, Andres Freund wrote:
> >> The way we read the WAL data is
On Mon, Apr 22, 2024 at 9:02 PM shveta malik wrote:
>
> On Mon, Apr 22, 2024 at 5:10 PM Amit Kapila wrote:
> >
> > On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
> > >
> > > Please find v9 with the above comments addressed.
> > >
> >
> > I have made minor modifications in the comments and
On Mon, Apr 22, 2024 at 2:36 AM Michael Paquier wrote:
> I'd like to think about this stuff in a different way: this is useful
> if enabled by default because it can also help in finding out error
> paths that should not use the internal errcode. Normally, there
> should be zero backtraces
On Sat, 20 Apr 2024 at 01:36, Tom Lane wrote:
> Japin Li writes:
>> I see [1] has already implemented on login event trigger, why not implement
>> the logoff event trigger?
>
> What happens if the session crashes, or otherwise fails unexpectedly?
>
I am currently unsure how to handle such
> Dear Vitaly,
>
> > I looked at the patch and realized that I can't try it easily in the near
> > future
> > because the solution I'm working on is based on PG16 or earlier. This patch
> > is
> > not easily applicable to the older releases. I have to port my solution to
> > the
> > master,
On Mon, Apr 22, 2024 at 5:10 PM Amit Kapila wrote:
>
> On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
> >
> > Please find v9 with the above comments addressed.
> >
>
> I have made minor modifications in the comments and a function name.
> Please see the attached top-up patch. Apart from
22.04.2024 13:52, Bertrand Drouvot wrote:
That's weird, I just launched it several times with the patch applied and I'm
not
able to see the seg fault (while I can see it constently failing on the master
branch).
Are you 100% sure you tested it against a binary with the patch applied?
Yes,
On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
>
> Please find v9 with the above comments addressed.
>
I have made minor modifications in the comments and a function name.
Please see the attached top-up patch. Apart from this, the patch looks
good to me.
--
With Regards,
Amit Kapila.
diff
Hi,
On Mon, Apr 22, 2024 at 01:00:00PM +0300, Alexander Lakhin wrote:
> Hi Bertrand,
>
> 22.04.2024 11:45, Bertrand Drouvot wrote:
> > Hi,
> >
> > This new thread is a follow-up of [1] and [2].
> >
> > Problem description:
> >
> > We have occasionally observed objects having an orphaned
Hi Alexander,
On 2024-Apr-18, Alexander Lakhin wrote:
> 18.04.2024 16:39, Alvaro Herrera wrote:
> > I have pushed a fix which should hopefully fix this problem
> > (d9f686a72e). Please give this a look. Thanks for reporting the issue.
>
> Please look at an assertion failure, introduced with
Hi Team,
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still using that" is timely and fair.
We
Hi Bertrand,
22.04.2024 11:45, Bertrand Drouvot wrote:
Hi,
This new thread is a follow-up of [1] and [2].
Problem description:
We have occasionally observed objects having an orphaned dependency, the
most common case we have seen is functions not linked to any namespaces.
...
Looking
Hi,
On Mon, Apr 22, 2024 at 11:32:14AM +0530, shveta malik wrote:
> On Mon, Apr 22, 2024 at 5:57 AM Zhijie Hou (Fujitsu)
> wrote:
> > Attach the V3 patch which also addressed Shveta[1] and Bertrand[2]'s
> > comments.
Thanks!
> Tested the patch, works well.
Same here.
Regards,
--
Bertrand
Dear hackers,
> Looking at this a bit more, maybe rolling back all prepared transactions on
> the
> subscriber when toggling two_phase from true to false might not be desirable
> for the customer. Maybe we should have an option for customers to control
> whether transactions should be rolled
On Fri, Apr 19, 2024 at 6:44 PM jian he wrote:
>
> On Thu, Apr 18, 2024 at 6:58 PM Alexander Korotkov
> wrote:
> >
> > Thank you for the fixes you've proposed. I didn't look much into
> > details yet, but I think the main concern Tom expressed in [1] is
> > whether the feature is reasonable at
Dear Vitaly,
> I looked at the patch and realized that I can't try it easily in the near
> future
> because the solution I'm working on is based on PG16 or earlier. This patch is
> not easily applicable to the older releases. I have to port my solution to the
> master, which is not done yet.
We
Hi,
On Wed, Mar 23, 2022 at 12:49:06PM -0400, Tom Lane wrote:
> Realistically, if we want to prevent this type of problem, then all
> creation DDL will have to take a lock on each referenced object that'd
> conflict with a lock taken by DROP. This might not be out of reach:
> I think we do
Hi,
This new thread is a follow-up of [1] and [2].
Problem description:
We have occasionally observed objects having an orphaned dependency, the
most common case we have seen is functions not linked to any namespaces.
Examples to produce such orphaned dependencies:
Scenario 1:
session 1:
hi.
minor issue in guc.c.
set work_mem to '1kB';
ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
.. 2147483647)
should it be
ERROR: 1 kB is outside the valid range for parameter "work_mem" (64
kB .. 2147483647 kB)
?
since the units for work_mem are { "B", "kB", "MB", "GB",
On Sat, Apr 20, 2024 at 2:00 PM Alena Rybakina
wrote:
> Hi, thank you for your work with this subject.
>
> While I was reviewing your code, I noticed that your patch conflicts with
> another patch [0] that been committed.
>
> [0]
>
Hello Peter,
07.04.2024 20:18, Peter Geoghegan wrote:
On Sun, Apr 7, 2024 at 1:00 PM Alexander Lakhin wrote:
SELECT * FROM t WHERE a < ANY (ARRAY[1]) AND b < ANY (ARRAY[1]);
TRAP: failed Assert("so->numArrayKeys"), File: "nbtutils.c", Line: 560, PID:
3251267
I immediately see what's up
On Mon, 22 Apr 2024 at 06:04, Michael Paquier wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I
Thanks all!
On Fri, 19 Apr 2024 at 13:59, Daniel Gustafsson wrote:
> > On 19 Apr 2024, at 13:49, Daniel Gustafsson wrote:
> >> On 19 Apr 2024, at 12:31, Aleksander Alekseev
> wrote:
>
> >> Here is the patch.
> >
> > Nice catch, and thanks for the patch. I'll apply it with a backpatch to
>
On Thu, Apr 18, 2024 at 4:26 PM Ajin Cherian wrote:
>
> Attaching the patch for your review and comments. Big thanks to Kuroda-san
> for also working on the patch.
>
>
Looking at this a bit more, maybe rolling back all prepared transactions on
the subscriber when toggling two_phase from true to
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
> On 19/04/2024 19:48, Jacob Champion wrote:
>> On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
>>> With direct SSL negotiation, we always require ALPN.
>>
>> (As an aside: I haven't gotten to test the version of the
On Sun, Apr 21, 2024 at 09:26:38AM +0200, Peter Eisentraut wrote:
> Note that a standard test run produces a number of internal errors. I
> haven't checked how likely these are in production, but one might want to
> consider that before starting to dump backtraces in routine situations.
>
> For
On Mon, Apr 22, 2024 at 10:52 AM Peter Geoghegan wrote:
> On Sun, Apr 21, 2024 at 10:36 PM Richard Guo
> wrote:
> > I didn't spend much time digging into it, but I wonder if this Assert is
> > sensible. I noticed that before commit 5bf748b86b, the two datatypes
> > were not equal to each other
On Sat, Apr 20, 2024 at 11:55:46AM +0900, Michael Paquier wrote:
> FYI, as this is an open item, I am planning to wrap that at the
> beginning of next week after a second lookup. If there are any
> comments, feel free.
This one is now fixed with f46bee346c3b, and the open item is marked
as
On Mon, Apr 22, 2024 at 5:57 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, April 19, 2024 10:54 AM Kuroda, Hayato/黒田 隼人
> wrote:
> > In your patch, the pg_dump.c was updated. IIUC the main reason was that
> > pg_restore executes some queries as single transactions so that ALTER
> > SUBSCRIPTION
22.04.2024 00:49, Thomas Munro wrote:
On Mon, Apr 22, 2024 at 12:00 AM Alexander Lakhin wrote:
From what I can see, the following condition (namely, -l):
if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
{
push @tsoids,
85 matches
Mail list logo
