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
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,
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 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
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
> 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
>>
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 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,
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.
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 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
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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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
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,
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
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
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
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(
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
33 matches
Mail list logo
