On Wed, Jan 12, 2022 at 01:41:42PM +0800, Julien Rouhaud wrote:
> The January commitfest should have started almost two weeks ago, but given
> that
> nothing happened until now I think that it's safe to assume that either
> everyone forgot or no one wanted to volunteer.
Thanks, Julien!
--
On Thu, Jan 13, 2022 at 02:01:24AM +0300, Sergey Shinderuk wrote:
> Gave it a thorough read. Looks good, except for errstr not set in a couple
> of places (see the diff attached).
Thanks for the review. The comments about pg_hmac_ctx->data were
wrong from the beginning, coming, I guess, from
13.01.2022 09:36, Thomas Munro wrote:
> On Wed, Jan 12, 2022 at 8:00 PM Alexander Lakhin wrote:
>> By the look of things, you are right and this is the localhost-only issue.
> But can't that be explained with timing races? You change some stuff
> around and it becomes less likely that you get a
On Thursday, January 13, 2022 12:38 PM, Fujii Masao
wrote:
> Isn't it better to tab-complete not only "PARTITION OF" but also "(" for
> CREATE
> FOREIGN TABLE?
Thanks for your review. Left bracket completion added.
> IMO it's better to make the docs changes in separate patch because they are
Thanks for posting the merged v63.
Here are my review comments for the v63-0001 changes.
~~~
1. src/backend/replication/logical/proto.c - logicalrep_write_tuple
TupleDesc desc;
- Datum values[MaxTupleAttributeNumber];
- bool isnull[MaxTupleAttributeNumber];
+ Datum*values;
+ bool
On Wed, Jan 12, 2022 at 8:00 PM Alexander Lakhin wrote:
> By the look of things, you are right and this is the localhost-only issue.
But can't that be explained with timing races? You change some stuff
around and it becomes less likely that you get a FIN to arrive in a
super narrow window,
On Wed, Jan 12, 2022 at 11:39 AM Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Dec 28, 2021 at 10:56 AM Bharath Rupireddy
> wrote:
> >
> > attaching v1-0001-XXX from the initial mail again just for the sake of
> > completion:
>
> Unfortunately this breaks the cfbot as it tries to apply this patch
>
On Thu, Jan 13, 2022 at 3:47 AM Bossart, Nathan wrote:
>
> On 12/31/21, 4:44 AM, "Bharath Rupireddy"
> wrote:
> > Currently the server is erroring out when unable to remove/parse a
> > logical rewrite file in CheckPointLogicalRewriteHeap wasting the
> > amount of work the checkpoint has done
"Efrain J. Berdecia" writes:
> After attempting to use gin and gist indexes for our queries that run against
> citext columns, our team has come up with the following to make our queries
> run from 2 mins to 25ms;CREATE EXTENSION pg_trgmCREATE EXTENSION btree_gin
> --may not be needed,
Hi,
On 2022-01-08 19:32:36 +0100, Fabien COELHO wrote:
> Attached v13 where the crash test is moved to tap.
The reason this test constantly fails on cfbot windows is a use-after-free
bug.
I figured that out in the context of another thread, so the debugging is
there:
Hi,
On 2022-01-12 20:03:14 -0800, Andres Freund wrote:
> So it looks like psql is hanging somewhere after that. I assume with an error
> popup that nobody can click on :/.
Not quite. Psql is actually just logging output in an endless loop. I
connected with cdb.exe.
kP:
`007fd3c8
On Thu, Jan 13, 2022 at 12:19 PM Julien Rouhaud wrote:
> On Tue, Jan 11, 2022 at 05:08:59PM +0900, Amit Langote wrote:
> >
> > I think I've managed to apply f4566345cf40b into v13 and v14. Patches
> > attached.
> >
>
> FTR this doesn't play well with the cfbot unfortunately as it tries to apply
After attempting to use gin and gist indexes for our queries that run against
citext columns, our team has come up with the following to make our queries run
from 2 mins to 25ms;CREATE EXTENSION pg_trgmCREATE EXTENSION btree_gin --may
not be needed, checking
CREATE OPERATOR CLASS
Hi,
On 2022-01-12 18:25:26 -0800, Andres Freund wrote:
> There's one interesting patch that also times out just on windows, albeit in
> another test group:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/36/2096
>
> This IMO looks likely to be a bug in psql introduced by
On 1/12/22, 1:28 PM, "Bossart, Nathan" wrote:
On 1/11/22, 11:46 PM, "Masahiko Sawada" wrote:
> Regarding the new pg_stat_progress_vacuum_index view, why do we need
> to have a separate view? Users will have to check two views. If this
> view is expected to be used together with
On 2022/01/11 21:43, tanghy.f...@fujitsu.com wrote:
Hi
Attached a patch to improve the tab completion for foreigh table.
Thanks!
Isn't it better to tab-complete not only "PARTITION OF" but also "(" for CREATE
FOREIGN TABLE?
Also modified some DOC description of ALTER TABLE at [1] in
Hi,
On Tue, Jan 11, 2022 at 05:08:59PM +0900, Amit Langote wrote:
>
> I think I've managed to apply f4566345cf40b into v13 and v14. Patches
> attached.
>
FTR this doesn't play well with the cfbot unfortunately as it tries to apply
both patches, and obviously on the wrong branches anyway.
It
Hi,
On Mon, Dec 20, 2021 at 04:13:04PM +0900, Amit Langote wrote:
>
> Patch 0002 needed a rebase, because a conflicting change to
> expected/rules.out has since been committed.
The cfbot reports new conflicts since about a week ago with this patch:
Latest failure:
On Wed, Jan 12, 2022 at 6:49 PM Noah Misch wrote:
> On Mon, Jan 10, 2022 at 03:34:27PM -0800, Zhihong Yu wrote:
> > On Sun, Jan 9, 2022 at 6:45 PM Zhihong Yu wrote:
> > > gcc -Wall -Wmissing-prototypes -Wpointer-arith
> > > -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> > >
On 2022/01/06 17:29, Etsuro Fujita wrote:
On Fri, Dec 3, 2021 at 6:07 PM Fujii Masao wrote:
On 2021/11/16 18:55, Etsuro Fujita wrote:
I changed my mind; I’ll update the patch to ignore the error as
before, because 1) as far as I know, there are no reports from the
field concerning that we
On Mon, Jan 10, 2022 at 03:34:27PM -0800, Zhihong Yu wrote:
> On Sun, Jan 9, 2022 at 6:45 PM Zhihong Yu wrote:
> > gcc -Wall -Wmissing-prototypes -Wpointer-arith
> > -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> > -Wmissing-format-attribute -Wimplicit-fallthrough=3
Hi,
On 2022-01-12 15:58:26 -0800, Andres Freund wrote:
> On 2022-01-12 14:34:00 -0500, Andrew Dunstan wrote:
> > For some considerable time the recovery tests have been at best flaky on
> > Windows, and at worst disastrous (i.e. they can hang rather than just
> > fail). It's a problem I worked
On Wed, Jan 12, 2022 2:02 PM Masahiko Sawada wrote:
>
> I've attached an updated patch that incorporated all comments I got so far.
>
Thanks for updating the patch. Here are some comments:
1)
+ Skip applying changes of the particular transaction. If incoming data
Should "Skip" be
Hi,
On 2022-01-12 15:22:18 +, Jelte Fennema wrote:
> This patch also includes a test for this new API (and also the already
> existing cancellation APIs). The test can be easily run like this:
>
> cd src/test/modules/libpq_pipeline
> make && ./libpq_pipeline cancel
Right now tests
Hi,
On 2022-01-13 12:40:00 +1300, Thomas Munro wrote:
> On Thu, Jan 13, 2022 at 12:24 AM Julien Rouhaud wrote:
> > On Wed, Jan 12, 2022 at 01:51:24PM +0300, Michail Nikolaev wrote:
> > > https://cirrus-ci.com/task/6532060239101952
> > > https://cirrus-ci.com/task/471606276096
>
> For the
On Tue, Jun 22, 2021 at 4:13 AM Robert Haas wrote:
> I think that's a reasonable request. I'm not sure that I believe it's
> 100% necessary, but it's certainly an improvement on a technical
> level, and given that the proposed change could impact quite a lot of
> plans, it's fair to want to see
Hi,
On 2022-01-12 14:34:00 -0500, Andrew Dunstan wrote:
> For some considerable time the recovery tests have been at best flaky on
> Windows, and at worst disastrous (i.e. they can hang rather than just
> fail). It's a problem I worked around on my buildfarm animals by
> disabling the tests,
> Hmm, this got me curious. If Sync itself cannot fail, then what is this
> sentence really saying: "This parameterless message (ed. Sync) causes the
> backend to close the current transaction if it's not inside a BEGIN/COMMIT
> transaction block (“close” meaning to commit if no error, or roll
On 12/28/21, 8:25 AM, "Peter Eisentraut"
wrote:
> (The "withcb" naming maybe isn't great; better ideas welcome.)
FWIW I immediately understood that this meant "with callback," so it
might be okay.
> Not included in this patch set, but food for further thought: The
> pg_analyze_and_rewrite_*()
On Thu, Jan 13, 2022 at 12:24 AM Julien Rouhaud wrote:
> On Wed, Jan 12, 2022 at 01:51:24PM +0300, Michail Nikolaev wrote:
> > https://cirrus-ci.com/task/6532060239101952
> > https://cirrus-ci.com/task/471606276096
For the record, cfbot only started running the recovery tests on
Windows a
On 12.01.2022 14:32, Michael Paquier wrote:
On Wed, Jan 12, 2022 at 12:56:17PM +0900, Michael Paquier wrote:
Attached is a rebased patch for the HMAC portions, with a couple of
fixes I noticed while going through this stuff again (mostly around
SASLprep and pg_fe_scram_build_secret), and a fix
Pushed, after clarifying the comments a bit.
I also looked into what would it take to consider incremental paths, and
in principle it doesn't seem all that complicated. The attached PoC
patch extends get_cheapest_fractional_path_for_pathkeys() to optionally
build incremental sort on paths if
On Mon, Jun 28, 2021 at 8:16 PM Thomas Munro wrote:
[v4 patchset]
Hi Thomas,
(Sorry for the delay -- I have some time to put into this now.)
> The lower numbered patches are all things that are reused in many
> places, and in my humble opinion improve the notation and type safety
> and code
On 1/12/22 16:15, Tom Lane wrote:
> Andrew Dunstan writes:
>> For some considerable time the recovery tests have been at best flaky on
>> Windows, and at worst disastrous (i.e. they can hang rather than just
>> fail).
> How long is "some considerable time"? I'm wondering if this isn't
> the
On 12/31/21, 4:44 AM, "Bharath Rupireddy"
wrote:
> Currently the server is erroring out when unable to remove/parse a
> logical rewrite file in CheckPointLogicalRewriteHeap wasting the
> amount of work the checkpoint has done and preventing the checkpoint
> from finishing. This is unlike
Hello.
It is also could be related -
https://www.postgresql.org/message-id/flat/20220112112425.pgzymqcgdy62e7m3%40jrouhaud#097b54a539ac3091ca4e4ed8ce9ab89c
(both Windows and Linux cases.
Best regards,
Michail.
Andrew Dunstan writes:
> For some considerable time the recovery tests have been at best flaky on
> Windows, and at worst disastrous (i.e. they can hang rather than just
> fail).
How long is "some considerable time"? I'm wondering if this isn't
the same issue under discussion in
On 12/9/21 09:04, Himanshu Upadhyaya wrote:
>
>
>
> Few comments For 0002-SQL-JSON-constructors-v59.patch:
> 1)
> + if (IsA(node, JsonConstructorExpr))
> + {
> + JsonConstructorExpr *ctor = (JsonConstructorExpr *) node;
> + ListCell *lc;
> +
On 1/5/22 02:53, Simon Riggs wrote:
> On Wed, 22 Dec 2021 at 11:35, Simon Riggs
> wrote:
>> On Mon, 15 Nov 2021 at 22:45, Alvaro Herrera wrote:
>>> On 2021-Nov-15, Alvaro Herrera wrote:
>>>
Thanks everyone for the feedback. I attach a version with the fixes
that were submitted, as
On 2022-Jan-12, Andrei Matei wrote:
> If Sync itself cannot fail, then what is this
> sentence really saying: "This parameterless message (ed. Sync) causes the
> backend to close the current transaction if it's not inside a BEGIN/COMMIT
> transaction block (“close” meaning to commit if no error,
For some considerable time the recovery tests have been at best flaky on
Windows, and at worst disastrous (i.e. they can hang rather than just
fail). It's a problem I worked around on my buildfarm animals by
disabling the tests, hoping to find time to get back to analysing the
problem. But now
On 1/11/22, 11:46 PM, "Masahiko Sawada" wrote:
> Regarding the new pg_stat_progress_vacuum_index view, why do we need
> to have a separate view? Users will have to check two views. If this
> view is expected to be used together with and joined to
> pg_stat_progress_vacuum, why don't we provide
Dave Page writes:
> On Tue, Jan 11, 2022 at 5:55 PM Tom Lane wrote:
>> So it looks like their plan is to unconditionally write "permissive=0"
>> or "permissive=1", while Dave's patch just prints nothing in enforcing
>> mode. While I can see some virtue in brevity, I think that doing
>> exactly
On 2022-Jan-11, Justin Pryzby wrote:
> Is there any coordination between the "column filter" patch and the "row
> filter" patch ?
Not beyond the grammar, which I tested.
> Are they both on track for PG15 ?
I think they're both on track, yes.
> Has anybody run them together ?
Not me.
> I
> Hi,
>
> According to the cfbot, the patch doesn't apply anymore and needs a
> rebase: http://cfbot.cputube.org/patch_36_3290.log
V4 rebased attached.
special-guc-values-v4.patch
Description: Binary data
Peter Eisentraut writes:
> On 11.01.22 17:06, Tom Lane wrote:
>> Nonetheless, we need to make a recommendation to the
>> buildfarm owners about what's the minimum python3 version we intend
>> to support going forward.
> Well, the minimum supported version has always been the oldest version
>
On Wed, Jan 12, 2022 at 2:39 AM Peter Eisentraut
wrote:
> Well, the minimum supported version has always been the oldest version
> that actually works. I don't think we ever said, we support >= X, even
> though < X still actually works, about any dependency.
I think that we sometimes say that
On Wed, Jan 12, 2022 at 9:32 AM Amit Langote wrote:
> I have pondered on the possible hazards before writing the patch,
> mainly because the concerns about a previously discussed proposal were
> along similar lines [1].
True. I think that the hazards are narrower with this proposal,
because if
Thanks!
I work on CockroachDB - which is wire-compatible with Postgres - so I'm
interested in what the server can and cannot do.
> Uh ... I don't think Sync itself can fail. Any ErrorResponse you see
> there is really from failure of some prior command.
Hmm, this got me curious. If Sync
Andrei Matei writes:
> I've got a question about the wire protocol; the relevant text in the docs
> seems a bit ambiguous to me. If the processing of a Sync message fails
> (e.g. because the commit of the current transaction fails), is the backend
> allowed to respond with an ErrorResponse, in
>Or, does the backend swallow the error, and return only the ReadyForQuery
(I hope not).
What is your backend version?
Here's a well-known case when the backend did swallow the error:
"Error on failed COMMIT"
Hello Postgres friends,
I've got a question about the wire protocol; the relevant text in the docs
seems a bit ambiguous to me. If the processing of a Sync message fails
(e.g. because the commit of the current transaction fails), is the backend
allowed to respond with an ErrorResponse, in
On 1/12/22, 7:43 AM, "John Naylor" wrote:
> On Wed, Jan 12, 2022 at 1:49 AM Masahiko Sawada wrote:
>> As another idea, we might be able to add a new option that takes an
>> optional integer value, like VACUUM (MIN_XID), VACUUM (MIN_MXID), and
>> VACUUM (MIN_XID 50). We vacuum only tables
Hi everyone,
I've adapted the work that Konstantina did for pl/julia as part of her
GSOC project to add an example of handling triggers to plsample. Which
was based from pl/tcl and pl/perl.
One aspect that I'm not sure about is whether the example should be
duplicating code (as it is now) for
Thanks for all the cleanup and adding of windows support. To me it now looks
good to merge.
Meanwhile I've created another patch that adds, a non-blocking version of
PQcancel to libpq.
Which doesn't have this problem by design, because it simply reuses the normal
code for
connection
On Wed, Jan 12, 2022 at 1:49 AM Masahiko Sawada wrote:
> It seems to me that adding new syntax instead of a new option is less
> flexible. In the future, for instance, when we support parallel heap
> scan for VACUUM, we may want to add a parallel-related option to both
> VACUUM statement and
While testing a buildfarm module to automate running headerscheck and
cpluspluscheck, I encountered a bunch of errors like this:
Jan 12 09:35:57 In file included from
/home/andrew/bf/root/HEAD/pgsql.build/../pgsql/src/include/port/atomics.h:70,
Jan 12 09:35:57 from
The existing PQcancel API is using blocking IO. This makes PQcancel
impossible to use in an event loop based codebase, without blocking the
event loop until the call returns.
This patch adds a new cancellation API to libpq which is called
PQcancelConnectionStart. This API can be used to send
On Wed, Jan 12, 2022 at 04:16:36PM +0100, Magnus Hagander wrote:
> On Wed, Jan 12, 2022 at 6:42 AM Julien Rouhaud wrote:
> >
> > Note that I don't have admin permissions on the cf app, so I'd be glad if
> > something could grant it!
>
> Granted!
Thanks Magnus!
On Wed, Jan 12, 2022 at 6:42 AM Julien Rouhaud wrote:
>
> Note that I don't have admin permissions on the cf app, so I'd be glad if
> something could grant it!
Granted!
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On Tue, Jan 11, 2022 at 9:20 PM Justin Pryzby wrote:
>
> On Tue, Jan 11, 2022 at 07:58:56PM -0500, John Naylor wrote:
> > + // FIXME: also check reloption
> > + // WIP: 95% is a starting point for discussion
> > + if ((table_xid_age < autovacuum_freeze_max_age
On Tue, Jan 11, 2022 at 8:57 PM Peter Geoghegan wrote:
> On Tue, Jan 11, 2022 at 4:59 PM John Naylor
> > For the PoC I wanted to try re-using existing keywords. I went with
> > "VACUUM LIMIT" since LIMIT is already a keyword that cannot be used as
> > a table name. It also brings "wraparound
Thanks for taking the time to look at this.
On Wed, Jan 12, 2022 at 1:22 AM Robert Haas wrote:
> On Fri, Dec 24, 2021 at 10:36 PM Amit Langote wrote:
> > However, using an idea that Robert suggested to me off-list a little
> > while back, it seems possible to determine the set of partitions
zlib still causes check-world to get stuck. I first mentioned this last March:
20210319062800.gi11...@telsasoft.com
Actually all the compression methods seems to get stuck with
time make check -C src/bin/pg_rewind
time make check -C src/test/isolation
For CI purposes, there should be an 0003
On Wed, Jan 12, 2022 at 11:32 AM Masahiko Sawada wrote:
>
> On Wed, Jan 12, 2022 at 12:21 PM Amit Kapila wrote:
> >
> > On Wed, Jan 12, 2022 at 5:49 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Jan 11, 2022 at 7:08 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Jan 11, 2022 at 1:51
>
> Maxim, maybe it's still a good idea to isolate those two patches and
> submit them separately first, to reduce the size of the rest of the patch?
>
> Looks to me like the best next actions would be:
>
> 1. Submit a patch that uses XID_FMT everywhere, as a cosmetic change.
> This
On 10.01.22 19:56, rajesh singarapu wrote:
I am trying to migrate my postgres to linux, as we are moving away from
windows.
I am trying both dump/restore and logical decoding, but people are not
happy with performance.
Is there a way/tooling I can use around WAL shipping/physical
replication
Re: patch that uses XID_FMT everywhere ... to make the main patch much smaller
That's exactly what my previous patch did, plus the patch to support 64-bit
GUCs.
Maxim, maybe it's still a good idea to isolate those two patches and submit
them separately first, to reduce the size of the rest of
On Sat, 8 Jan 2022 at 08:21, Maxim Orlov wrote:
>>
>>Perhaps we can merge some of the code cleanup that it contained, such as
>> using XID_FMT everywhere and creating a type for the kind of page returned
>> by TransactionIdToPage() to make the code cleaner.
>
>
> Agree, I think this is a
On Thursday, December 23, 2021 6:37 PM Wang, Wei/王 威
wrote:
> On Wednesday, December 22, 2021 10:30 PM osumi.takami...@fujitsu.com
> wrote:
> > On Wednesday, December 22, 2021 8:38 PM I wrote:
> > > Do we expect these commit counts which come from empty transactions ?
> > This is another issue
On Wed, Jan 12, 2022 at 12:56:17PM +0900, Michael Paquier wrote:
> Attached is a rebased patch for the HMAC portions, with a couple of
> fixes I noticed while going through this stuff again (mostly around
> SASLprep and pg_fe_scram_build_secret), and a fix for a conflict
> coming from 9cb5518.
On 12.01.22 01:41, Alvaro Herrera wrote:
Therefore, I propose to add an index on pg_publication_rel.prpubid.
That seems very reasonable.
On Wed, Jan 12, 2022 at 01:51:24PM +0300, Michail Nikolaev wrote:
> Hello.
>
> Looks like logical replication also affected:
>
> [08:26:35.599] # poll_query_until timed out executing this query:
> [08:26:35.599] # SELECT count(1) = 0 FROM pg_subscription_rel WHERE
> srsubstate NOT IN ('r', 's');
On Tue, Jan 11, 2022 at 8:13 PM Fabrice Chapuis
wrote:
> Can you explain why you think this will help in solving your current
> problem?
>
> Indeed your are right this function won't help, we have to look elsewhere.
>
> It is still not clear to me why the problem happened? IIUC, after
>
Hello.
Looks like logical replication also affected:
[08:26:35.599] # poll_query_until timed out executing this query:
[08:26:35.599] # SELECT count(1) = 0 FROM pg_subscription_rel WHERE
srsubstate NOT IN ('r', 's');
[08:26:35.599] # expecting this output:
[08:26:35.599] # t
[08:26:35.599] #
Hi, hackers!
I've noticed that on my branch with amcheck improvements cfbot on windows
server 2019 fails stream replication test.
https://cirrus-ci.com/task/5353503093686272
I don't see any relation of it to the changes in my patch. Furthermore it
also fails on the other СF branch
Hi,
On Tue, Nov 02, 2021 at 04:40:39PM +0530, Dilip Kumar wrote:
>
> I have fixed this, the updated patch is attached.
The cfbot reports that this patch doesn't compile:
https://cirrus-ci.com/task/564273490432?logs=build
[03:01:24.477] snapbuild.c: In function ‘SnapBuildInitialSnapshot’:
On Tue, Jan 11, 2022 at 5:55 PM Tom Lane wrote:
> Andrew Dunstan writes:
> > I am not that person either. I agree this looks reasonable, but I also
> > would like the opinion of an expert, if we have one.
>
> I'm not sure we do anymore. Anyway, I tried this on Fedora 35 and
> confirmed that it
Hi,
On Mon, Aug 30, 2021 at 02:11:34PM -0700, Zhihong Yu wrote:
> On Mon, Aug 30, 2021 at 1:23 PM Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> wrote:
>
> > rebased patch set
>
> +WITH RETURN
> +WITHOUT RETURN
> +
> +
> + This option is only valid for cursors
On Wed, Jan 12, 2022 at 11:11 AM Julien Rouhaud wrote:
>
> The January commitfest should have started almost two weeks ago, but given
> that
> nothing happened until now I think that it's safe to assume that either
> everyone forgot or no one wanted to volunteer.
>
> I'm therfore volunteering to
On 10.01.22 14:14, Peter Eisentraut wrote:
I think this patch is necessary:
diff --git a/src/interfaces/ecpg/preproc/pgc.l
b/src/interfaces/ecpg/preproc/pgc.l
index 07fee80a9c..3529b2ea86 100644
--- a/src/interfaces/ecpg/preproc/pgc.l
+++ b/src/interfaces/ecpg/preproc/pgc.l
@@ -753,7 +753,7
On Sat, Aug 28, 2021 at 10:40:42AM +0900, Michael Paquier wrote:
> On Fri, Aug 27, 2021 at 12:28:42PM -0700, Andres Freund wrote:
> > Isn't that just going to end up with extension code erroring out and/or
> > blocking waiting for a bgworker to start?
>
> Well, that's the point to block things
> 8 янв. 2022 г., в 01:56, Stephen Frost написал(а):
>>
>> It's discussed in last year's thread. The thinking is that there tends to be
>> *fewer* exploitable opportunities between application->DB than between
>> browser->app.
>
> Yes, this was discussed previously and addressed.
What else
On Wed, Jan 12, 2022 at 3:00 AM Alvaro Herrera wrote:
>
> I just looked at 0002 because of Justin Pryzby's comment in the column
> filtering thread, and realized that the pgoutput row filtering has a
> very strange API, which receives both heap tuples and slots; and we seem
> to convert to and
Hi,
On Wed, Sep 29, 2021 at 03:55:22PM -0500, David Christensen wrote:
>
> I can see the argument for this in terms of being cautious/explicit about
> what gets removed, however
> the utility in this particular form was related to being able to *avoid*
> having to manually figure out
> the
Hi,
On Thu, Nov 25, 2021 at 10:00 PM Antonin Houska wrote:
>
> So it should be ok if the temporary undo is managed and discarded by
> individual backends. Patch 0005 of the new series tries to do that.
The cfbot reports that at least the 001 patch doesn't apply anymore:
86 matches
Mail list logo
