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.
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
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
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 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 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 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 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 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 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
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 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
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 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 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
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
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
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
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 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 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 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
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);
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
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
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
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 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 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 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 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
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 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
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 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 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
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
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
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
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 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
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 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
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 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 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
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 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
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 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 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
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 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,
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
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'
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
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
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 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
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 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 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
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 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
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 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 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 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 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
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 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
> 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 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.
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 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
> 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 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
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 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
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
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
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
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 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 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
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 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
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 CF. How does one
> go about doing that?
>
> Here's the entry: ht
Bonjour Julien,
Attached a patch which attempts to fix this by moving the cancellation
cancelling request after processing results.
Thank you for your fixing. I tested and the problem has been solved
after applying your patch.
Thanks for the patch Fabien. I've hit this issue multiple time
On 4/8/21 2:40 AM, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 11:33:20PM -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2021-04-08 02:05:25 -0400, Tom Lane wrote:
>>> So far the buildfarm seems to be turning green after b3ee4c503 ...
>>> so I wonder what extra condition is needed to cause the f
On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-08, Bruce Momjian wrote:
>
> > pg_stat_activity.queryid is new, but I can imagine cases where you would
> > join pg_stat_activity to pg_stat_statements to get an estimate of how
> > long the query will take --- having on
On Thu, Apr 8, 2021 at 8:01 AM 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 P
On 2021-Apr-08, Bruce Momjian wrote:
> pg_stat_activity.queryid is new, but I can imagine cases where you would
> join pg_stat_activity to pg_stat_statements to get an estimate of how
> long the query will take --- having one using an underscore and another
> one not seems odd.
OK. So far, you h
On Thu, 8 Apr 2021 at 17:44, David Steele wrote:
>
> On 4/8/21 12:29 PM, Simon Riggs wrote:
> > On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
> >
> It has been five months since this patch was updated, so marking
> Returned with Feedback.
>
> Please resubmit to the next CF
On Fri, Apr 9, 2021 at 12:38:29AM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 11:34:25AM -0400, Bruce Momjian wrote:
> >
> > OK, let's get some details. First, pg_stat_statements.queryid already
> > exists (no underscore), and I don't think anyone wants to change that.
> >
> > pg_st
On 4/8/21 12:29 PM, Simon Riggs wrote:
On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
It has been five months since this patch was updated, so marking
Returned with Feedback.
Please resubmit to the next CF when you have a new patch.
There are 2 separate patch-sets on this thread, with sep
Another round of doc review, not yet including all of yesterday's commits.
29c8d614c3 duplicate words
diff --git a/src/include/lib/sort_template.h b/src/include/lib/sort_template.h
index 771c789ced..24d6d0006c 100644
--- a/src/include/lib/sort_template.h
+++ b/src/include/lib/sort_template.h
@@ -2
On Thu, Apr 08, 2021 at 11:34:25AM -0400, Bruce Momjian wrote:
>
> OK, let's get some details. First, pg_stat_statements.queryid already
> exists (no underscore), and I don't think anyone wants to change that.
>
> pg_stat_activity.queryid is new, but I can imagine cases where you would
> join p
On Thu, Apr 08, 2021 at 01:32:12AM +, shiy.f...@fujitsu.com wrote:
> > Attached a patch which attempts to fix this by moving the cancellation
> > cancelling request after processing results.
>
> Thank you for your fixing. I tested and the problem has been solved after
> applying your patch.
On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
> >> It has been five months since this patch was updated, so marking
> >> Returned with Feedback.
> >>
> >> Please resubmit to the next CF when you have a new patch.
> >
> > There are 2 separate patch-sets on this thread, with separate CF entries.
1 - 100 of 187 matches
Mail list logo
