ttps://cirrus-ci.com/task/5308087077699584
https://api.cirrus-ci.com/v1/artifact/task/5308087077699584/log/src/test/regress/regression.diffs
Greetings,
Andres Freund
Hi,
On 2021-06-30 05:36:11 +0300, Yura Sokolov wrote:
> Anastasia Lubennikova писал 2021-06-30 00:49:
> > Hi, hackers!
> >
> > Many recently discussed features can make use of an extensible storage
> > manager API. Namely, storage level compression and encryption [1],
> > [2], [3], disk quota fea
Greetings,
Andres Freund
cputube.org/patch_37_3213.log
Greetings,
Andres Freund
patch submitted to the last CF, hasn't gotten any review yet and
misses some platform support, it seems like there's no chance it can make it
into 15?
Greetings,
Andres Freund
: http://cfbot.cputube.org/patch_37_3290.log
My impression is that there's not a lot of enthusiasm for the concept? If
that's true we maybe ought to mark the CF entry as rejected?
Greetings,
Andres Freund
Hi,
On 2022-01-22 22:56:44 +0800, Julien Rouhaud wrote:
> On Sat, Jan 22, 2022 at 05:28:05AM -0800, Kenaniah Cerny wrote:
> > Thank you so much for the backtrace!
> >
> > This latest patch should address by moving the dumpRoleMembership call to
> > before the pointer is closed.
>
> Thanks! The
Hi,
On 2022-01-17 01:05:14 -0800, Jeff Davis wrote:
> Great, I attached a rebased version.
Currently this doesn't apply: http://cfbot.cputube.org/patch_37_3394.log
- Andres
Hi,
On 2022-01-20 14:55:13 +0900, Takashi Menjo wrote:
> Here is patchset v8. It will have "make check-world" and Cirrus to
> pass.
This unfortunately does not apply anymore:
http://cfbot.cputube.org/patch_37_3181.log
Could you rebase?
- Andres
no action on it, I don't see this going into 15. Therefore I'd like to
move it to the next CF?
Greetings,
Andres Freund
; directly checking params)?
This fails on freebsd (so likely a timing issue):
https://cirrus-ci.com/task/4758411492458496?logs=test_world#L2225
Marked as waiting on author.
Greetings,
Andres Freund
On 2022-01-17 15:27:53 +0300, Alexander Pyhalov wrote:
> Alexander Pyhalov писал 2022-01-17 15:26:
> > Updated patch.
>
> Sorry, missed attachment.
Needs another update: http://cfbot.cputube.org/patch_37_3369.log
Marked as waiting on author.
- Andres
gotten so far, it
seems not realistically a fit for 15, but is marked as such.
Think it should be moved to the next CF. Marked as waiting-on-author for now.
Greetings,
Andres Freund
On 2022-01-24 14:44:10 -0500, Robert Haas wrote:
> On Sat, Jan 22, 2022 at 2:20 AM Shruthi Gowda wrote:
> > Agree. In the latest patch, the template0 and postgres OIDs are fixed
> > to unused manually assigned OIDs 4 and 5 respectively. These OIDs are
> > no more listed as unused OIDs.
>
> Thanks
On 2022-02-21 21:04:19 +, Simon Riggs wrote:
> On Mon, 21 Feb 2022 at 16:49, Chapman Flack wrote:
>
> > Shouldn't the comment be "with work_done=false" ?
>
> Good catch, thanks.
>
> I've also added docs to say that "promote_trigger_file" is now
> deprecated. There were no tests for that fun
.com/task/4632127944785920?logs=test_world#L1938
Looks like you're missing an adjustment of postgresql.conf.sample
Marked as waiting-on-author.
Greetings,
Andres Freund
Hi,
On 2022-01-25 15:49:01 +0100, Juan José Santamaría Flecha wrote:
> So, I'm doing that in the attached version, just changing the object name.
Currently fails to apply, please rebase:
http://cfbot.cputube.org/patch_37_3450.log
Marked as waiting-on-author.
- Andres
roken since commit 705e20f8550c0e8e47c0b6b20b5f5ffd6ffd9e33. I
> rebased it.
This fails tests, specifically it seems psql crashes:
https://cirrus-ci.com/task/6592281292570624?logs=cores#L46
Marked as waiting-on-author.
Greetings,
Andres Freund
Hi,
On 2021-10-12 18:04:35 -0400, Greg Stark wrote:
> Here's an updated patch.
Unfortunately it doesn't apply anymore these days:
http://cfbot.cputube.org/patch_37_3358.log
Marked as waiting-on-author.
Greetings,
Andres Freund
Hi,
On 2021-08-19 18:35:27 +1200, David Rowley wrote:
> Anyway, I'll take a few more days to think about it before posting a fix.
The patch in the CF entry doesn't apply:
http://cfbot.cputube.org/patch_37_3234.log
The quoted message was ~6 months ago. I think this CF entry should be marked
as r
ts?
This currently doesn't apply: http://cfbot.cputube.org/patch_37_3533.log
Marked as waiting-on-author for now. Are you aiming this for 15?
Greetings,
Andres Freund
rked as waiting-on-author.
Greetings,
Andres Freund
On 2022-01-26 09:04:15 -0800, Mark Dilger wrote:
> Also, rebased as necessary:
Needs another one: http://cfbot.cputube.org/patch_37_3367.log
Marked as waiting-on-author.
Greetings,
Andres Freund
off
footer on
format aligned
+formfeed off
linestyleascii
null ''
numericlocaleoff
Greetings,
Andres Freund
Marked as waiting on author.
Greetings,
Andres Freund
Hi,
On 2022-02-23 00:51:24 +0100, Tomas Vondra wrote:
> And here's the slightly simplified patch, without the part adding the
> unnecessary GetServerVersion() function.
Doesn't apply anymore: http://cfbot.cputube.org/patch_37_3535.log
Marked as waiting-on-author.
Greetings,
Andres Freund
.cputube.org/patch_37_3454.log
> But can we have some benchmarks showing that this optimization really helps?
As there hasn't been a response to this even in the last CF, I'm going to mark
this entry as returned with feedback (IMO shouldn't even have been moved to
this CF).
Greetings,
Andres Freund
t should be moved to
the next CF?
It currently fails in cfbot, but that's likely just due to Peter's incremental
patch. Perhaps you could make sure the patch still applies and repost?
Greetings,
Andres Freund
Hi,
On 2022-03-09 10:50:45 -0600, Justin Pryzby wrote:
> Rebased over 9e9858389 (Michael may want to look at the tuplestore part?).
Doesn't apply cleanly anymore: http://cfbot.cputube.org/patch_37_2377.log
Marked as waiting-on-author.
Greetings,
Andres Freund
hes marked as
returned with feeback or whatnot.
Either way, currently this patch fails on cfbot due to a new GUC:
https://api.cirrus-ci.com/v1/artifact/task/5134905372835840/log/src/test/recovery/tmp_check/regression.diffs
https://cirrus-ci.com/task/5134905372835840
Greetings,
Andres Freund
his is clearly not 15 material, I've set the target version as 16. But it
might be good to just move the whole entry to the next CF...
Greetings,
Andres Freund
If a patch fails to apply and it looks to be a "real patch" clearly some
action has to be taken by the author, so marking entries as "waiting on
author" is good.
Greetings,
Andres Freund
Hi,
On 2022-02-25 12:15:25 -0500, Tom Lane wrote:
> The attached revision does that, standardizes on pg_fatal() as the
> abbreviation for pg_log_error() + exit(1), and invents detail/hint
> features as per previous discussion.
This unfortunately has had some bitrot:
http://cfbot.cputube.org/patc
Hi,
On 2022-02-24 12:26:08 +0530, Sadhuprasad Patro wrote:
> I have added a dummy test module for table AM and did the document
> change in the latest patch attached...
The test module doesn't build on windows, unfortunately... Looks like you need
to add PGDLLIMPORT to a few variables:
[01:26:18.
Hi,
On 2022-03-21 22:00:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > This unfortunately has had some bitrot:
> > http://cfbot.cputube.org/patch_37_3574.log
>
> Yeah, I know. That patch touches enough places that it's sure to
> break every few days durin
Hi,
Attached is v8. It's just a rebase to resolve conflicts with recent changes.
- Andres
v8-0001-meson-prereq-output-and-depencency-tracking-work.patch.gz
Description: application/patch-gzip
binfm5f_PMrcn.bin
Description: application/patch-gzip
binkuFB75lqSa.bin
Description: application/pa
7;ve also fixed the
> silly mistake highlighted in the postgresql.conf.sample test.
docs fail to build:
https://cirrus-ci.com/task/5556234047717376?logs=docs_build#L349
Greetings,
Andres Freund
g_dumpall starts to be built before that...
Seems we just need to add $(WIN32RES) to pg_dumpall: ?
Greetings,
Andres Freund
[index] = val;
> + else
> + entry->st_progress_param[index] += val;
> +
> + LWLockRelease(ProgressParallelLock);
> +}
I think that's an absolute no-go. Adding locking to progress reporting,
particularly a single central lwlock, is going to *vastly* increase the
overhead incurred by progress reporting.
Greetings,
Andres Freund
Hi,
On 2022-03-22 16:32:24 +0530, Bharath Rupireddy wrote:
> On Tue, Mar 22, 2022 at 12:20 AM Andres Freund wrote:
> > > Something like attached
> > > v6-0001-Deduplicate-checkpoint-restartpoint-complete-mess.patch?
> >
> > Mostly. I don't see a reason for
Hi,
On 2022-03-22 18:09:08 +1300, Thomas Munro wrote:
> On Tue, Mar 22, 2022 at 4:14 PM Andres Freund wrote:
> > The problem looks to be that pg_dumpall doesn't have a dependency on OBJs,
> > which in turn is what contains the dependency on WIN32RES, which in turn
> > c
it because I just skimmed the patch. But I still think it
should contain a comment detailing why accessing catalogs from another
database is safe in this instance, and perhaps a comment or three in places
that could break it (e.g. snapshot computation, horizon stuff).
Greetings,
Andres Freund
the future...
Greetings,
Andres Freund
Hi,
On 2022-03-22 21:57:51 +0530, Bharath Rupireddy wrote:
> On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
> > On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > > +--
> > > +-- pg_get_raw_wal_record()
> >
> > What is raw about the function
Hi,
On 2022-03-22 14:20:55 -0400, Robert Haas wrote:
> On Tue, Mar 22, 2022 at 1:43 PM Andres Freund wrote:
> > When LockAcquireExtended(dontWait=false) acquires a lock where we already
> > hold
> > stronger lock and somebody else is also waiting for that lock, it goes
>
On 2022-03-22 13:15:34 -0500, David Christensen wrote:
> > On Mar 21, 2022, at 7:53 PM, Tom Lane wrote:
> > If we'd done it like this from the beginning, it'd have been
> > great, but retrofitting it now is a lot less appealing.
>
> Yeah, agreed on this. As far as I’m concerned we can reject.
Upd
Hi,
On 2022-03-22 13:47:27 -0400, Andrew Dunstan wrote:
> OK, I have pushed that.
Seems like it might actually be good to test that object access hooks work
well in a parallel worker. How about going the other way and explicitly setting
force_parallel_mode = disabled for parts of the test and to
executor type stuff, seems even more
amenable to being moved to plan time.
Greetings,
Andres Freund
Hi,
On 2022-03-22 18:41:45 -0400, Tom Lane wrote:
> Mark Dilger writes:
> >> On Mar 22, 2022, at 3:20 PM, Andres Freund wrote:
> >> Seems like it might actually be good to test that object access hooks work
> >> well in a parallel worker. How about goin
1] disallow XMAX_COMMITTED + XMAX_LOCK_ONLY
Just skimming this thread quickly, I really have no idea what this is trying
to achieve and the commit message doesn't help either... I didn't read the
referenced thread, but I shouldn't have to, to get a basic idea.
Greetings,
Andres Freund
ROR: syntax error at or near "int"
with this commit.
And the bison warnings I complained about on -committers:
https://www.postgresql.org/message-id/2022033319.so4ajcki7wwaujin%40alap3.anarazel.de
Greetings,
Andres Freund
ur
headers? The members of pg_locale are just pointers and could thus be void *,
and HAVE_UCOL_STRCOLLUTF8 could be computed at configure time or such.
Greetings,
Andres Freund
Hi,
On 2022-03-22 17:20:24 -0700, Andres Freund wrote:
> I was about to propose adding headerscheck / cpluspluscheck to the CI file so
> that cfbot can catch future issues.
The attached patch does so, with ICU disabled to avoid the problems discussed
in the thread. Example run:
https://
ls tests: https://cirrus-ci.com/build/4929662173315072
https://cirrus-ci.com/task/6651773434724352?logs=test_bin#L121
https://cirrus-ci.com/task/6088823481303040?logs=test_world#L2377
Greetings,
Andres Freund
de all of those follow this one-file-per-line style some time ago.
Yea. merge conflicts are considerably rarer that way, and a heck of a lot
easier to deal with when they occur.
Greetings,
Andres Freund
Hi,
On 2022-03-22 23:14:23 -0500, Justin Pryzby wrote:
> On Fri, Mar 18, 2022 at 03:45:03PM -0700, Andres Freund wrote:
> > Pushed 0001, 0002. Only change I made was to add
>
> Thanks - is there any reason not to do the MSVC compiler warnings one, too ?
Purely a lack of roun
Hi,
On 2022-03-23 08:19:38 -0400, Andrew Dunstan wrote:
> On 3/22/22 22:23, Andres Freund wrote:
> > On 2022-03-22 17:20:24 -0700, Andres Freund wrote:
> >> I was about to propose adding headerscheck / cpluspluscheck to the CI file
> >> so
> >> that cf
hould have all files ending with *.log or starting with
regress_log_*.
Greetings,
Andres Freund
us-ci-build/src/backend/executor/execProcnode.c:463
#8 0x562655bf7580 in ExecProcNode
../../../src/include/executor/executor.h:259
#9 0x562655bf7580 in ExecutePlan
/tmp/cirrus-ci-build/src/backend/executor/execMain.c:1633
#10 0x562655bf78b9 in standard_ExecutorR
Hi,
On 2022-03-23 17:27:50 +0900, Kyotaro Horiguchi wrote:
> At Mon, 21 Mar 2022 14:30:17 -0700, Andres Freund wrote
> in
> > > Right now we reset stats for replicas, even if we start from a shutdown
> > > checkpoint. That seems pretty unnecessary with this patch:
>
Hi,
On 2022-03-23 13:54:50 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I tried to run postgres with ubsan to debug something.
>
> For 0001, could we just replace configure's dlopen check with the
> dlsym check? Or are you afraid of reverse-case failures?
Yea, I
Hi,
On 2022-03-23 11:21:37 -0700, Andres Freund wrote:
> On 2022-03-23 13:54:50 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > I tried to run postgres with ubsan to debug something.
> >
> > For 0001, could we just replace configure's dlopen check wi
Hi,
On 2022-03-23 15:58:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we should backpatch both, based on the reasoning in
> > 46ab07ffda9d6c8e63360ded2d4568aa160a7700 ?
>
> Yeah, I suppose. Is anyone going to step up and run a buildfarm
> member w
t;workers);
> + if (ZSTD_isError(ret))
> + {
> + pg_log_error("could not set compression worker count to %d: %s",
> + compress->workers,
> ZSTD_getErrorName(ret));
> + exit(1);
> + }
Will this cause test failures on systems with older zstd?
Greetings,
Andres Freund
Hi,
On 2022-03-23 13:12:34 -0700, Andres Freund wrote:
> I'm planning to enable it on two of mine. Looks like gcc and clang find
> slightly different things, so I was intending to enable it on one of each.
Originally I'd planned to mix them into existing members, but I think i
Hi,
On 2022-03-23 18:31:12 -0400, Robert Haas wrote:
> On Wed, Mar 23, 2022 at 5:14 PM Andres Freund wrote:
> > The most likely source of problem would errors thrown while zstd threads are
> > alive. Should make sure that that can't happen.
> >
> > What is the lif
On 2022-03-23 18:07:01 -0500, Justin Pryzby wrote:
> Did you try this on windows at all ?
Really should get zstd installed in the windows cf environment...
> It's probably no surprise that zstd implements threading differently there.
Worth noting that we have a few of our own threads running on
o make it a GUC. With a bit of care it could be
automatically synced by the existing parallelism infrastructure...
Greetings,
Andres Freund
se
makes them kind of dangerous.
Greetings,
Andres Freund
[1]
https://postgr.es/m/7177d0cd40b82409024e7c495e9d6992.squirrel%40sq.gransy.com
[2] https://www.postgresql.org/message-id/4D0E5A54.3060302%40fuzzy.cz
[3]
https://www.postgresql.org/message-id/9837222c1001240837r5c103519lc6a74c37be5f1831%40mail.gmail.com
Hi,
On 2022-03-23 17:55:16 -0700, Andres Freund wrote:
> Maybe I just don't understand what these reset functions are intended for?
> Their introduction [3] didn't explain much either. To me the behaviour of
> resetting pg_stat_database.stats_reset but nothing else in pg_st
On 2022-03-24 11:54:15 +1300, Thomas Munro wrote:
> Erm, is that really OK? C says "Each enumerated type shall be
> compatible with char, a signed integer type, or an
> unsigned integer type. The choice of type is implementation-defined,
> but shall be capable of representing the values of all the
l_forkexec() around CreateProcess() &&
pgwin32_ReserveSharedMemoryRegion() without, as far as I can see, a single
debug message.
I don't think we can infer too much about the failure rate on windows from the
!windows EXEC_BACKEND rates. The two internal_forkexec() implementations
behaves just too differently.
Greetings,
Andres Freund
nctions. Neither docs nor the thread introducing them
presented that. We don't have SQL level stats
values either.
Greetings,
Andres Freund
f we did rely on
_Generic() we probably could do better, even getting rid of the need
for something like estr_lsn().
Greetings,
Andres Freund
as well. ("There aren't any" is the wrong
> answer.)
+1
Greetings,
Andres Freund
g a conditionally
compiled mode where we track what the longest time between two
CHECK_FOR_INTERRUPTS() calls is (with some extra logic for client
IO).
Obviously the regression tests don't tend to hit the worst cases of
CFR() less code, but even if they did, we currently wouldn't know
ile: No such file
> or directory
It's a change in how LLVM dependencies are declared
internally. Previously the 'native' component was - unintentionally -
transitively included via the 'orcjit' component, but now that's not the
case anymore.
The attached patch should fix
or past versions
of LLVM as well.
Greetings,
Andres Freund
initiate IO into s_b at that
point, rather than fetching it just into the kernel page cache.
Greetings,
Andres Freund
nd one harmless issue (using a pointer to
size_t instead of ExprEvalOp* to represent the 'op' parameter), which
you promptly copied...
If I pushed a slightly cleaned up version of that, it should be fairly
easy to adapt your code to it, I think?
WRT the prototype, I think it may be wo
Hi,
On 2020-12-07 16:32:32 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think it'd be a better to rely on the backend's definition of
> > ExecEvalBoolSubroutine etc. For the functions implementing expression
> > steps I've found that far easier to
ys work.
I don't think it's likely to be a problem, and if it ends up being one,
we can still deduplicate the ops at that point...
Greetings,
Andres Freund
Hi,
On 2020-12-01 12:08:10 -0800, Andres Freund wrote:
> On 2020-12-01 21:04:44 +0100, Fabien COELHO wrote:
> > Andres investigated a few days ago, managed to reproduce the issue locally,
> > and has one line patch. I'm unsure if it should be prevently back-patched,
>
Hi,
On 2020-11-09 20:13:43 -0800, Andres Freund wrote:
> I pushed the change to master. If that doesn't show any problems, I'll
> backpatch in a week or so. Seawasp runs only on master, so it should
> satisfy the buildfarm at least.
It was a bit longer than a week, but I f
n extension written by
> 2ndQuadrant that can double redo performance by doing read-ahead on
> btree pages that will soon be needed.
Thomas has a patch for prefetching during WAL apply. It currently uses
posix_fadvise(), but he took care that it'd be fairly easy to rebase it
onto "real" AIO. Most of the changes necessary are pretty independent of
posix_fadvise vs aio.
Greetings,
Andres Freund
have all the tight coordination of buffer management,
> WAL write ordering, PGXACT and PGPROC, the clog, etc.
I think it'd be a fairly massive increase in complexity. And I don't see
a really large payoff: Once you have real readahead in the WAL there's
really not much synchronous IO left. What am I missing?
Greetings,
Andres Freund
Hi,
On 2020-12-07 19:38:19 -0800, Andres Freund wrote:
> On 2020-12-01 12:08:10 -0800, Andres Freund wrote:
> > On 2020-12-01 21:04:44 +0100, Fabien COELHO wrote:
> > > Andres investigated a few days ago, managed to reproduce the issue
> > > locally,
> > > a
ran numbers at some point, but since then enough has changed
(including many correctness issues fixed) that they don't seem really
relevant anymore. I'll try to include some in the post I'm planning to
do in a few weeks.
Greetings,
Andres Freund
makefile at all?
Somebody taught pg_regress to do so, but only on windows... See
convert_sourcefiles_in().
The other thing that confuses me is why I started getting that error in
*multiple* branches recently, even though I have used the parallel
check-world for ages.
Greetings,
Andres Freund
[1]: make -Otarget -j20 -s check-world && echo success || echo failed
ld suffice.
>
> Hm, that would mean redoing llvm_pg_var_type() often wouldn't it?
> I don't have a very good feeling for how expensive that is, so I'm
> not sure if this seems like a good idea or not.
It should be fairly cheap - it's basically one hashtable lookup.
Greetings,
Andres Freund
On 2020-12-08 22:02:24 -0500, Tom Lane wrote:
> BTW, I observe that with MAXDIM gone from execExpr.h, there are
> no widely-visible uses of MAXDIM except for array.h. I therefore
> suggest that we should pull "#define MAXDIM" out of c.h and put it
> into array.h, as attached. I was slightly surpr
On 2020-11-20 11:23:44 -0500, Robert Haas wrote:
> Andres, do you like the new loop better?
I do!
atter seems better if we can make it work, but the
> former is probably also acceptable. What you've got right now is not.
I mostly wonder which of those two has which implications for how many
FPWs we need to redo. Presumably stalling but not cancelling the current
checkpoint is better?
Greetings,
Andres Freund
*str);
Minor nit: I'd put this into common/string.[ch], besides
pg_clean_ascii(). Probably renaming it to pg_is_ascii().
Greetings,
Andres Freund
o go back to the complexity of having tranches
specify base & stride.
Even more API churn around lwlock initialization isn't desirable :(, but we
could just add a LWLockInitializeIdentified() or such.
Greetings,
Andres Freund
Hi,
On 2020-11-23 19:44:37 -0300, Alvaro Herrera wrote:
> I was contemplating commands/trigger.c this morning (after Heikki split
> copy.c) thinking about the three pieces embedded in there -- one
> catalog/pg_trigger.c, one in executor (execTrigger.c?) and what seems a
> very small piece to remai
read.c and add support for "continuing" partial writes/reads
in one central place?
> I'm drawing a blank on trivial candidate uses for preadv(), without
> infrastructure from later patches.
Can't immediately think of something either.
Greetings,
Andres Freund
a transaction
snapshot set, thus avoiding the error? And that the code normally only
works because GetTransactionSnapshot() will already have been called
somewhere, before EnterParallelMode()?
Greetings,
Andres Freund
Hi,
On 2020-12-20 15:54:31 -0800, Peter Geoghegan wrote:
> On Sun, Dec 20, 2020 at 3:13 PM Andres Freund wrote:
> > Hm. Do I understand correctly that this problem is hit solely because
> > the parallel mode code relies on there already have been a transaction
> > snapshot s
QL level you chose to make
wal_records, wal_fpi bigint. And wal_bytes numeric?
Greetings,
Andres Freund
201 - 300 of 9955 matches
Mail list logo
