On 09.09.22 22:13, Tom Lane wrote:
Peter Eisentraut writes:
I have updated this patch set to rename the _obj() functions to
_object(), and I have dropped the _ptrtype() variants.
I have also split the patch to put the new API and the example uses into
separate patches.
This patch set seems
else if (TailMatches("USING", MatchAny, "ON", MatchAny, "WHEN"))
COMPLETE_WITH("MATCHED", "NOT MATCHED");
else if (TailMatches("USING", MatchAny, "AS", MatchAny, "ON",
MatchAny, "WHEN"))
COMPLETE_WITH("MATCHED", "NOT MATCHED");
else if (TailMatches(
Hi hackers!
Recently I observed very peculiar incident.
=== Incident description ===
ETL database was operating fine for many months, regularly updated etc.
Workload was not changing much, but as far as it was ETL database - most of
queries were different all the time.
On the night of Septembe
On Mon, Sep 12, 2022 at 9:03 AM Bharath Rupireddy
wrote:
>
> Please review the attached v4 patch addressing above review comments.
Oops, there's a compiler warning [1] with the v4 patch, fixed it.
Please review the attached v5 patch.
[1] https://cirrus-ci.com/task/5730076611313664?logs=gcc_warni
Julien Rouhaud writes:
> On Sun, Sep 11, 2022 at 06:22:21PM +, andrey.ara...@nixaid.com wrote:
>> Everyone using containerized postgresql image cannot use /var/lib/postgresql
>> as the mountpoint but has to use /var/lib/postgresql/data instead due to this
>> issue [4] due to [5].
> initdb had
po 12. 9. 2022 v 7:37 odesÃlatel John Naylor
napsal:
> On Thu, Sep 8, 2022 at 12:51 PM Pavel Stehule
> wrote:
> >
> >
> >> Does anyone want to advocate for backpatching these missing ranges to
> >> v12 and up? v12 still has a table in-line so trivial to remedy, but
> >> v13 and up use a script,
On Thu, Sep 8, 2022 at 12:51 PM Pavel Stehule wrote:
>
>
>> Does anyone want to advocate for backpatching these missing ranges to
>> v12 and up? v12 still has a table in-line so trivial to remedy, but
>> v13 and up use a script, so these exceptions would likely have to use
>> hard-coded branches t
On Fri, 9 Sept 2022 at 11:12, Amit Kapila wrote:
>
> On Thu, Sep 8, 2022 at 9:32 AM vignesh C wrote:
> >
> >
> > The attached patch has the changes to handle the same.
> >
>
> Pushed. I am not completely sure whether we want the remaining
> documentation patch in this thread in its current form o
On Sun, Sep 11, 2022 at 06:22:21PM +, andrey.ara...@nixaid.com wrote:
> September 11, 2022 12:18 PM, "Julien Rouhaud" wrote:
>
> > Hi,
> >
> > On Sat, Sep 10, 2022 at 07:14:59PM +, andrey.ara...@nixaid.com wrote:
> >
> >> Have slightly improved the logic so that it does not report an error
On Sun, Sep 11, 2022 at 5:06 PM Aleksander Alekseev
wrote:
>
> Hi John,
>
> Many thanks for the feedback!
>
> > Or put the now-standard 0b in front.
>
> Good idea.
Now that I look at the results, though, it's distracting and not good
for readability. I'm not actually sure we need to do anything h
On Monday, September 12, 2022 1:08 AM Mark Dilger
wrote:
> > > On Sep 10, 2022, at 4:17 PM, Robert Haas wrote:
> >
> >>> I don't understand why we
> >>> used this ALL TABLES IN SCHEMA language.
> >>
> >> The conversation, as I recall, was that "ADD SCHEMA foo" would only mean
> all tables in foo
On Thu, Sep 8, 2022 at 9:13 PM Peter Eisentraut
wrote:
> Attached is the plain-text list of acknowledgments for the PG15 release
> notes, current through REL_15_BETA4. Please check for problems such as
> wrong sorting, duplicate names in different variants, or names in the
> wrong order etc. (No
On Sat, Sep 10, 2022 at 3:35 AM Nathan Bossart wrote:
>
> Well, for wal_keep_size, using bytes makes sense. Given you know how much
> disk space you have, you can set this parameter accordingly to avoid
> retaining too much of it for standby servers. For your proposed parameter,
> it's not so si
On Mon, Sep 12, 2022 at 02:34:48PM +1200, Thomas Munro wrote:
> On Mon, Sep 12, 2022 at 2:27 PM Justin Pryzby wrote:
>> Yeah ... I just realized that I've already forgotten the relevant
>> chronology.
>>
>> The io_concurrency bugfix wasn't included in 15b4, so (if I understood
>> you correctly), t
On Mon, Sep 12, 2022 at 2:27 PM Justin Pryzby wrote:
> On Mon, Sep 12, 2022 at 02:25:48PM +1200, Thomas Munro wrote:
> > On Mon, Sep 12, 2022 at 1:42 PM Justin Pryzby wrote:
> > > But yesterday I started from initdb and restored this cluster from
> > > backup, and
> > > started up sqlsmith, and
On Mon, Sep 12, 2022 at 02:25:48PM +1200, Thomas Munro wrote:
> On Mon, Sep 12, 2022 at 1:42 PM Justin Pryzby wrote:
> > On Mon, Sep 12, 2022 at 10:44:38AM +1200, Thomas Munro wrote:
> > > On Sat, Sep 10, 2022 at 5:44 PM Justin Pryzby
> > > wrote:
> > > > < 2022-09-09 19:37:25.835 CDT telsasoft
On Mon, Sep 12, 2022 at 1:42 PM Justin Pryzby wrote:
> On Mon, Sep 12, 2022 at 10:44:38AM +1200, Thomas Munro wrote:
> > On Sat, Sep 10, 2022 at 5:44 PM Justin Pryzby wrote:
> > > < 2022-09-09 19:37:25.835 CDT telsasoft >ERROR: MultiXactId 133553154
> > > has not been created yet -- apparent wr
On Sun, Sep 11, 2022 at 6:42 PM Justin Pryzby wrote:
> I think you're saying is that this can be explained by the
> io_concurrency bug in recovery_prefetch, if run under 15b3.
>
> But yesterday I started from initdb and restored this cluster from backup, and
> started up sqlsmith, and sent some ki
On Mon, Sep 12, 2022 at 10:44:38AM +1200, Thomas Munro wrote:
> On Sat, Sep 10, 2022 at 5:44 PM Justin Pryzby wrote:
> > < 2022-09-09 19:37:25.835 CDT telsasoft >ERROR: MultiXactId 133553154 has
> > not been created yet -- apparent wraparound
>
> I guess what happened here is that after one of
On Tue, Aug 03, 2021 at 02:19:22PM +1200, Thomas Munro wrote:
> On Tue, Aug 3, 2021 at 9:52 AM Thomas Munro wrote:
> > On Tue, Aug 3, 2021 at 1:17 AM Robert Haas wrote:
> > > That's great. I just realized that this leaves us with identical
> > > RequestCheckpoint() calls in two nearby places. Is
On Mon, Sep 12, 2022 at 09:42:25AM +1200, Thomas Munro wrote:
> When looking the function up it made sense to use the name ending in
> '...A', but when calling directly I think we shouldn't use the A
> suffix, we should let the macros do that for us[1]. (I
> wondered for a moment if that would ev
On Sat, Sep 10, 2022 at 5:44 PM Justin Pryzby wrote:
> < 2022-09-09 19:37:25.835 CDT telsasoft >ERROR: MultiXactId 133553154 has
> not been created yet -- apparent wraparound
I guess what happened here is that after one of your (apparently
several?) OOM crashes, crash recovery didn't run all th
On Sat, Sep 10, 2022 at 5:01 PM Justin Pryzby wrote:
> BTW, after a number of sigabrt's, I started seeing these during
> recovery:
>
> < 2022-09-09 19:44:04.180 CDT >LOG: unexpected pageaddr 1214/AF0FE000 in
> log segment 0001121400B4, offset 1040384
> < 2022-09-09 23:20:50.830 CDT
Here's a v3 that gets rid of guc_hooks.c in favor of moving the
hook functions to related modules (though some did end up in
variables.c for lack of a better idea). I also pushed all the
hook function declarations to guc_hooks.h. Unsurprisingly,
removal of guc.h #includes from header files led to
On Sun, Sep 11, 2022 at 12:29 PM Michael Paquier wrote:
> On Fri, Sep 09, 2022 at 08:11:09PM +0900, Michael Paquier wrote:
> > Based on what I can see, the Windows animals seem to have digested
> > 47bd0b3 (cygwin, MinGW and MSVC), so I think that we are good.
Great, that's a lot of nice cleanup.
On Wed, Sep 7, 2022 at 8:05 AM Simon Riggs wrote:
>
> On Tue, 6 Sept 2022 at 21:33, Justin Pryzby wrote:
> >
> > On Tue, Sep 06, 2022 at 04:16:02PM +0100, Simon Riggs wrote:
> > > New chapter on transaction management, plus a few related changes.
> > >
> > > Markup and links are not polished yet,
I wrote:
> Michael Paquier writes:
>> One part that I have found a bit strange lately about guc.c is that we
>> have mix the core machinery with the SQL-callable parts. What do you
>> think about the addition of a gucfuncs.c in src/backend/utils/adt/ to
>> split things a bit more?
> I might be w
> On Sep 10, 2022, at 4:17 PM, Robert Haas wrote:
>
>>> I don't understand why we
>>> used this ALL TABLES IN SCHEMA language.
>>
>> The conversation, as I recall, was that "ADD SCHEMA foo" would only mean all
>> tables in foo, until publication of other object types became supported, at
>>
Julien Rouhaud writes:
> On Sat, Sep 10, 2022 at 07:14:59PM +, andrey.ara...@nixaid.com wrote:
>> Have slightly improved the logic so that it does not report an error
>> "directory \"%s\" exists but is not empty"
>> when it is only supposed to warn the user about the mountpoint, without
>> exi
Hi hackers,
While wandering around the codes of reducing outer joins, I noticed that
when determining which base rels/Vars are forced nonnullable by given
clause, we don't take SubPlan into consideration. Does anyone happen to
know what is the concern behind that?
IMO, for SubPlans of type ALL/AN
Hi,
On Sat, Sep 10, 2022 at 07:14:59PM +, andrey.ara...@nixaid.com wrote:
>
> Have slightly improved the logic so that it does not report an error
> "directory \"%s\" exists but is not empty"
> when it is only supposed to warn the user about the mountpoint, without
> exiting.
>
> To me, my pat
Hi John,
Many thanks for the feedback!
> Or put the now-standard 0b in front.
Good idea.
> I think the problem is ambiguity about what a "toast pointer" is. This
> comment:
>
> * struct varatt_external is a traditional "TOAST pointer", that is, the
Right. The comment for varatt_external says
Hi Tom,
I've updated the patch by adding the explanation behind and more comments.
(please see the attachment)
Have slightly improved the logic so that it does not report an error
"directory \"%s\" exists but is not empty"
when it is only supposed to warn the user about the mountpoint, without e
33 matches
Mail list logo
