ird but not
> much weirder than what we have now)? I don't know if that solves the
> problem you're trying to solve, but it seems lower-risk.
That seems to not really get us very far. It's hard to use for users, and hard
to make secure for the hosted PG providers.
Greetings,
Andres Freund
. Think of e.g. a pg_hba.conf line of "local all user
peer" (quite reasonable config) or "host all all 127.0.0.1/32 trust" (less so).
Hence the hack with dblink_security_check().
I think there might be a discussion somewhere about adding an option to force
libpq to not use certain auth methods, e.g. plaintext password/md5. It's
possible this could be integrated.
Greetings,
Andres Freund
ant to access the variable alrady.
Do others dislike this as well?
I assume we'd again have to dive into pg_bsd_indent's code to fix it :(
And even if we were to figure out how, would it be worth the
reindent-all-branches pain? I'd say yes, but...
Greetings,
Andres Freund
quot; isn't released. To the point that
it's very annoying in other contexts, because it doesn't deal well with
conditional lock acquisition/releases.
Greetings,
Andres Freund
Hi,
On 2023-01-19 15:10:38 -0800, Peter Geoghegan wrote:
> On Thu, Jan 19, 2023 at 2:54 PM Andres Freund wrote:
> > Yea. Hence my musing about potentially addressing this by choosing to visit
> > additional blocks during the heap scan using vacuum's block sampling logic.
prefetched and which should not. Big OS readahead affects index scan
> > performance.
I don't disagree fundamentally. But that doesn't make this patch a useful
starting point.
Greetings,
Andres Freund
Hi,
On 2023-01-19 13:22:28 -0800, Peter Geoghegan wrote:
> On Thu, Jan 19, 2023 at 12:56 PM Andres Freund wrote:
> > But in contrast to dead_tuples, where I think we can just stop analyze from
> > updating it unless we crashed recently, I do think we need to update
> > re
Hi,
On 2023-01-19 13:36:41 -0800, Peter Geoghegan wrote:
> On Thu, Jan 19, 2023 at 12:58 PM Andres Freund wrote:
> > There's absolutely no guarantee that autoanalyze is triggered
> > there. Particularly with repeated vacuums triggered due to an relfrozenxid
> > age
Hi
On 2023-01-18 19:26:22 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 7:04 PM Andres Freund wrote:
> > > You seem to be saying that it's a problem if we don't update reltuples
> > > -- an estimate -- when less than 2% of the table is scanned by VACU
om sample -- which seems to me to be an
> > approach that just doesn't have any sound theoretical basis.
>
> In other words, ANALYZE sometimes (but not always) produces wrong answers.
For dead tuples, but not live tuples.
> On Wed, Jan 18, 2023 at 4:08 PM Andres Freund wrote
windows, but it's not really relative either. It's a "drive local"
path. I.e. relative to the current drive (c:/), but not the subdirectory
therein.
Greetings,
Andres Freund
Hi,
On 2023-01-18 18:21:33 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 5:49 PM Andres Freund wrote:
> > On 2023-01-18 15:28:19 -0800, Peter Geoghegan wrote:
> > > Perhaps we should make vac_estimate_reltuples focus on the pages that
> > > VACUUM newly set
Hi,
On 2023-01-18 11:24:19 +0100, Drouvot, Bertrand wrote:
> On 1/6/23 4:40 AM, Andres Freund wrote:
> > Hm, that's quite expensive. Perhaps worth adding a C helper that can do that
> > for us instead? This will likely also be needed in real applications after
> > all
Hi,
On 2023-01-18 17:00:48 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 4:37 PM Andres Freund wrote:
> > I can, it should be just about trivial code-wise. A bit queasy about trying
> > to
> > forsee the potential consequences.
>
> That's always go
Hi,
On 2023-01-18 16:19:02 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 4:02 PM Andres Freund wrote:
> > vacuum-no reltuples/n_live_tupn_dead_tup
> > 1 476 500
> > 2 2500077
Hi,
On 2023-01-18 13:45:19 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 1:08 PM Andres Freund wrote:
> > I suggested nearby to only have ANALYZE dead_tuples it if there's been no
> > [auto]vacuum since the stats entry was created. That allows recovering from
>
Hi,
On 2023-01-18 14:37:20 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 2:22 PM Andres Freund wrote:
> > The problem with the change is here:
> >
> > /*
> > * Okay, we've covered the corner cases. The normal calculation is
>
Hi,
On 2023-01-18 13:42:40 -0800, Andres Freund wrote:
> The real point of change appears to be 10->11.
>
> There's a relevant looking difference in the vac_estimate_reltuples call:
> 10:
> /* now we can compute the new value for pg_class.reltuples */
> v
Hi,
On 2023-01-18 13:08:44 -0800, Andres Freund wrote:
> One complicating factor is that VACUUM sometimes computes an incrementally
> more bogus n_live_tup when it skips pages due to the VM, whereas ANALYZE
> computes something sane. I unintentionally encountered one when I was trying
&g
d it out, and it does *not* reproduce in 11, but does in
12. Haven't dug into what the cause is, but we probably use the wrong
denominator somewhere...
Greetings,
Andres Freund
vactest.sql
Description: application/sql
t; > of reportMemoryError, and then we could add LOCK_ACQUIRE_INTENT_DROP &
> > LOCK_ACQUIRE_INTENT_TRUNCATE or such. Then the same for
> > RangeVarGetRelidExtended(). It already "customizes" how to lock based on
> > RVR*
> > flags.
>
> It would be tricky, but still relatively straightforward compared to
> other things. It is often a TRUNCATE or a DROP TABLE, and we have
> nothing to lose and everything to gain by changing the rules for
> those.
Probably should also change the rules for VACUUM and VACUUM FULL / CLUSTER, if
we do it. Manual VACUUM will often be faster due to the cost limits, and
VACUUM FULL can be *considerably* faster than VACUUM once you hit bad bloat.
Greetings,
Andres Freund
Hi,
On 2023-01-18 10:22:14 -0800, Andres Freund wrote:
> On 2023-01-12 08:34:25 +0100, Peter Eisentraut wrote:
> > On 07.01.23 08:21, Peter Eisentraut wrote:
> > > This patch version looks correct to me. It is almost the same as the
> > > one that Andres had posted
the same as the
> > one that Andres had posted in his thread, except that yours also
> > modifies slist_delete() and dlist_member_check(). Both of these changes
> > also look correct to me.
>
> committed
Unfortunately this causes a build failure with ILIST_DEBUG
enabled. dlist_member_check() uses dlist_foreach(), which isn't set up to work
with const :(. I'll push a quick workaround.
Greetings,
Andres Freund
', 1)
> -have_optimized_crc = true
> +if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd
> without -march=armv8-a+crc',
> +args: test_c_args)
Seems like it'd be easier to read if you don't re-indent this, but just have
the cc.get_id() == 'msvc' part of this if/else-if.
Greetings,
Andres Freund
vacuum run? We don't know. Do we need the XID horizon to advance
> first, and if so, how far? We don't know. Do we need auto-cancellation
> to be disabled? We don't know. That's where we get into a lot of
> trouble here.
Agreed. I think the metrics I proposed would help some, by at least providing
sensible upper boundaries (for work) and minimal requirements (horizon during
last vacuum).
Greetings,
Andres Freund
ly built sourcetree. No need to build other
binaries when you just want to test psql, or more extremely, pg_test_timing.
> I propose to put something like this into "SanityCheck".
Perhaps we instead could add it as a separate "meson-only" test? Then it'd
fail on developer's machines, instead of later in CI. We could pass the test
information from the 'tests' array, or it could look at the metadata in
meson-info/intro-tests.json
Greetings,
Andres Freund
machine, but now we have
allow_in_place_tablespaces.
> > SELECT pg_relation_size('test_io_local') /
> > current_setting('block_size')::int8 > 100;
> >
> > Better toast compression or such could easily make test_io_local smaller
> > than
> > it's today. Seeing that it's too small would make it easier to understand
> > the
> > failure.
>
> Good idea. So, I used pg_table_size() because it seems like
> pg_relation_size() does not include the toast relations. However, I'm
> not sure this is a good idea, because pg_table_size() includes FSM and
> visibility map. Should I write a query to get the toast relation name
> and add pg_relation_size() of that relation and the main relation?
I think it's the right thing to just include the relation size. Your queries
IIRC won't use the toast table or other forks. So I'd leave it at just
pg_relation_size().
Greetings,
Andres Freund
Hi,
On 2023-01-17 12:26:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Here's an updated version of the move to representing instr_time as
> > nanoseconds. It's now split into a few patches:
>
> I took a quick look through this.
Thanks!
> > 0001)
Hi,
On 2023-01-17 19:00:02 +0100, Tomas Vondra wrote:
> On 1/17/23 18:02, Andres Freund wrote:
> > On 2023-01-17 15:52:07 +0100, Tomas Vondra wrote:
> >> That also does not have issues with timestamp "rounding" - considering
> >> e.g. sample rate 1000Hz, that&
onsider XID age as a
> second reason for not auto-cancelling. You would want to force the
> behavior anyway when you hit emergency mode, because that should force
> all the mitigations we have, but I don't know that you need to do
> anything before that.
Hm, without further restrictions, that has me worried. It's not crazy to have
a LOCK TABLE on a small-ish table be part of your workload - I've certainly
seen it plenty of times. Suddenly blocking on that for a few minutes, just
because a bit of bloat has collected, seems likely to cause havoc.
Greetings,
Andres Freund
Hi,
On 2023-01-16 13:58:21 -0800, Peter Geoghegan wrote:
> On Fri, Jan 13, 2023 at 9:55 PM Andres Freund wrote:
> When I express skepticism of very high autovacuum_freeze_max_age
> settings, it's mostly just that I don't think that age(relfrozenxid)
> is at all infor
es, but that's just a small bit of additional summin-up to be done during
> > EXPLAIN.
> >
>
> That's certainly one way to implement that. I wonder if we could make
> that work without the global pointer, but I can't think of any.
I don't see a realistic way at least. We could pass down an
"InstrumentationContext" through everything that needs to do IO and WAL. But
that seems infeasible at this point.
Greetings,
Andres Freund
Hi,
On 2023-01-17 08:46:12 -0500, Robert Haas wrote:
> On Fri, Jan 13, 2023 at 2:56 PM Andres Freund wrote:
> > Does anybody see a reason to not move forward with this aspect? We do a fair
> > amount of INSTR_TIME_ACCUM_DIFF() etc, and that gets a good bit cheaper by
> > j
TIMING OFF ANALYZE, and a further 45%
from TIMING ON. The per-row overhead, compared between TIMING ON/OFF:
((6.187ms - 3.423 ms) * 100)/(10 * 2) = 13.82ns
which is within the run-to-run variance of the pg_test_timing result.
Greetings,
Andres Freund
[1] https://postgr.es/m/202301160236
t where necessary at the call
> site?
I think those should be a separate discussion / patch.
Greetings,
Andres Freund
Hi,
On 2023-01-13 11:55:47 -0800, Andres Freund wrote:
> Does anybody see a reason to not move forward with this aspect? We do a fair
> amount of INSTR_TIME_ACCUM_DIFF() etc, and that gets a good bit cheaper by
> just using nanoseconds. We'd also save memory in BufferUsage
Hi,
On 2023-01-15 15:53:09 -0500, Tom Lane wrote:
> Andres Freund writes:
> > For the purpose here a limit of MaxTupleAttributeNumber or such instead of
> > FUNC_MAX_ARGS would do the trick, I think?
>
> As long as we have to change the code, we might as well remove the
&g
Hi,
On 2023-01-15 15:17:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-01-15 14:39:41 -0500, Tom Lane wrote:
> >> But I suppose we are stuck with that, seeing that this datatype choice
> >> is effectively part of the logrep protocol now. I think the on
to be done during
EXPLAIN.
Separately, I think we should consider re-ordering Instrumentation so that
bufusage_start, walusage_start are after the much more commonly used
elements. We're forcing ntuples, nloops, .. onto separate cachelines, even
though they're accounted for unconditionally.
Greetings,
Andres Freund
ucing another, or just "rely" on too long arrays to
trigger errors when forming tuples?
I guess we'll have to process the input twice? Pre-allocating an int2vector
for 100 elements is one thing, for 1600 another.
Greetings,
Andres Freund
when we
afterwards have to re-read it from disk to replicate, it's less clearly a win.
Greetings,
Andres Freund
Hi,
On 2023-01-13 19:39:41 -0800, Peter Geoghegan wrote:
> On Fri, Jan 13, 2023 at 6:09 PM Andres Freund wrote:
> > I don't think the split is right. There's too much in 0001 - it's basically
> > introducing the terminology of 0002 already. Could you make it
nd that connections would need to
"warm up" to have good plans. But it'd handle restarts nicely.
Greetings,
Andres Freund
Hi,
On 2023-01-13 16:13:45 -0800, Peter Geoghegan wrote:
> On Fri, Jan 13, 2023 at 2:00 PM Andres Freund wrote:
> > I think it'd be a good idea to split off the part of the patch that
> > introduces
> > AutoVacType / adds logging for what triggered. That's i
security definer function blindly, is an administrative
> failure, not a security hole.
The point of the security definer section is to explain how to safely write
security definer functions that you grant to less privileged users. It's not
about whether it's safe to call a security invoker / definer function -
indeed, if you don't trust the function author / owner, it's never safe to
call the function.
Greetings,
Andres Freund
ted at "0".
The reason for using FIRST is to be able to define the loop variable as the
enum type, without assigning numeric values to an enum var. I prefer it
slightly.
> From f8c9077631169a778c893fd16b7a973ad5725f2a Mon Sep 17 00:00:00 2001
> From: Andres Freund
> Date: Fri,
s
initial loops over all tables. But seems completely wrong for the later calls
via table_recheck_autovac() -> recheck_relation_needs_vacanalyze() ->
relation_needs_vacanalyze()?
These variables really shouldn't be globals. It makes sense to cache them
locally in do_autovacuum(), but reusing them
recheck_relation_needs_vacanalyze() and sharing it between launcher and worker
is bad.
Greetings,
Andres Freund
Hi,
On 2023-01-13 15:25:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Does anybody see a reason to not move forward with this aspect? We do a fair
> > amount of INSTR_TIME_ACCUM_DIFF() etc, and that gets a good bit cheaper by
> > just using nanoseconds.
>
>
ed -c1 -P5 -T15 -f <(echo "EXPLAIN (ANALYZE, BUFFERS) SELECT
generate_series(1, 1000) OFFSET 1000;")
the best result is:
timespec: 1073.431
nanosec: 957.532
a ~10% difference
Greetings,
Andres Freund
with a version returning a fully "reconciled"
> PgStat_StatTabEntry
> 2) remove prefixes
> 3) Introduce the new macros
> I'll first look at 1).
Makes sense.
> And it looks to me that removing PgStat_BackendFunctionEntry can be done
> independently
It's imo the function version of 1), just a bit simpler to implement due to
the much simpler reconciliation. It could be done together with it, or
separately.
Greetings,
Andres Freund
nt user has the rights to do that).
An alternative to b would be a version SET ROLE that can't be undone. But I
think we'd just miss all the other things that are prevented by
SECURITY_RESTRICTED_OPERATION.
Greetings,
Andres Freund
Hi,
On 2023-01-13 09:15:10 -0500, Reid Thompson wrote:
> On Mon, 2023-01-09 at 18:31 -0800, Andres Freund wrote:
> > > Dynamic shared memory allocations are included only in the value displayed
> > > for the backend that created them, they are not included in the value for
&g
ss transaction, otherwise we'd be in
trouble. Some resets are part of that. If the error actually corrupted local
state badly enough to break the transaction machinery, we'd need to PANIC out.
Greetings,
Andres Freund
Hi,
On 2023-01-12 23:38:50 -0800, Jeff Davis wrote:
> On Thu, 2023-01-12 at 19:29 -0800, Andres Freund wrote:
> > superuser:
> > # CREATE FUNCTION exec_su(p_sql text) RETURNS text LANGUAGE plpgsql
> > SECURITY DEFINER AS $$BEGIN RAISE NOTICE 'executing %', p_sql;
Hi,
On 2023-01-12 21:49:00 -0800, Andres Freund wrote:
> Clearly this would need a bunch more work, but it seems promising? I think
> there'd be other uses than this.
>
> I briefly tried to use it for spinlocks. Mostly works and detects things like
> returning with a spinlo
Hi,
On 2023-01-12 22:17:55 -0600, Justin Pryzby wrote:
> On Thu, Jan 12, 2023 at 06:43:54PM -0800, Andres Freund wrote:
> > Are you actually proposing that we don't PANIC after an fsync for the
> > category
> > of files that you list here, even with data_sync_re
problem is
in. E.g. above the first warning points to PG_TRY, the second to
PG_CATCH. It'd work to just put it into PG_TRY and PG_END_TRY.
Clearly this would need a bunch more work, but it seems promising? I think
there'd be other uses than this.
I briefly tried to use it
Hi,
On 2023-01-12 19:21:00 -0800, Will Mortensen wrote:
> FWIW re: deadlocks in general, I probably didn't highlight it well in my
> original email, but the existing solution for this use case (as Marco
> described in his blog post) is to actually lock the table momentarily.
> Marco's blog post us
On 2023-01-12 19:29:43 -0800, Andres Freund wrote:
> Hi,
>
> On 2023-01-12 18:40:30 -0800, Jeff Davis wrote:
> > On Wed, 2023-01-11 at 19:33 -0800, Andres Freund wrote:
> >
> > > and the
> > > privilege check will be done with the rights of the admi
Hi,
On 2023-01-12 18:40:30 -0800, Jeff Davis wrote:
> On Wed, 2023-01-11 at 19:33 -0800, Andres Freund wrote:
>
> > and the
> > privilege check will be done with the rights of the admin in many of
> > these
> > contexts.
>
> Can you explain?
If the less-privi
und
fsync_fname_ext(). Both end up in pg_fsync().
Are you actually proposing that we don't PANIC after an fsync for the category
of files that you list here, even with data_sync_retry set?
Greetings,
Andres Freund
On 2023-01-12 12:28:39 -0800, Christophe Pettus wrote:
> What's the distinction between errdetail and errdetail_log in the ereport
> interface?
Only goes to the server log, not to the client.
Hi,
On 2023-01-11 23:03:30 -0800, Will Mortensen wrote:
> On Wed, Jan 11, 2023 at 12:33 PM Andres Freund wrote:
> > I think such a function would still have to integrate enough with the lock
> > manager infrastructure to participate in the deadlock detector. Otherwise I
> >
so
> consider this to be a pre-existing bug worth fixing.
> As reported by skink, valgrind and Tom Lane.
>
> Discussion: https://postgr.es/m/901504.1673504836%40sss.pgh.pa.us
Makes sense. We should backpatch this, I think?
Greetings,
Andres Freund
Hi,
On 2023-01-12 08:38:57 +0100, Drouvot, Bertrand wrote:
> On 1/11/23 11:59 PM, Andres Freund wrote:
> > > Now that this patch renames some fields
> >
> > I don't mind renaming the fields - the prefixes really don't provide
> > anything
> > use
ep wants to be able to concurrently perform
ongoing replication, and synchronize tables added to the replication set. The
pg_16399_sync_16392_7187728548042694423 slot should vanish after the initial
synchronization.
Greetings,
Andres Freund
try. Whereas PgStat_FunctionCounts and PgStat_StatFuncEntry
both use it. Right now there's no way to remember where to add the t_ prefix,
and where not.
Imo the reason to rename here isn't to abolish prefixes, it's to be halfway
consistent within closeby code. And the code overwhelmingly doesn't use the
prefixes.
Greetings,
Andres Freund
ng) this GUC
> to be true, such as in a subscription apply worker.
>
> This proposal may offer a path to allowing non-superusers to create
> event triggers.
That'd allow a less-privileged user to completely hobble the admin by erroring
out on all actions.
Greetings,
Andres Freund
n the use case, a transaction callback.
It's really hard to know what precisely to suggest, without knowing a good bit
more about the intended usecase.
Greetings,
Andres Freund
sing "git diff --color-moved=dimmed-zebra
> --color-moved-ws=ignore-all-space" with this, per your recent tip,
> which did help.)
It's a really useful feature. I configured git to always use
--color-moved=dimmed-zebra, but haven't quite dared to enable
--color-moved-ws=ignore-all-space by default.
Greetings,
Andres Freund
Hi,
On 2023-01-11 15:26:45 -0800, Nathan Bossart wrote:
> On Wed, Jan 11, 2023 at 12:48:36PM -0800, Andres Freund wrote:
> > Given that we check for interrupts in other parts of recovery with
> > HandleStartupProcInterrupt(), which doesn't interact with latches, isn'
mpact shared_buffers, regardless of how that
> non-impact manifests).
VACUUM can end up dirtying all of shared buffers, even with the ring buffer in
use...
Greetings,
Andres Freund
37: WARNING: Additional Perl modules are
> required to run TAP tests.
>
> That could be caused by a transient failure combined with bad error
> handling - if there's an error while building the image, it shouldn't be
> uploaded.
Yea, there's a problem where packer on windows doesn't seem to abort after a
powershell script error out. The reason isn't yet quiete clear. I think Bilal
is working on a workaround.
Greetings,
Andres Freund
can run the tests and copy the required changes from
> src/test/regress/output/interval.out to
> src/test/regress/expected/interval.out
Wonder if we should have a bit of content about that in
doc/src/sgml/regress.sgml?
Greetings,
Andres Freund
Hi,
On 2023-01-11 14:29:25 -0800, Peter Geoghegan wrote:
> On Sat, Jan 7, 2023 at 7:25 PM Andres Freund wrote:
> > Probably a good idea, although it doesn't neatly fit right now.
>
> I'll leave it for now.
>
> Attached is v2, which changes things based on you
ion with its own dependencies. Perhaps you can hack it into one
of the contrib/ modules?
Greetings,
Andres Freund
Hi,
On 2023-01-11 14:53:54 -0800, Peter Geoghegan wrote:
> On Tue, Jan 10, 2023 at 11:35 AM Andres Freund wrote:
> > Nontrivial, I'm afraid. We don't pass any relevant parameters to rm_desc:
> > void(*rm_desc) (StringInfo buf, XLogReaderState
>
with a version
returning a fully "reconciled" PgStat_StatTabEntry? It feels quite wrong to
have that intimitate knowledge of the subtransaction stuff in pgstatfuncs.c
and about how the different counts get combined.
I think that'd allow us to move the definition of PgStat_TableStatus to
PgStat_TableXactStatus, PgStat_TableCounts to pgstat_internal.h. Which feels a
heck of a lot cleaner.
Greetings,
Andres Freund
Hi,
On 2023-01-11 22:30:42 +0100, Tomas Vondra wrote:
> On 1/11/23 21:58, Andres Freund wrote:
> > If you're thinking of decoding changes in parallel (rather than streaming
> > out
> > large changes before commit when possible), you'd only be able to do that in
>
Hi,
On 2023-01-11 16:18:34 -0500, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Wed, Jan 11, 2023 at 11:18 AM Andres Freund wrote:
> >> I don't like that - it's also quite useful to disable use of ringbuffers
> >> when
> >> you actually need
Hi,
On 2023-01-11 14:38:34 -0600, Justin Pryzby wrote:
> On Wed, Jan 11, 2023 at 10:58:54AM -0800, Andres Freund wrote:
> > Some ideas:
> >
> > USE_RING_BUFFERS on|off
> > REUSE_BUFFERS on|off
>
> +1 for either of these.
Then I'd go for REUSE
you'd only be able to do that in
cases when transaction haven't performed catalog changes, I think. In which
case there'd also be no issue wrt transactional sequence changes.
Greetings,
Andres Freund
h.c, checkpointer.c via
CheckpointWriteDelay() seem borked.
Greetings,
Andres Freund
ething else
>
> Definitely +1 on adding a function/syntax to wait for lockers without
> actually taking a lock.
I think such a function would still have to integrate enough with the lock
manager infrastructure to participate in the deadlock detector. Otherwise I
think you'd trivially end up with loads of deadlocks.
Greetings,
Andres Freund
x27;d have been able to see the
catalog modifications made by the committing transaction.
Greetings,
Andres Freund
Hi,
On 2023-01-06 10:52:06 +0100, Drouvot, Bertrand wrote:
> On 1/6/23 4:40 AM, Andres Freund wrote:
> > ISTM that the ordering of patches isn't quite right later on. ISTM that it
> > doesn't make sense to introduce working logic decoding without first fixing
> >
Decoding needs access to syscaches et al., which in turn use
> + * heavyweight locks and such. Thus we need to have enough
> state around to
> + * keep track of those. The easiest way is to simply use a
> transaction
> + * internally. That also allows us to easily enforce that
> nothing writes
> + * to the database by checking for xid assignments.
> + *
> + * When we're called via the SQL SRF there's already a
> transaction
> + * started, so start an explicit subtransaction there.
> + */
> + using_subtxn = IsTransactionOrTransactionBlock();
This duplicates a lot of the code from ReorderBufferProcessTXN(). But only
does so partially. It's hard to tell whether some of the differences are
intentional. Could we de-duplicate that code with ReorderBufferProcessTXN()?
Maybe something like
void
ReorderBufferSetupXactEnv(ReorderBufferXactEnv *, bool process_invals);
void
ReorderBufferTeardownXactEnv(ReorderBufferXactEnv *, bool is_error);
Greetings,
Andres Freund
Hi,
On 2023-01-11 11:06:26 -0800, Peter Geoghegan wrote:
> On Wed, Jan 11, 2023 at 10:58 AM Andres Freund wrote:
> > Any idea about the name? The obvious thing is to reference ring buffers in
> > the
> > option name, but that's more of an implementation detail...
>
Hi,
On 2023-01-11 10:35:19 -0800, Peter Geoghegan wrote:
> On Wed, Jan 11, 2023 at 10:27 AM Andres Freund wrote:
> > Therefore I'd like to add an option to the VACUUM command to use to disable
> > the use of the ringbuffer. Not sure about the name yet.
>
> Sounds l
Hi,
On 2023-01-11 10:27:20 -0800, Andres Freund wrote:
> On cloud hardware with higher fsync latency I've seen > 15x time differences
> between using the ringbuffers and avoiding them by using pg_prewarm.
A slightly edited version of what I've in the past to defeat th
tting disabled
(c.f. lazy_check_wraparound_failsafe()). If things are bad enough that we're
soon going to shut down, we want to be aggressive.
Greetings,
Andres Freund
[1] according to pg_test_fsync:
fdatasync 769.189 ops/sec1300 usecs/op
[2]
For the s_b
atus and take necessary actions?
Invalidated slots are not a new concept introduced in this patchset, so I'd
say we can introduce such a field separately.
Greetings,
Andres Freund
kpointerMain(void)
> /* Report pending statistics to the cumulative stats system */
> pgstat_report_checkpointer();
> pgstat_report_wal(true);
> + pgstat_report_slru(true);
Why do we need a force parameter if all callers use it?
Greetings,
Andres Freund
Hi,
On 2023-01-09 19:59:42 -0800, Peter Geoghegan wrote:
> On Mon, Jan 9, 2023 at 1:58 PM Andres Freund wrote:
> > A couple times when investigating data corruption issues, the last time just
> > yesterday in [1], I needed to see the offsets affected by PRUNE and VACUUM
> &g
dn't, on average, schedule more jobs than we currently
do. Although peak "job throughput" would be higher.
Thomas?
Greetings,
Andres Freund
Hi,
On 2023-01-10 15:03:42 +0100, Matthias van de Meent wrote:
> On Mon, 9 Jan 2023 at 20:34, Andres Freund wrote:
> > On 2023-01-09 17:50:10 +0100, Matthias van de Meent wrote:
> > > Wouldn't it be enough to only fix the constructions in
> > > FullXidRelativeT
toast table? I suspect doing so for
non-catalog tables as well would trigger test changes. Running a buildfarm
animal with that would at least make issues like this much easier to discover.
Greetings,
Andres Freund
Hi,
On 2023-01-10 13:11:35 -0500, Robert Haas wrote:
> On Tue, Jan 10, 2023 at 12:40 PM Andres Freund wrote:
> > > I think. `expected = originalVictim + 1;` line should be in while loop
> > > (before acquiring spin lock) so that, even in the case above, expected
> > &g
Hi,
On 2023-01-11 01:25:06 +0900, 斯波隼斗 wrote:
> This question is about ClockSweepTick function and the code is below.
> https://github.com/postgres/postgres/blob/24d2b2680a8d0e01b30ce8a41c4eb3b47aca5031/src/backend/storage/buffer/freelist.c#L146-L165
>
> The value of expected, NBuffers, wrapped
OOM being a result of this
> configuration
> + * parameter vs a system failure to allocate OOM.
> + */
> + ereport(WARNING,
> + errmsg("allocation would exceed
> max_total_memory limit (%llu > %llu)",
> +(unsigned long long)
> pgstat_get_all_backend_memory_allocated() +
> +allocation_request, (unsigned long
> long) max_total_bkend_mem * 1024 * 1024));
> +
> + result = true;
> + }
I think it's completely unfeasible to execute something as expensive as
pgstat_get_all_backend_memory_allocated() on every allocation. Like,
seriously, no.
And we absolutely definitely shouldn't just add CHECK_FOR_INTERRUPT() calls
into the middle of allocator code.
Greetings,
Andres Freund
1901 - 2000 of 6557 matches
Mail list logo
