On 2021-Apr-08, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 02:58:02AM -0400, Tom Lane wrote:
> > No, because if that were the explanation then we'd be getting no
> > buildfarm coverage at all for for pg_stat_statements. Which aside
> > from being awful contradicts the results at coverage.po
Bonjour Fabien,
On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
> >
> > Thanks for the patch Fabien. I've hit this issue multiple time and this is
> > indeed unwelcome. Should we add it as an open item?
>
> It is definitely a open item. I'm not sure where you want to add it…
> p
On Thu, Apr 8, 2021 at 1:04 PM Alvaro Herrera wrote:
>
> On 2021-Apr-08, James Coleman wrote:
>
> > I assume proper procedure for the CF entry is to move it into the
> > current CF and then mark it as committed, however I don't know how (or
> > don't have permissions?) to move it into the current
On 2021-Apr-08, Simon Riggs wrote:
> On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
> > It's not clear to me which patch is which, so perhaps move one CF entry
> > to next CF and clarify which patch is current?
>
> Entry: Maximize page freezing
> has this patch, perfectly fine, awaiting revie
On 2021-Apr-08, James Coleman wrote:
> On Thu, Apr 8, 2021 at 1:04 PM Alvaro Herrera wrote:
> >
> > On 2021-Apr-08, James Coleman wrote:
> >
> > > I assume proper procedure for the CF entry is to move it into the
> > > current CF and then mark it as committed, however I don't know how (or
> > > d
On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> Well, bug or not, we are not going to change back branches for this, and
> if you want a larger discussion, it will have to wait for PG 15.
>
> > > https://www.postgres
Hi,
This started out as a reply to
https://postgr.es/m/20210408170802.GA9392%40alvherre.pgsql
but it's independent enough to just start a new thread...
On 2021-04-08 13:08:02 -0400, Alvaro Herrera wrote:
> Yes, coverage.pg.org runs "make check-world".
>
> Maybe it would make sense to change that
Alvaro Herrera writes:
> On 2021-Apr-08, Tom Lane wrote:
>> Looks like this has issues under EXEC_BACKEND:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2021-04-08%2005%3A50%3A08
> Hmm, I couldn't reproduce this under EXEC_BACKEND or otherwise, but I
> think this is unre
On 2021-04-08 10:50:39 -0700, Andres Freund wrote:
> It's hard to convey just how much nicer it is to see a progress report
> during the test, see the failing tests at the end, without needing to
> wade through reams of log output. The output of the individual tests is
> in testlog.txt referenced
Consider the following snippet
create table data as select generate_series(1,100) s;
do $d$
begin
PERFORM * FROM dblink_connect('test','');
PERFORM * from dblink_send_query('test', 'SELECT * FROM data');
LOOP
if dblink_is_busy('test') = 0
THEN
PERFORM * FROM dblink_get_r
On Thu, 8 Apr 2021 at 18:15, Alvaro Herrera wrote:
>
> On 2021-Apr-08, Simon Riggs wrote:
>
> > On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
>
> > > It's not clear to me which patch is which, so perhaps move one CF entry
> > > to next CF and clarify which patch is current?
> >
> > Entry: Maxi
> On 08-Apr-2021, at 10:24, Bruce Momjian wrote:
>
> On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
>> On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
>> Well, bug or not, we are not going to change back branches for this, and
>> if you want a larger discussion, it
On 2021-Apr-08, Tom Lane wrote:
> Yeah. I hit this on another machine that isn't using EXEC_BACKEND,
> and I concur it looks more like a race condition. I think the problem
> is that autovacuum is calling find_all_inheritors() on a relation it
> has no lock on, contrary to that function's API sp
Alvaro Herrera writes:
> On 2021-Apr-08, Tom Lane wrote:
>> Yeah. I hit this on another machine that isn't using EXEC_BACKEND,
>> and I concur it looks more like a race condition. I think the problem
>> is that autovacuum is calling find_all_inheritors() on a relation it
>> has no lock on, contr
On Thu, Apr 8, 2021 at 11:32 AM David Steele wrote:
> It looks like this CF entry should have been marked as committed so I
> did that.
Thanks.
Here's a patch for the doc update which was mentioned as an open item upthread.
--
Robert Haas
EDB: http://www.enterprisedb.com
update-storage-docs.
> On Apr 7, 2021, at 1:16 PM, Robert Haas wrote:
>
> On Sun, Apr 4, 2021 at 8:02 PM Mark Dilger
> wrote:
>> v18-0001 - Finishes work started in commit 3b6c1259f9 that was overlooked
>> owing to how I had separated the changes in v17-0002 vs. v17-0003
>
> Committed.
Thank you.
>> v18-0002
> On Apr 7, 2021, at 8:43 AM, Andrew Dunstan wrote:
>
>
> On 4/7/21 1:03 AM, Mark Dilger wrote:
>> The v1 patch supported postgres versions back to 8.4, but v2 pushes that
>> back to 8.1.
>>
>> The version of PostgresNode currently committed relies on IPC::Run in a way
>> that is subtly wro
Buildfarm member curculio, which doesn't usually produce
uninitialized-variable warnings, is showing one here:
nbtinsert.c: In function '_bt_doinsert':
nbtinsert.c:411: warning: 'curitemid' may be used uninitialized in this function
nbtinsert.c:411: note: 'curitemid' was declared here
I can see i
On Thu, Apr 08, 2021 at 02:58:04PM -0400, Robert Haas wrote:
> On Thu, Apr 8, 2021 at 11:32 AM David Steele wrote:
> > It looks like this CF entry should have been marked as committed so I
> > did that.
>
> Thanks.
>
> Here's a patch for the doc update which was mentioned as an open item
> upth
On Thu, Apr 8, 2021 at 12:19 PM Tom Lane wrote:
> Buildfarm member curculio, which doesn't usually produce
> uninitialized-variable warnings, is showing one here:
>
> nbtinsert.c: In function '_bt_doinsert':
> nbtinsert.c:411: warning: 'curitemid' may be used uninitialized in this
> function
> nb
On Thu, Apr 8, 2021 at 3:02 PM Mark Dilger wrote:
> Imagine a toasted attribute with 18 chunks numbered [0..17]. Then we update
> the toast to have only 6 chunks numbered [0..5] except we corruptly keep
> chunks numbered [12..17] in the toast table. We'd rather see a report like
> this:
[ toa
On Thu, Apr 8, 2021 at 3:38 PM Justin Pryzby wrote:
> It looks like this should not remove the word "data" ?
Oh, yes, right.
> The compression technique used for either in-line or out-of-line compressed
> -data is a fairly simple and very fast member
> -of the LZ family of compression technique
On 2021-Apr-08, Tom Lane wrote:
> > So I tend to think that my initial instinct was the better direction: we
> > should not be doing any find_all_inheritors() here at all, but instead
> > rely on pg_class.reltuples to be set for the partitioned table.
>
> +1
This patch does that.
--
Álvaro Her
On Thu, Apr 8, 2021 at 1:12 PM Alvaro Herrera
wrote:
> On 2021-Apr-08, Tom Lane wrote:
>
> > > So I tend to think that my initial instinct was the better direction:
> we
> > > should not be doing any find_all_inheritors() here at all, but instead
> > > rely on pg_class.reltuples to be set for the
Peter Geoghegan writes:
> You had a near-identical complaint about a compiler warning that led
> to my commit d64f1cdf2f4 -- that one involved _bt_check_unique()'s
> curitup, while this one is about curitemid. While I have no problem
> silencing this compiler warning now, I don't see any reason to
> On Apr 8, 2021, at 1:05 PM, Robert Haas wrote:
>
> On Thu, Apr 8, 2021 at 3:02 PM Mark Dilger
> wrote:
>> Imagine a toasted attribute with 18 chunks numbered [0..17]. Then we update
>> the toast to have only 6 chunks numbered [0..5] except we corruptly keep
>> chunks numbered [12..17] i
On 2021-Apr-08, Zhihong Yu wrote:
> Hi,
> Within truncate_update_partedrel_stats(), dirty is declared within the loop.
> + if (rd_rel->reltuples != 0)
> + {
> ...
> + if (dirty)
>
> The two if blocks can be merged. The variable dirty can be dropped.
Hi, thanks for reviewing. Y
On Thu, Apr 08, 2021 at 01:20:14AM -0400, Alvaro Herrera wrote:
> On 2021-Apr-07, Alvaro Herrera wrote:
>
> > OK, I bit the bullet and re-did the logic in the way I had proposed
> > earlier in the thread: do the propagation on the collector's side, by
> > sending only the list of ancestors: the co
On 4/8/21 2:00 PM, David Rowley wrote:
> On Thu, 8 Apr 2021 at 22:54, David Rowley wrote:
>>
>> I think the changes in the patch are fairly isolated and the test
>> coverage is now pretty good. I'm planning on looking at the patch
>> again now and will consider pushing it for PG14.
>
> I push th
The previous patches accidentally included some unrelated changes.
--
Justin
>From fd67dd04d1b824a25e113796c235fd9fc9db23e0 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 3 Apr 2021 19:06:37 -0500
Subject: [PATCH v2 1/4] track_activity_query_size is STATS_COLLECTOR category
Not Resourc
On 2021-Apr-08, Justin Pryzby wrote:
> commit 0827e8af70f4653ba17ed773f123a60eadd9f9c9
> |This also introduces necessary reloptions support for partitioned tables
> |(autovacuum_enabled, autovacuum_analyze_scale_factor,
> |autovacuum_analyze_threshold). It's unclear how best to docume
On Thu, Apr 08, 2021 at 05:56:25PM -0400, Alvaro Herrera wrote:
> On 2021-Apr-08, Justin Pryzby wrote:
>
> > commit 0827e8af70f4653ba17ed773f123a60eadd9f9c9
> > |This also introduces necessary reloptions support for partitioned
> > tables
> > |(autovacuum_enabled, autovacuum_analyze_scale
I noticed that nodeFuncs.c appears to have some pretty sloppy work
done in many of the comments. Many look like they've just not been
updated from a copy/paste/edit from another node function.
The attached aims to clean these up.
I plan to push this a later today unless anyone has anything they'
Justin Pryzby writes:
> On Thu, Apr 08, 2021 at 05:56:25PM -0400, Alvaro Herrera wrote:
>> This new bit reads weird:
>>
>> +Most parameters are not supported on partitioned tables, with exceptions
>> +noted below; you may specify them for individual leaf partitions.
> "Except where noted
On Thu, Apr 8, 2021 at 5:21 PM Mark Dilger wrote:
> All this leads me to believe that we should report the following:
>
> 1) If the total number of chunks retrieved differs from the expected number,
> report how many we expected vs. how many we got
> 2) If the chunk_seq numbers are discontiguous,
David Rowley writes:
> I noticed that nodeFuncs.c appears to have some pretty sloppy work
> done in many of the comments. Many look like they've just not been
> updated from a copy/paste/edit from another node function.
> The attached aims to clean these up.
I believe every one of these changes
> On Apr 8, 2021, at 3:11 PM, Robert Haas wrote:
>
> On Thu, Apr 8, 2021 at 5:21 PM Mark Dilger
> wrote:
>> All this leads me to believe that we should report the following:
>>
>> 1) If the total number of chunks retrieved differs from the expected number,
>> report how many we expected vs
On Thu, Apr 8, 2021 at 6:51 PM Mark Dilger wrote:
> #2 is if chunk_seq goes up but skips numbers. #3 is if chunk_seq ever goes
> down, meaning the index scan did something unexpected.
Yeah, sure. But I think we could probably treat those the same way.
--
Robert Haas
EDB: http://www.enterprise
On Thu, Apr 08, 2021 at 12:21:05PM -0400, Tom Lane wrote:
> I see that contrib/test_decoding also sets NO_INSTALLCHECK = 1,
> and the reason it gets tested is that the buildfarm script has
> a special module for that. I guess we need to clone that module,
> or maybe better, find a way to generaliz
On Thu, Apr 8, 2021 at 1:05 PM Merlin Moncure wrote:
> This effect is only noticeable when the remote query is returning
> volumes of data. My question is, is there any way to sleep loop
> client side without giving up 3x performance penalty? Why is that
> that when more local sleep queries are
Hi Julien and Amit Kapila,
On 2021/04/08 17:33, Julien Rouhaud wrote:
On Thu, Apr 08, 2021 at 10:06:56AM +0900, Tatsuro Yamada wrote:
Hi,
I found a typo in jsonfuncs.c, probably.
s/an an/an/
Please find attached patch.
For the archives' sake, this has been pushed as of 8ffb003591.
Juli
On Fri, 9 Apr 2021 at 09:32, Tomas Vondra wrote:
>
> I ran the same set of benchmarks on the v6, which I think should be
> mostly identical to what was committed. I extended the test a bit to
> test table with 0, 1, 5 and 1000 rows, and also with int and text
> values, to see how it works with mor
On Fri, 9 Apr 2021 at 10:11, Tom Lane wrote:
>
> David Rowley writes:
> > I noticed that nodeFuncs.c appears to have some pretty sloppy work
> > done in many of the comments. Many look like they've just not been
> > updated from a copy/paste/edit from another node function.
> > The attached aims
On Thu, Apr 08, 2021 at 10:50:39AM -0700, Andres Freund wrote:
> Obviously all very far from being ready, but this seemed like a good
> enough excuse to mention it ;)
This is nice. Are there any parallelism capabilities?
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote:
>
> Paul, you can submit to the next CF when you are ready with a new patch.
Thanks David! I've made a lot of progress but still need to finish
support for CASCADE on temporal foreign keys. I've been swamped with
other things, but hopefully I can
David Rowley writes:
> hmm ok. I imagine there must be a better way to say that then since
> it confused at least 1 reader so far. My problem is that I assumed
> "result" meant the result of the function that the comment is written
> in, not the result of evaluating the given expression during
>
On Thu, Apr 08, 2021 at 06:27:56PM +0530, Bharath Rupireddy wrote:
> Agree. Please see the attached patch, I removed a fixed waiting time.
> Instead of relying on pg_stat_activity, pg_sleep and
> pg_stat_clear_snapshot, now it depends on pg_terminate_backend and
> pg_wait_for_backend_termination. T
Dear Andrei,
> I think, yes, version of pg_stat_statements is need to be updated. Is
> it will be 1.10 in PG15?
I think you are right.
According to [1] we can bump up the version per one PG major version,
and any features are not committed yet for 15.
[1]: https://www.postgresql.org/message-id/
On Thu, Apr 8, 2021, at 4:25 AM, Ajin Cherian wrote:
> Updated.
- Protocol version. Currently only version 1 is
- supported.
-
+ Protocol version. Currently versions 1 and
+ 2 are supported. The version 2
+ is supported only for server versions 14 and above, and
At Thu, 8 Apr 2021 23:51:34 +1200, Thomas Munro wrote
in
> On Thu, Apr 8, 2021 at 9:46 PM Thomas Munro wrote:
> > I squashed the patch set into one because half of them were fixups,
> > and the two main patches were really parts of the same change and
> > should go in together.
> >
> > I fixed
I rebased this patch to resolve a trivial 1 line conflict from c5b7ba4e6.
--
Justin
>From 0987ca4f62fb8c9b43a3fe142d955d8a9cb6f36f Mon Sep 17 00:00:00 2001
From: Takayuki Tsunakawa
Date: Tue, 9 Feb 2021 12:50:00 +0900
Subject: [PATCH] Fast COPY FROM into the foreign or sharded table.
This featu
On Fri, Apr 09, 2021 at 01:11:35AM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
>> It is definitely a open item. I'm not sure where you want to add it…
>> possibly the "Pg 14 Open Items" wiki page?
>
> Correct.
I was running a long query this morni
On Thu, Apr 08, 2021 at 09:49:20AM -0400, David Steele wrote:
> Overall, 118 of 262 entries were closed during this commitfest (45%). That
> includes 91 patches committed since March 1, which is pretty fantastic.
> Thank you to everyone, especially the committers, for your hard work!
I think that
On 2021-Apr-08, Tom Lane wrote:
> Maybe like
>
> case T_ScalarArrayOpExpr:
> /* ScalarArrayOpExpr's result is boolean ... */
> coll = InvalidOid; /* ... so it has no collation */
> break;
This is much clearer, yeah.
On Fri, Apr 9, 2021 at 5:51 AM Michael Paquier wrote:
>
> On Thu, Apr 08, 2021 at 06:27:56PM +0530, Bharath Rupireddy wrote:
> > Agree. Please see the attached patch, I removed a fixed waiting time.
> > Instead of relying on pg_stat_activity, pg_sleep and
> > pg_stat_clear_snapshot, now it depends
From: David Steele
> Overall, 118 of 262 entries were closed during this commitfest (45%).
> That includes 91 patches committed since March 1, which is pretty
> fantastic. Thank you to everyone, especially the committers, for your
> hard work!
The number of committed patches in the last CF is rec
On Thu, Apr 8, 2021 at 5:49 PM Justin Pryzby wrote:
> I rebased this patch to resolve a trivial 1 line conflict from c5b7ba4e6.
>
> --
> Justin
>
Hi,
In src/backend/commands/copyfrom.c :
+ if (resultRelInfo->ri_RelationDesc->rd_rel->relkind ==
RELKIND_FOREIGN_TABLE)
There are a few steps of
On Thu, Apr 8, 2021 at 6:44 PM Fujii Masao wrote:
> The followings are the open items and discussion points that I'm thinking of.
>
> 1. Currently the extra information (TRUNCATE_REL_CONTEXT_NORMAL,
> TRUNCATE_REL_CONTEXT_ONLY or TRUNCATE_REL_CONTEXT_CASCADING) about how a
> foreign table was sp
On Sat, Apr 03, 2021 at 08:25:46PM -0500, Justin Pryzby wrote:
> Forking this thread
> https://www.postgresql.org/message-id/20210403154336.GG29125%40momjian.us
Didn't see this one, thanks for forking.
> I understood "developer" to mean someone who's debugging postgres itself, not
> (say) a funct
On Thu, Apr 08, 2021 at 09:21:30PM -0400, Alvaro Herrera wrote:
> On 2021-Apr-08, Tom Lane wrote:
>> Maybe like
>>
>> case T_ScalarArrayOpExpr:
>> /* ScalarArrayOpExpr's result is boolean ... */
>> coll = InvalidOid; /* ... so it has no
On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> I didn't think of the warning cases, my bad. How about using SET
> client_min_messages = 'ERROR'; before we call
> pg_wait_for_backend_termination? We can only depend on the return
> value of pg_wait_for_backend_termination, when
On Thu, Apr 8, 2021 at 6:47 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Thu, Apr 8, 2021 at 6:44 PM Fujii Masao
> wrote:
> > The followings are the open items and discussion points that I'm
> thinking of.
> >
> > 1. Currently the extra information (TRUNCATE_REL_CONT
At Fri, 9 Apr 2021 10:59:44 +0900, Michael Paquier wrote
in
> On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> > I didn't think of the warning cases, my bad. How about using SET
> > client_min_messages = 'ERROR'; before we call
> > pg_wait_for_backend_termination? We can only
Hi,
On 2021-04-09 08:39:46 +0900, Michael Paquier wrote:
> On Thu, Apr 08, 2021 at 10:50:39AM -0700, Andres Freund wrote:
> > Obviously all very far from being ready, but this seemed like a good
> > enough excuse to mention it ;)
>
> This is nice. Are there any parallelism capabilities?
Yes. It
Hi,
Looks like the running query is not getting cancelled even though I
issue CTRL+C from psql or kill the backend with SIGINT. This only
happens with PG14 not in PG13. Am I missing something here? Is it a
bug?
create table t1(a1 int);
insert into t1 select * from generate_series(1,100);
On Fri, Apr 9, 2021 at 10:23 AM Euler Taveira wrote:
>
> I didn't like this style because it is not descriptive enough. It is also
> not a
> style adopted by Postgres. I suggest to add something like "This field was
> introduced in version 2" or "This field is available since version 2"
> after t
On Fri, Apr 09, 2021 at 08:24:51AM +0530, Bharath Rupireddy wrote:
> Looks like the running query is not getting cancelled even though I
> issue CTRL+C from psql or kill the backend with SIGINT. This only
> happens with PG14 not in PG13. Am I missing something here? Is it a
> bug?
Yes, see here:
h
On Fri, Apr 9, 2021 at 8:38 AM Justin Pryzby wrote:
>
> On Fri, Apr 09, 2021 at 08:24:51AM +0530, Bharath Rupireddy wrote:
> > Looks like the running query is not getting cancelled even though I
> > issue CTRL+C from psql or kill the backend with SIGINT. This only
> > happens with PG14 not in PG13
On Fri, Apr 09, 2021 at 10:50:53AM +0900, Michael Paquier wrote:
> On Sat, Apr 03, 2021 at 08:25:46PM -0500, Justin Pryzby wrote:
> > Forking this thread
> > https://www.postgresql.org/message-id/20210403154336.GG29125%40momjian.us
>
> Didn't see this one, thanks for forking.
>
> - {"force_
On Fri, Apr 9, 2021 at 6:36 AM Michael Paquier wrote:
>
> On Fri, Apr 09, 2021 at 01:11:35AM +0800, Julien Rouhaud wrote:
> > On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
> >> It is definitely a open item. I'm not sure where you want to add it…
> >> possibly the "Pg 14 Open Items
2021年4月8日(木) 22:14 Fujii Masao :
>
> On 2021/04/08 22:02, Kohei KaiGai wrote:
> >> Anyway, attached is the updated version of the patch. This is still based
> >> on the latest Kazutaka-san's patch. That is, extra list for ONLY is still
> >> passed to FDW. What about committing this version at fir
Here's some little language fixes.
BTW, before beginning "recovery", PG syncs all the data dirs.
This can be slow, and it seems like the slowness is frequently due to file
metadata. For example, that's an obvious consequence of an OS crash, after
which the page cache is empty. I've made a habit
On Fri, Apr 9, 2021 at 9:49 AM Justin Pryzby wrote:
>
> I rebased this patch to resolve a trivial 1 line conflict from c5b7ba4e6.
>
> --
> Justin
On Fri, Apr 9, 2021 at 9:49 AM Justin Pryzby wrote:
> I rebased this patch to resolve a trivial 1 line conflict from c5b7ba4e6.
Thanks for rebasing!
Actually, I've started reviewing this, but I couldn't finish my
review. My apologies for not having much time on this. I'll continue
to work on i
On Wed, Mar 31, 2021 at 7:02 PM Thomas Munro wrote:
> On Fri, Mar 12, 2021 at 7:55 PM Thomas Munro wrote:
> > On Thu, Mar 11, 2021 at 7:34 PM Michael Paquier wrote:
> > > Wow. This probably means that we would be able to get rid of
> > > USE_POSTMASTER_DEATH_SIGNAL?
> >
> > We'll still need it,
On Fri, Apr 9, 2021 at 8:29 AM Ajin Cherian wrote:
>
> On Fri, Apr 9, 2021 at 10:23 AM Euler Taveira wrote:
>>
>>
>> I didn't like this style because it is not descriptive enough. It is also
>> not a
>> style adopted by Postgres. I suggest to add something like "This field was
>> introduced in v
Breaking with tradition, the previous patch included one too *few* changes, and
failed to resolve the OID collisions.
>From d3d33b25e8571f5a2a3124e85164321f19ca Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 16 Mar 2020 14:12:55 -0500
Subject: [PATCH v28 01/11] Document historic behav
On Wed, Apr 07, 2021 at 05:45:16PM +0530, Amit Kapila wrote:
> On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
> >
> > Found that some documentation hasn't been updated for the changes made as
> > part of
> > streaming large in-progress transactions. Attached a patch that adds the
> > missing
On Fri, 9 Apr 2021 at 13:52, Michael Paquier wrote:
>
> On Thu, Apr 08, 2021 at 09:21:30PM -0400, Alvaro Herrera wrote:
> > On 2021-Apr-08, Tom Lane wrote:
> >> Maybe like
> >>
> >> case T_ScalarArrayOpExpr:
> >> /* ScalarArrayOpExpr's result is boolean ... */
>
On Fri, Apr 9, 2021 at 7:29 AM Michael Paquier wrote:
>
> On Fri, Apr 09, 2021 at 06:53:21AM +0530, Bharath Rupireddy wrote:
> > I didn't think of the warning cases, my bad. How about using SET
> > client_min_messages = 'ERROR'; before we call
> > pg_wait_for_backend_termination? We can only depen
On Thu, Apr 08, 2021 at 11:40:08AM -0500, Justin Pryzby wrote:
> Another round of doc review, not yet including all of yesterday's commits.
Thanks for compiling all that. I got through the whole set and
applied the most relevant parts on HEAD. Some of them applied down to
9.6, so I have fixed it
On Fri, Apr 9, 2021 at 9:58 AM Justin Pryzby wrote:
>
> On Wed, Apr 07, 2021 at 05:45:16PM +0530, Amit Kapila wrote:
> > On Wed, Apr 7, 2021 at 1:11 PM Ajin Cherian wrote:
> > >
> > > Found that some documentation hasn't been updated for the changes made as
> > > part of
> > > streaming large in
On Wed, Mar 24, 2021 at 07:56:59PM -0700, Noah Misch wrote:
> That would entail forbidding various shell metacharacters in @testtablespace@.
> One could avoid imposing such a restriction by adding a mkdir() function to
> regress.c and writing it like:
>
> CREATE FUNCTION mkdir(text)
>RETURNS v
On Wed, Apr 7, 2021 at 7:31 PM Robins Tharakan wrote:
> Correct. This is easily reproducible on this test-instance, so let me know if
> you want me to test a patch.
>From your description it sounds like signals are not arriving at all,
rather than some more complicated race. Let's go back to ba
On Fri, 9 Apr 2021 at 16:12, Thomas Munro wrote:
> From your description it sounds like signals are not arriving at all,
> rather than some more complicated race. Let's go back to basics...
> what does the attached program print for you? I see:
>
> tmunro@x1:~/junk$ cc test-signalfd.c
> tmunro@x
Bonjour Michaël,
I was running a long query this morning and wondered why the
cancellation was suddenly broken. So I am not alone, and here you are
with already a solution :)
So, studying through 3a51306, this stuff has changed the query
execution from a sync PQexec() to an async PQsendQuer
Attached v2 does as you suggest.
There is not a single test of "ctrl-c" which would have caught this
trivial and irritating regression. ISTM that a TAP test is doable. Should
one be added?
--
Fabien.
101 - 187 of 187 matches
Mail list logo
