On Tue, 12 Mar 2024, 23:45 Anthonin Bonnefoy, <
anthonin.bonne...@datadoghq.com> wrote:
>
> > - I don't think it's a good idea to do memory allocations in the middle
> of a
> > PG_CATCH. If the error was due to out-of-memory, you'll throw another
> error.
> Good point. I was wondering what were
Hi all
Just saw this thread.
I cooked up a PoC distributed tracing support in Pg years ago as part of
the 2ndQuadrant BDR project.
I used GUCs to set the `opentelemtery_trace_id` and
`opentelemetry_span_id`. These can be sent as protocol-level messages by
the client driver if the client driver
On Tue, 23 Feb 2021 at 08:09, Peter Geoghegan wrote:
> On Tue, Dec 8, 2020 at 2:42 AM Alexander Korotkov
> wrote:
> > Thank you for your feedback!
>
> It would be nice to use this patch to test things that are important
> but untested inside vacuumlazy.c, such as the rare
>
On Sat, 2 Oct 2021 at 01:24, Jaime Casanova
wrote:
> On Tue, Jun 29, 2021 at 01:32:26PM +0800, Craig Ringer wrote:
> > On Sat, 20 Mar 2021 at 03:46, Tom Lane wrote:
> >
> > > Robert Haas writes:
> > > > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote:
>
On Wed, 6 Oct 2021, 03:30 Andres Freund, wrote:
> Hi,
>
>
> My first attempt was to try to use the existing crashdump stuff in
> pgwin32_install_crashdump_handler(). That's not really quite what I want,
> because it only handles postmaster rather than any binary, but I thought
> it'd
> be a good
On Tue, 29 Jun 2021 at 13:30, Craig Ringer
wrote:
> Laurenz,
>
> Thanks for your comments. Sorry it's taken me so long to get back to you.
> Commenting inline below on anything I think needs comment; other proposed
> changes look good.
>
I'm not going to get back to
On Fri, 27 Aug 2021 at 08:59, Julien Rouhaud wrote:
> On Fri, Aug 27, 2021 at 3:42 AM Magnus Hagander
> wrote:
> >
> > Yeah, but that does move the problem to the other side doesn't it? So
> > if you (as a pure test of course) were to remove the variable
> > completely from the included header
On Thu, 26 Aug 2021 at 01:51, Alvaro Herrera
wrote:
> On 2021-Aug-25, Magnus Hagander wrote:
>
> > The thing we need the PGDLLIMPORT definition for is to *import* them
> > on the other end?
>
> Oh ... so modules that are willing to cheat can include their own
> declarations of the variables they
On Wed, 25 Aug 2021 at 22:36, Magnus Hagander wrote:
> On Wed, Aug 25, 2021 at 4:06 PM Robert Haas wrote:
> >
> > On Tue, Aug 24, 2021 at 5:06 PM Chapman Flack
> wrote:
> > > The thing is, I think I have somewhere a list of all the threads on
> this
> > > topic that I've read through since the
On Wed, 25 Aug 2021 at 03:13, Robert Haas wrote:
> On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack
> wrote:
> > I don't think that's true of the second proposal in [0]. I don't foresee
> > a noticeable runtime cost unless there is a plausible workload that
> > involves very frequent updates to
On Mon, 23 Aug 2021 at 22:45, Julien Rouhaud wrote:
> On Mon, Aug 23, 2021 at 10:22 PM Tom Lane wrote:
> >
> > Bruce Momjian writes:
> > > On Mon, Aug 23, 2021 at 10:15:04AM -0400, Tom Lane wrote:
> > >> By that argument, *every* globally-visible variable should be marked
> > >> PGDLLIMPORT.
On Tue, 24 Aug 2021 at 05:08, Chapman Flack wrote:
> On 08/23/21 14:30, Robert Haas wrote:
> > it seems likely that this proposed
> > API would have the exact same problem, because it would let people do
> > exactly the same thing. And, going through this proposed API would
> > still be
On Tue, 24 Aug 2021 at 13:21, Craig Ringer
wrote:
>
> There is not even the thinnest pretense of Pg having a dedicated extension
> API or any sort of internal vs public API separation.
>
Oh, and if we do want such a separation, we'll need to introduce a MUCH
lower-pain-and-overhea
On Tue, 24 Aug 2021 at 02:31, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 11:40 AM Alvaro Herrera
> wrote:
> > In that case, why not improve the API with functions that return the
> > values in some native datatype? For scalars with native C types (int,
> > floats, Boolean etc) this is easy
On Mon, 23 Aug 2021 at 22:15, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sun, Aug 22, 2021 at 09:29:01PM +0800, Julien Rouhaud wrote:
> >> Then shouldn't we try to prevent direct access on all platforms rather
> than
> >> only one?
>
> > Agreed. If Julian says 99% of the non-export
On Sun, 22 Aug 2021 at 21:29, Julien Rouhaud wrote:
> On Sun, Aug 22, 2021 at 09:19:42AM -0400, Tom Lane wrote:
> >
> > Uh, no, it's exactly *not* clear. There are a lot of GUCs that are only
> > of interest to particular subsystems. I do not see why being a GUC makes
> > something
n_bison.exe if they're found, and to accept full paths
for these tools in buildenv.pl).
From ad9625026bcb7768c636fdf3a37a3403db195ae2 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Tue, 13 Jul 2021 14:18:44 +1000
Subject: [PATCH v1 1/2] Teach pgflex.pl and pgbision.pl to read buildenv.pl
for too
On Fri, 2 Jul 2021 at 00:19, Simon Riggs
wrote:
> > So yeah. I think it'd be better to log the info you want at start-of-txn
> unless there's a compelling reason not so, and I don't see one yet.
>
> AFAIK, XLOG_XACT_ASSIGNMENT does not occur for normal top-level
> transactions, only for
On Thu, 6 May 2021 at 19:40, Amit Kapila wrote:
> On Thu, May 6, 2021 at 9:54 AM Craig Ringer wrote:
> >
> At the least it'd be helpful to have pg_stat_replication (or a new
> related auxiliary view like pg_stat_logical_decoding) show
> >
> > - walsender to
On Mon, 1 Feb 2021 at 18:42, Craig Ringer
wrote:
> On Sun, 24 Jan 2021 at 09:12, Andres Freund wrote:
>
>> Hi,
>>
>> On 2021-01-19 14:16:07 +0800, Craig Ringer wrote:
>> > AFAICS it'd be necessary to expand PROCLOG to expose this in shmem.
>> > Proba
On Sat, 20 Mar 2021 at 03:46, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote:
> >> I'm not very comfortable about the idea of having the postmaster set
> >> child processes' latches ... that doesn't sound terribly safe from the
> >> standpoint of not
Laurenz,
Thanks for your comments. Sorry it's taken me so long to get back to you.
Commenting inline below on anything I think needs comment; other proposed
changes look good.
On Sun, 30 May 2021 at 19:20, Laurenz Albe wrote:
> + always use
. That patch will
replace patch 4 above, but not patches 1-3.
I'd love to see these PGDLLIMPORTs backported to pg13.
From f4c1abfbfc33ad95b5c216f1fcf132938c6377bc Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Thu, 17 Jun 2021 11:46:17 +0800
Subject: [PATCH v1 1/5] Make xlog.c vars PGDLLIMPORT
On Tue, 22 Jun 2021 at 00:24, Simon Riggs
wrote:
> On Thu, Mar 18, 2021 at 6:20 AM Craig Ringer
> wrote:
> >
> > On Mon, 15 Mar 2021 at 21:01, David Steele wrote:
> >>
> >> On 11/18/20 5:23 AM, Simon Riggs wrote:
> >> > On Wed,
On Thu, 6 May 2021 at 02:28, Andres Freund wrote:
> Hi,
>
> On 2021-05-05 18:33:27 +0800, Craig Ringer wrote:
> > I'm thinking of piggy-backing on the approach used in the "Get memory
> > contexts of an arbitrary backend process" patch in order to provide
> acc
On Wed, 5 May 2021 at 23:15, Craig Ringer wrote:
> Which was fine as far as it went, but I failed to account for the xid
> assignment not necessarily being durable when the client calls
> txid_status().
Ahem, I meant "when the client calls txid_current()"
and double
round-trip costs. The main point of txid_status() was to avoid the cost of
that double-flush.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
, I missed this mail initially. I'll look into it shortly.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
k.
Anyone drastically opposed to the idea?
(I know I have to finish up with the LWLock tracepoint patchset first, this
is a RFC at this stage).
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
patch commit message (attached) and in the
src/test/valgrind_wrapper script it adds. If you're wondering why the
valgrind options --trace-children=yes --trace-children-skip=pattern
--trace-children-skip-by-arg=pattern don't solve this problem, read the
script's comments.
--
Craig Ringer
On Wed, 5 May 2021 at 09:15, Craig Ringer wrote:
>> warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
>> 1322 |TRACE_POSTGRESQL_LWLOCK_WAIT_START(T_NAME(lock), mode);
>> | ^
>
&g
On Wed, 5 May 2021, 06:15 Andres Freund, wrote:
> Hi,
>
> warning: suggest braces around empty body in an ‘if’ statement
> [-Wempty-body]
> 1322 |TRACE_POSTGRESQL_LWLOCK_WAIT_START(T_NAME(lock), mode);
> | ^
>
Odd that I
On Wed, 14 Apr 2021, 22:29 Robert Haas, wrote:
> On Tue, Apr 13, 2021 at 10:42 PM Craig Ringer
> wrote:
> > I'd really love it if a committer could add an explanatory comment or
> > two in the area though. I'm happy to draft a comment patch if anyone
> > agrees m
On Thu, 29 Apr 2021 at 15:31, Peter Eisentraut
wrote:
> > So if you could produce a separate patch that adds the
> > _ENABLED guards targeting PG14 (and PG13), that would be helpful.
>
> Here is a proposed patch for this.
LGTM.
Applies and builds fine on master and (with default fuzz) on
On Wed, 14 Apr 2021 at 10:41, Craig Ringer
wrote:
> On Wed, 14 Apr 2021 at 02:25, Robert Haas wrote:
> > You could try to identify locks by pointer addresses, but that's got
> > security hazards and the addreses aren't portable across all the
> > backends involved in the p
On Wed, 14 Apr 2021 at 02:25, Robert Haas wrote:
> So before the commit in question --
> 3761fe3c20bb040b15f0e8da58d824631da00caa -- T_ID() used to compute an
> offset for a lock within the tranche that was supposed to uniquely
> identify the lock. However, the whole idea of an array per tranche
On Wed, 14 Apr 2021 at 04:46, Andres Freund wrote:
>
> On 2021-04-13 14:25:23 -0400, Robert Haas wrote:
> > On Mon, Apr 12, 2021 at 11:06 PM Andres Freund wrote:
> > You could identify every lock by a tranche ID + an array offset + a
> > "tranche instance ID". But where would you store the
On Tue, 13 Apr 2021 at 21:40, Craig Ringer
wrote:
> Findings:
>
> * A probe without arguments or with simple arguments is just a 'nop'
> instruction
> * Probes that require function calls, pointer chasing, other
> expression evaluation etc may impose a fixed cost to collect u
On Tue, 13 Apr 2021 at 21:05, Craig Ringer
wrote:
> On Tue, 13 Apr 2021 at 11:06, Andres Freund wrote:
> > IIRC those aren't really comparable - the kernel actually does modify
> > the executable code to replace the tracepoints with nops.
>
> Same with userspace static
On Tue, 13 Apr 2021 at 11:06, Andres Freund wrote:
> > Each backend can have different tranche IDs (right?)
>
> No, they have to be the same in each. Note how the tranche ID is part of
> struct LWLock. Which is why LWLockNewTrancheId() has to acquire a lock
> etc.
Ah. I misunderstood that at
On Tue, 13 Apr 2021 at 02:23, Andres Freund wrote:
[I've changed the order of the quoted sections a little to prioritize
the key stuff]
>
> On 2021-04-12 14:31:32 +0800, Craig Ringer wrote:
>
> > It's annoying that we have to pay the cost of computing the tranche name
> >
On Mon, 22 Mar 2021 at 16:38, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> First, a problem: 0002 doesn't build on macOS, because uint64 has been
> used in the probe definitions. That needs to be handled like the other
> nonnative types in that file.
>
Will fix.
All the
On Mon, 22 Mar 2021 at 17:00, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 20.03.21 01:29, Craig Ringer wrote:
> > There is already support for that. See the documentation at the end
> of
> > this page:
> >
> https://www.postgresql.
On Fri, 26 Mar 2021 at 06:15, Bruce Momjian wrote:
> On Thu, Mar 25, 2021 at 08:49:44AM -0400, David Steele wrote:
> > On 1/22/21 1:36 AM, Craig Ringer wrote:
> > >
> > > Would you mind attaching a revised version of the patch with your
> edits?
> > > O
On Sat, 20 Mar 2021, 04:21 Peter Eisentraut, <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 18.03.21 07:34, Craig Ringer wrote:
> > The main reason I didn't want to add more tracepoints than were strictly
> > necessary is that Pg doesn't enable the systemtap semaphor
On Thu, 11 Mar 2021 at 15:57, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 10.03.21 06:38, Craig Ringer wrote:
> > On Wed, 3 Mar 2021 at 20:50, David Steele > <mailto:da...@pgmasters.net>> wrote:
> >
> > On 1/22/21 6:02 AM, Peter E
On Mon, 15 Mar 2021 at 21:01, David Steele wrote:
> On 11/18/20 5:23 AM, Simon Riggs wrote:
> > On Wed, 18 Nov 2020 at 06:42, Craig Ringer
> > wrote:
> >>
> >> On Fri, Nov 13, 2020 at 7:24 PM Simon Riggs
> wrote:
> >>>
> >>>
>
interested in whether Andres will be able to do anything about
identifying LWLocks in a cross-backend manner. But this work doesn't really
depend on that; it'd benefit from it, but would be easily adapted to it
later if needed.
From 36c7ddcbca2dbbcb2967f01cb92aa1f61620c838 Mon Sep 17 00:00:00 2001
Fro
On Thu, 11 Feb 2021, 21:09 Daniil Zakhlystov,
wrote::
>
> 3. Chunked compression allows to compress only well compressible messages
> and save the CPU cycles by not compressing the others
> 4. Chunked compression introduces some traffic overhead compared to the
> permanent (1.2810G vs 1.2761G TX
On Wed, 17 Feb 2021, 07:13 Alvaro Herrera, wrote:
> Here's a new version, where I've renamed everything to "pipeline".
Wow. Thanks.
I
> think the docs could use some additional tweaks now in order to make a
> coherent story on pipeline mode, how it can be used in a batched
> fashion, etc.
>
Hi all
This morning for the the umpteenth time I saw:
some error message: [blank here]
output from a libpq program.
That's because passing a NULL PGresult to PQgetResultErrorMessage() returns
"". But a NULL PGresult is a normal result from PQexec when it fails to
submit a query due to an
On Tue, 16 Feb 2021 at 09:19, Craig Ringer
wrote:
>
> So long as there is a way to "send A", "send B", "send C", "read results
> from A", "send D", and there's a way for the application to associate some
> kind of state (an applica
On Thu, 11 Feb 2021 at 07:51, Alvaro Herrera
wrote:
> On 2021-Jan-21, Alvaro Herrera wrote:
>
> > As you can see in an XXX comment in the libpq test program, the current
> > implementation has the behavior that PQgetResult() returns NULL after a
> > batch is finished and has reported
On Sun, 24 Jan 2021 at 09:12, Andres Freund wrote:
> Hi,
>
> On 2021-01-19 14:16:07 +0800, Craig Ringer wrote:
> > AFAICS it'd be necessary to expand PROCLOG to expose this in shmem.
> > Probably by adding a small bitfield where bit 0 is set if there's a txn
> >
On Fri, 25 Dec 2020 at 06:07, Tom Lane wrote:
> I wrote:
> > Bharath Rupireddy writes:
> >> 4) IIUC, in the patch we mark slot->terminate = true only for
> >> BGW_NEVER_RESTART kind bg workers, what happens if a bg worker has
> >> bgw_restart_time seconds and don't we hit the hanging issue(that
Hi
Thanks so much for reading over this!
Would you mind attaching a revised version of the patch with your edits?
Otherwise I'll go and merge them in once you've had your say on my comments
inline below.
Bruce, Robert, can I have an opinion from you on how best to locate and
structure these
On Thu, 21 Jan 2021 at 09:56, Tom Lane wrote:
> Craig Ringer writes:
> > On Wed, 20 Jan 2021 at 05:23, Tom Lane wrote:
> >> BTW, it also looks like the patch is doing nothing to prevent the
> >> backtrace from being sent to the connected client.
>
> > I
On Wed, 20 Jan 2021 at 02:45, Stephen Frost wrote:
> Greetings,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Craig Ringer (craig.rin...@enterprisedb.com) wrote:
> > > On Thu, 14 Jan 2021 at 03:44, Stephen Frost
> wrote:
> > > > Alright, how d
On Wed, 20 Jan 2021 at 05:23, Tom Lane wrote:
>
> Recursion is scary, but it should (I think) not be possible if this
> is driven off CHECK_FOR_INTERRUPTS. There will certainly be none
> of those in libbacktrace.
>
We can also hold interrupts for the call, and it might be wise to do so.
One
On Wed, 20 Jan 2021 at 01:31, Robert Haas wrote:
> On Sat, Jan 16, 2021 at 3:21 PM Tom Lane wrote:
> > I'd argue that backtraces for those processes aren't really essential,
> > and indeed that trying to make the syslogger report its own backtrace
> > is damn dangerous.
>
> I agree. Ideally I'd
On Tue, 19 Jan 2021 at 12:44, Craig Ringer
wrote:
>
> > We're about halfway there already, see 7e784d1dc. I didn't do the
>> > other half because it wasn't necessary to the problem, but exposing
>> > the shutdown state more fully seems reasonable.
>>
>
&
Presently there doesn't seem to be a way to tell whether a lock is
session-level or transaction-level in the pg_locks view.
I was expecting this to be a quick patch, but the comment on the definition
of PROCLOCKTAG in lock.h notes that shmem state for heavyweight locks does
not track whether the
On Tue, 19 Jan 2021, 02:01 Robert Haas, wrote:
> On Mon, Jan 18, 2021 at 11:56 AM Tom Lane wrote:
> > > I've wanted this in the past, too, so +1 from me.
> >
> > I dunno, this seems pretty scary and easily abusable. There's not all
> > that much that can be done safely in ProcessInterrupts(),
ignal slot for something that won't be relevant for most backends for
most of the postmaster lifetime. Ideas welcomed.
From 1c8c477a5814420011fa034323e82d8eabc6bc5f Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Mon, 18 Jan 2021 14:14:46 +0800
Subject: [PATCH v1 1/4] Provide a hook for Process
with clear references to the right place in the code,
READMEs, etc to look when they need to understand specific topics.
From 96ce89cb7e1a97d9d247fbacba73ade85a01ea38 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Mon, 18 Jan 2021 14:05:15 +0800
Subject: [PATCH v1 2/2] Expand docs on PostgreSQL
the
various scattered but inter-related code.
I hope this helps some new developers in future.
From a16d0a0f8f502ba3631d20d51c7bb50cedea6d57 Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Mon, 18 Jan 2021 12:21:18 +0800
Subject: [PATCH v1 1/2] Comments and cross-references for signal handling
To help
On Mon, 18 Jan 2021 at 00:56, vignesh C wrote:
>
> Thanks for your comments Andres, I will ignore it for the processes
> which do not have access to ProcSignal. I will make the changes and
> post a patch for this soon.
>
I think that's sensible.
I've had variable results with glibc's
On Thu, 14 Jan 2021 at 03:44, Stephen Frost wrote:
>
> Alright, how does this look? The new entries are all under the
> 'obsolete' section to keep it out of the main line, but should work to
> 'fix' the links that currently 404 and provide a bit of a 'softer'
> landing for the other cases that
On Thu, 14 Jan 2021 at 15:56, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 2020-12-19 06:00, Craig Ringer wrote:
> > Patch 1 fixes a bogus tracepoint where an lwlock__acquire event would be
> > fired from LWLockWaitForVar, despite that function never a
On Wed, 13 Jan 2021 at 19:19, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Sat, Dec 19, 2020 at 01:00:01PM +0800, Craig Ringer wrote:
> >
> > The attached patch set follows on from the discussion in [1] "Add LWLock
> > blocker(s) information" by a
On Sat, 26 Dec 2020 at 06:51, Andres Freund wrote:
> Hi,
>
> On 2020-12-23 14:56:07 +0800, Craig Ringer wrote:
> > I want to share an idea I've looked at a few times where I've run into
> > situations where logical slots were inadvertently dropped, or where it
> >
On Sat, 19 Dec 2020 at 13:00, Craig Ringer
wrote:
> Hi all
>
> The attached patch set follows on from the discussion in [1] "Add LWLock
> blocker(s) information" by adding the actual LWLock* and the numeric
> tranche ID to each LWLock related TRACE_POSTGRESQL_foo trac
On Mon, 28 Dec 2020 at 20:09, Masahiko Sawada wrote:
> Hi Craig,
>
> On Sat, Dec 19, 2020 at 2:00 PM Craig Ringer
> wrote:
> >
> > Hi all
> >
> > The attached patch set follows on from the discussion in [1] "Add LWLock
> blocker(s) information&q
On Wed, 6 Jan 2021 at 18:23, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2021-01-06 00:30, Craig Ringer wrote:
> > Perhaps debug_invalidate_system_caches_always ? It's a bit long but we
> > use the debug prefix elsewhere too.
>
> Committed with tha
On Tue, 5 Jan 2021, 22:41 Peter Eisentraut, <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-12-03 07:01, Craig Ringer wrote:
> > To try it out, apply the patch (git am), build with --enable-cassert,
> > then compare:
> >
> >
On Wed, 30 Dec 2020 at 10:11, Andres Freund wrote:
> Hi,
>
> On 2020-11-27 20:22:41 +0200, Heikki Linnakangas wrote:
> > On 26/11/2020 04:50, Tom Lane wrote:
> > > Craig Ringer writes:
> > > > On Wed, Nov 25, 2020 at 9:23 PM Ashutosh Bapat <
> a
On Wed, 23 Dec 2020, 18:57 Amit Kapila, wrote:
> On Wed, Dec 23, 2020 at 12:26 PM Craig Ringer
> wrote:
> >
> > Hi all
> >
> > I want to share an idea I've looked at a few times where I've run into
> situations where logical slots were inadvertently droppe
On Wed, 23 Dec 2020 at 15:51, Craig Ringer
wrote:
>
> I've struggled with this quite a bit myself.
>
>
By the way, I sent in a patch to enhance the static tracepoints available
for LWLocks. See
https://www.postgresql.org/message-id/cagry4nxjo+-hcc2i5h93ttsz4gzo-fsddcw
On Mon, 21 Dec 2020 at 05:27, Andres Freund wrote:
> Hi,
>
> The current wait events are already pretty useful. But I think we could
> make them more informative without adding real runtime overhead.
>
>
All 1-3 sound pretty sensible to me.
I also think there's a 4, but I think the tradeoffs
Hi all
I recently wrote a utility that adds a $node->gdb_backends() method to
PostgresNode instances - figured I'd share it here in case anyone finds it
useful, or wants to adopt it into the features of the TAP tools.
This function provides a one-line way to dump stacks for all running
backends
Hi all
I want to share an idea I've looked at a few times where I've run into
situations where logical slots were inadvertently dropped, or where it
became necessary to decode changes in the past on a slot.
As most of you will know you can't just create a logical slot in the past.
Even if it was
On Wed, 23 Dec 2020 at 05:40, Tom Lane wrote:
> Here's an attempt at closing the race condition discussed in [1]
> (and in some earlier threads, though I'm too lazy to find them).
>
> The core problem is that the bgworker management APIs were designed
> without any thought for exception
ts
I found confusing and hard to understand when investigating this topic.
[1]
https://www.postgresql.org/message-id/CAGRY4nz%3DSEs3qc1R6xD3max7sg3kS-L81eJk2aLUWSQAeAFJTA%40mail.gmail.com
.
From 583c818e3121c0f7c6506b434497c81ae94ee9cb Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Thu, 19 Nov 202
On Thu, 3 Dec 2020 at 15:53, Craig Ringer wrote:
>
> On Tue, 27 Oct 2020 at 16:34, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> On 2020-09-25 09:40, Craig Ringer wrote:
>> > While working on extensions I've often wanted to enable cache
On Tue, 8 Dec 2020 at 17:54, Andrey Borodin wrote:
> > In pglogical3 we already support streaming decoded WAL data to
> alternative writer downstreams including RabbitMQ and Kafka via writer
> plugins.
> Yes, Yandex.Cloud Transfer Manger supports it too. But it has to be
> resynced after
On Tue, 8 Dec 2020 at 15:04, Andres Freund wrote:
> Hi,
>
> On 2020-12-08 04:24:44 +, tsunakawa.ta...@fujitsu.com wrote:
> > I'm looking forward to this from the async+direct I/O, since the
> > throughput of some write-heavy workload decreased by half or more
> > during checkpointing (due to
On Tue, 8 Dec 2020 at 12:02, Andres Freund wrote:
> Hi,
>
> On 2020-12-08 10:55:37 +0800, Craig Ringer wrote:
> > A new kernel API called io_uring has recently come to my attention. I
> > assume some of you (Andres?) have been following it for a while.
>
> Yea, I've sp
References to get things started:
* https://lwn.net/Articles/810414/
* https://unixism.net/loti/what_is_io_uring.html
*
https://blogs.oracle.com/linux/an-introduction-to-the-io_uring-asynchronous-io-framework
*
https://thenewstack.io/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/
Hi all
A new kernel API called io_uring has recently come to my attention. I
assume some of you (Andres?) have been following it for a while.
io_uring appears to offer a way to make system calls including reads,
writes, fsync()s, and more in a non-blocking, batched and pipelined manner,
with or
On Wed, 25 Nov 2020 at 22:11, Alexander Korotkov
wrote:
> Hackers,
>
> PostgreSQL is a complex multi-process system, and we are periodically
> faced with complicated concurrency issues. While the postgres community
> does a great job on investigating and fixing the problems, our ability to
>
On Mon, 7 Dec 2020 at 11:44, Peter Smith wrote:
>
> Basically, I was wondering why can't the "tablesync" worker just
> gather messages in a similar way to how the current streaming feature
> gathers messages into a "changes" file, so that they can be replayed
> later.
>
>
See the related thread
Hi all
Related to my other post about deadlock detector hooks for victim
selection, I'd like to gauge opinions here about whether it's feasible to
inject edges into the deadlock detector's waits-for graph.
Doing so would help with detecting deadlocks relating to shm_mq waits, help
with
Hi folks
Now that we're well on track for streaming logical decoding, it's becoming
more practical to look at parallel logical apply.
The support for this in pglogical3 benefits from a deadlock detector hook.
It was added in the optional patched postgres pglogical can use to enable
various extra
Hi folks
TL;DR: Anyone object to a new bgworker flag that exempts background workers
(such as logical apply workers) from the first round of fast shutdown
signals, and instead lets them to finish their currently in-progress txn
and exit?
This is a change proposal raised for comment before patch
Actually CC'd Petr this time.
On Mon, 7 Dec 2020 at 11:05, Craig Ringer
wrote:
> Reply follows inline. I addressed your last point first, so it's out of
> order.
>
> On Fri, 4 Dec 2020 at 15:33, Andrey Borodin wrote
>
> > If OLAP cannot consume data fast enough - we
Reply follows inline. I addressed your last point first, so it's out of
order.
On Fri, 4 Dec 2020 at 15:33, Andrey Borodin wrote
> If OLAP cannot consume data fast enough - we are out of space due to repl
slot.
There is a much simpler solution to this than logical PITR.
What we should be
On Sat, 5 Dec 2020, 10:03 Amit Kapila, wrote:
> On Fri, Dec 4, 2020 at 7:12 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Dec 3, 2020 at 7:24 PM Amit Kapila
> wrote:
> > >
> > > On Thu, Dec 3, 2020 at 7:04 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Thu, Dec 3, 2020 at 2:55 PM Amit Kapila
On Thu, 3 Dec 2020 at 17:25, Amit Kapila wrote:
> Is there any fundamental problem if
> we commit the transaction after initial copy and slot creation in
> LogicalRepSyncTableStart and then allow the apply of transactions as
> it happens in apply worker?
No fundamental problem. Both approaches
On Thu, 3 Dec 2020, 13:06 Joel Mariadasan (jomariad),
wrote:
> Hi,
>
>
>
> We are using Windows 2019 server.
>
>
>
> Sometimes we see the *pg_ctl.exe* getting automatically deleted.
>
> Due to this, while starting up Postgres windows service we are getting the
> error.
>
> “Error 2: The system
On Wed, 2 Dec 2020 at 15:41, Michael Paquier wrote:
> On Tue, Dec 01, 2020 at 07:39:30PM +0800, Craig Ringer wrote:
> > On Wed, 14 Oct 2020, 13:06 Michael Paquier, wrote:
> >> Yeah, it is safer to assume that it is the responsability of the
> >> backup tool to e
1 - 100 of 529 matches
Mail list logo
