On Mon, Jul 5, 2021 at 7:33 PM Alexey Lesovsky wrote:
>
> Hi,
> Have a few notes about pg_stat_logical_replication_error from the DBA point
> of view (which will use this view in the future).
Thank you for the comments!
> 1. As I understand it, this view might contain many errors related to
>
Alvaro Herrera writes:
> Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
> was sufficient, but it's not: you have to have the PQgetResult in there
> too. Looking ...
Any progress on fixing this?
On Tue, Jul 6, 2021 at 12:43 AM Tom Lane wrote:
>
> Noah Misch writes:
> > On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
> >> However, I think we should also give serious consideration to
> >> "debug_clobber_cache" or "debug_clobber_cache_always" for continuity
> >> with past
On Fri, Jul 2, 2021 at 8:29 PM Simon Riggs wrote:
>
> On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer
> wrote:
> >
>
> > If you don't think the sorts of use cases I presented are worth the trouble
> > that's fair enough. I'm not against adding it on the commit record. It's
> > just that with
On Tue, 30 Mar 2021 at 22:33, bu...@sohu.com wrote:
> I have written a plan with similar functions, It is known that the following
> two situations do not work well.
I read through this thread and also wondered about a Parallel
Partition type operator. It also seems to me that if it could be
On Thu, Jul 01, 2021 at 06:45:25PM +0900, Kyotaro Horiguchi wrote:
> Separating "CREATE TABLE AS EXECUTE" from ExecuteStmt would be cleaner
> but I avoided to change the syntax tree. Instead the attched make
> distinction of $$.type of ExecuteStmt between NULL and "" to use to
> notify the
On Tue, Jul 6, 2021 at 1:56 AM vignesh C wrote:
> The 2nd patch does not apply on Head, please post a rebased version:
> error: patch failed: src/backend/utils/adt/ri_triggers.c:337
> error: src/backend/utils/adt/ri_triggers.c: patch does not apply
Thanks for the heads up.
Rebased patches
On Mon, Jul 05, 2021 at 04:53:06PM +0300, Victor Spirin wrote:
> This patch related to this post:
> https://www.postgresql.org/message-id/CAEepm%3D0FV-k%2B%3Dd9z08cW%3DZXoR1%3Dkw9wdpkP6WAuOrKJdz-8ujg%40mail.gmail.com
How does that cope with durable_rename_excl() where rename() is used
on Windows?
On Sunday, July 4, 2021 1:44 PM Dilip Kumar wrote:
> On Fri, Jul 2, 2021 at 8:16 PM Robert Haas wrote:
> >
> > On Wed, Jun 30, 2021 at 11:46 PM Greg Nancarrow
> wrote:
> > > I personally think "(b) provide an option to the user to specify
> > > whether inserts can be parallelized on a relation"
On Tue, 9 Mar 2021 at 05:13, Ibrar Ahmed wrote:
> It was a minor change therefore I rebased the patch, please take a look.
I only had a quick look at the v3 patch.
+ rel = table_open(rte->relid, NoLock);
+ att = TupleDescAttr(rel->rd_att, var->varattno - 1);
+ if (att->attnotnull &&
On Tue, 8 Sept 2020 at 13:46, Tom Lane wrote:
>
> I've been doing some handwaving about changing the representation
> of Vars, with an eye to making it clear by inspection whether a
> given Var is nullable by some lower outer join [2]. If that work
> ever comes to fruition then the need for
On Mon, Jul 05, 2021 at 09:42:29PM +0530, Bharath Rupireddy wrote:
> I agree. I'm attaching the patch that replaces pg_usleep with
> WaitLatch for {pre, post}_auth_delay. I'm also attaching Michael's
> latest patch stop-backup-latch-v2.patch, just for the sake of cfbot.
I don't object to the
On Tue, 6 Jul 2021 at 06:55, James Coleman wrote:
> While re-reading this code I found a small typo and fixed it (making
> the comment more explicit at the same time).
Thanks. Pushed (9ee91cc58).
David
On Tue, 6 Jul 2021 at 05:03, Justin Pryzby wrote:
>
> Also, if you're going to remove the initializations here, maybe you'd also
> change i and j to C99 "for" declarations like "for (int i=0, j=0; ...)"
>
> - PartitionListValue **all_values = NULL;
> - ListCell *cell;
> - int
On Tue, 6 Jul 2021 at 04:45, Justin Pryzby wrote:
> If you wanted to further squish the patches together, I don't mind being a
> co-author.
Thanks for looking at the patches.
I fixed the couple of things that you mentioned and pushed all 4
patches as a single commit (53d86957e)
David
On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
wrote:
> On 18/6/21 15:02, Alexander Pyhalov wrote:
> > Andrey Lepikhov писал 2021-05-27 07:27:
> >> Next version of the patch.
> >> For searching any problems I forced this patch during 'make check'
> >> tests. Some bugs were found and fixed.
> >
>
On Mon, Jul 5, 2021 at 8:08 AM Ronan Dunklau wrote:
>
> > Ok, I reproduced that case, just not using a group by: by adding the group
> > by a sort node is added in both cases (master and your patch), except that
> > with your patch we sort on both keys and that doesn't really incur a
> >
Noah Misch writes:
> On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
>> However, I think we should also give serious consideration to
>> "debug_clobber_cache" or "debug_clobber_cache_always" for continuity
>> with past practice (though it still feels like "always" is a good
>> word to
On Sat, Jun 12, 2021 at 11:07 AM David Rowley wrote:
>
> A few years ago I wrote a patch to implement the missing aggregate
> combine functions for array_agg and string_agg [1]. In the end, the
> patch was rejected due to some concern [2] that if we allow these
> aggregates to run in parallel
While re-reading this code I found a small typo and fixed it (making
the comment more explicit at the same time).
Thanks,
James
v1-0001-Fix-typo-in-comment.patch
Description: Binary data
On Mon, Jul 5, 2021 at 10:30 PM Álvaro Herrera wrote:
>
> On 2021-Jul-05, vignesh C wrote:
>
> > On Wed, Jun 23, 2021 at 7:32 PM Álvaro Herrera
> > wrote:
> > >
> > > On 2021-Jun-20, Tom Lane wrote:
> > >
> > > > Actually ... isn't there a second race, in the opposite direction?
> > > > IIUC,
Also, if you're going to remove the initializations here, maybe you'd also
change i and j to C99 "for" declarations like "for (int i=0, j=0; ...)"
- PartitionListValue **all_values = NULL;
- ListCell *cell;
- int i = 0;
- int
On 2021-Jul-05, vignesh C wrote:
> On Wed, Jun 23, 2021 at 7:32 PM Álvaro Herrera
> wrote:
> >
> > On 2021-Jun-20, Tom Lane wrote:
> >
> > > Actually ... isn't there a second race, in the opposite direction?
> > > IIUC, the point of this is that once we force some WAL to be sent
> > > to the
On Sun, Apr 4, 2021 at 1:51 PM Amit Langote wrote:
>
> On Fri, Apr 2, 2021 at 11:55 PM Zhihong Yu wrote:
> >
> > Hi,
> >
> > + skip = !ExecLockTableTuple(erm->relation, , markSlot,
> > + estate->es_snapshot,
> > estate->es_output_cid,
> > +
On Mon, Jun 7, 2021 at 8:48 PM Bossart, Nathan wrote:
>
> On 12/25/20, 12:09 PM, "Andres Freund" wrote:
> > When running write heavy transactional workloads I've many times
> > observed that one needs to run the benchmarks for quite a while till
> > they get to their steady state performance.
On Wed, Jun 23, 2021 at 7:32 PM Álvaro Herrera wrote:
>
> On 2021-Jun-20, Tom Lane wrote:
>
> > Actually ... isn't there a second race, in the opposite direction?
> > IIUC, the point of this is that once we force some WAL to be sent
> > to the frozen sender/receiver, they'll be killed for failure
Andrew Dunstan writes:
> On 7/4/21 3:57 PM, Tom Lane wrote:
>> I'm now a little dubious about my claim that this would have helped find
>> any bugs. Invalidating a finished OpClassCache entry does not model any
>> real-world scenario, because as noted elsewhere in LookupOpclassInfo,
>> once such
On Tue, Jul 06, 2021 at 01:48:52AM +1200, David Rowley wrote:
> On Wed, 19 May 2021 at 05:28, Nitin Jadhav
> wrote:
> > I have rebased all the patches on top of
> > 'v2_0001-removed_extra_mem_alloc_from_create_list_bounds.patch'.
> > Attaching all the patches here.
>
> I had a look over these
On Mon, Jul 5, 2021 at 9:25 PM Stephen Frost wrote:
> In general, I agree with Tom's up-thread comment about children hanging
> around after postmaster death making things more difficult for debugging
> and just in general, so I'm in favor of trying to eliminate as many
> cases where that's
On Mon, Jul 5, 2021 at 7:33 AM Michael Paquier wrote:
>
> On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote:
> > My bad. I was talking about the cases when do_pg_stop_backup is called
> > while the server is in recovery mode i.e. backup_started_in_recovery =
> >
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote:
> > My bad. I was talking about the cases when do_pg_stop_backup is called
> > while the server is in recovery mode i.e. backup_started_in_recovery =
> >
Em seg., 5 de jul. de 2021 às 12:07, Ronan Dunklau
escreveu:
> Le lundi 5 juillet 2021, 16:51:59 CEST Ranier Vilela a écrit :
> > >Please find attached a POC patch to do just that.
> > >
> > >The switch to the single-datum tuplesort is done when there is only one
> > >attribute, it is byval (to
Le lundi 5 juillet 2021, 16:51:59 CEST Ranier Vilela a écrit :
> >Please find attached a POC patch to do just that.
> >
> >The switch to the single-datum tuplesort is done when there is only one
> >attribute, it is byval (to avoid having to deal with copy of the
>
> references
>
> >everywhere)
>Please find attached a POC patch to do just that.
>The switch to the single-datum tuplesort is done when there is only one
>attribute, it is byval (to avoid having to deal with copy of the
references
>everywhere) and we are not in bound mode (to also avoid having to move
things
>around).
Hi,
Greetings,
* osumi.takami...@fujitsu.com (osumi.takami...@fujitsu.com) wrote:
> On Monday, July 5, 2021 10:32 AM Michael Paquier wrote:
> > On Sun, Jul 04, 2021 at 11:02:01AM -0400, Stephen Frost wrote:
> > > Rather than RfC, the appropriate status seems like it should be
> > > Rejected, as
Hi
I used the SetFileInformationByHandle function with the
FILE_RENAME_FLAG_POSIX_SEMANTICS flag for the file rename function..
1) The _WIN32_WINNT variable needs to be increased to 0x0A00 (Windows
10). Fixed conflict with #undef CHECKSUM_TYPE_NONE
2) The SetFileInformationByHandle
On Wed, 19 May 2021 at 05:28, Nitin Jadhav
wrote:
> I have rebased all the patches on top of
> 'v2_0001-removed_extra_mem_alloc_from_create_list_bounds.patch'.
> Attaching all the patches here.
I had a look over these and I think what's being done here is fine.
I think this will help speed up
On 2/7/21 01:56, Hywel Carver wrote:
On Wed, Jun 30, 2021 at 12:21 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
I think, here we could ask more general question: do we want to
remove a
'IS NOT NULL' clause from the clause list if the rest of the list
implicitly
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I looked through the patch. Looks good to me.
CFbot tests are
On Sun, 13 Jun 2021 at 21:28, Tomas Vondra
wrote:
>
> Here is a slightly updated version of the patch
>
Hi,
I have looked at this in some more detail, and it all looks pretty
good, other than some mostly cosmetic stuff.
The new code in statext_is_compatible_clause_internal() is a little
hard
Hi,
This is not a live bug.
I think this is worth fixing, just for the sake of style and code
correctness.
As a bonus, we have a reduced scope and standardized return.
regards,
Ranier Vilela
fix_possible_decl_var_uninitialized_varlena.patch
Description: Binary data
Em seg., 5 de jul. de 2021 às 09:02, David Rowley
escreveu:
> On Mon, 5 Jul 2021 at 23:07, Ranier Vilela wrote:
> >
> > Em seg., 5 de jul. de 2021 às 06:44, Dean Rasheed <
> dean.a.rash...@gmail.com> escreveu:
> >> Note, however, that it won't make any difference to performance in the
> >> way
> Ok, I reproduced that case, just not using a group by: by adding the group
> by a sort node is added in both cases (master and your patch), except that
> with your patch we sort on both keys and that doesn't really incur a
> performance penalty.
>
> I think the overhead occurs because in the
On Mon, 5 Jul 2021 at 23:07, Ranier Vilela wrote:
>
> Em seg., 5 de jul. de 2021 às 06:44, Dean Rasheed
> escreveu:
>> Note, however, that it won't make any difference to performance in the
>> way that you're suggesting -- elog() in Postgres is used for "should
>> never happen, unless there's a
On 7/4/21 3:57 PM, Tom Lane wrote:
> Over in [1] it is demonstrated that with CLOBBER_CACHE_ALWAYS enabled,
> initdb accounts for a full 50% of the runtime of "make check-world"
> (well, actually of the buildfarm cycle, which is not quite exactly
> that but close). Since initdb certainly
On 7/4/21 4:27 PM, Tom Lane wrote:
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always". It is too d*mn long.
> It's a serious pain to type in any context where you don't have
> autocomplete to help
Em seg., 5 de jul. de 2021 às 06:44, Dean Rasheed
escreveu:
> On Fri, 2 Jul 2021 at 19:48, Ranier Vilela wrote:
> >
> > If you allow me a small suggestion.
> > Move the initializations of the variable tmp_var to after check if the
> function can run.
> > Saves some cycles, when not running.
> >
Le 01/07/2021 à 18:47, Tom Lane a écrit :
Nicolas CHAHWEKILIAN writes:
As far as I am concerned, I am totally awaiting for this kind of feature
exposed here, for one single reason at this time : the extension
pg_statement_rollback will be much more valuable with the ability of
processing
Hi,
Have a few notes about pg_stat_logical_replication_error from the DBA point
of view (which will use this view in the future).
1. As I understand it, this view might contain many errors related to
different subscriptions. It is better to name
"pg_stat_logical_replication_errors" using the
On Mon, Jul 5, 2021 at 3:16 PM Amit Kapila wrote:
>
> On Thu, Jul 1, 2021 at 6:31 PM Masahiko Sawada wrote:
> >
> > On Thu, Jul 1, 2021 at 12:56 PM Amit Kapila wrote:
>
> Instead of using the syntax "ALTER SUBSCRIPTION name SET SKIP
> TRANSACTION Iconst", isn't it better to use it as a
On 12.06.21 11:41, Fabien COELHO wrote:
The patch includes basic AUTOCOMMIT and ON_ERROR_ROLLBACK tests, which
did not exist before, at all.
I looked at these tests first. The tests are good, they increase
coverage. But they don't actually test the issue that was broken by the
previous
On Sun, 4 Jul 2021 at 09:43, David Rowley wrote:
>
> On Sat, 3 Jul 2021 at 11:04, Dean Rasheed wrote:
> > Thinking about this more, I think it's best not to risk back-patching.
> > It *might* be safe, but it's difficult to really be sure of that. The
> > bug itself is pretty unlikely to ever
On 18/6/21 15:02, Alexander Pyhalov wrote:
Andrey Lepikhov писал 2021-05-27 07:27:
Next version of the patch.
For searching any problems I forced this patch during 'make check'
tests. Some bugs were found and fixed.
Hi.
I've tested this patch and haven't found issues, but I have some
On Tue, Jun 29, 2021 at 2:21 PM Amit Kapila wrote:
>
> On Sat, Jun 26, 2021 at 3:43 PM Amit Kapila wrote:
> >
>
> I am planning to go through the patch once again and would like to
> commit and backpatch till v10 in a day to two unless someone thinks
> otherwise.
>
Pushed.
--
With Regards,
On Thu, Jul 1, 2021 at 6:31 PM Masahiko Sawada wrote:
>
> On Thu, Jul 1, 2021 at 12:56 PM Amit Kapila wrote:
> >
> >
> > Don't we want to clear stats at drop subscription as well? We do drop
> > database stats in dropdb via pgstat_drop_database, so I think we need
> > to clear subscription stats
On Fri, 2 Jul 2021 at 19:48, Ranier Vilela wrote:
>
> If you allow me a small suggestion.
> Move the initializations of the variable tmp_var to after check if the
> function can run.
> Saves some cycles, when not running.
>
OK, thanks. I agree, on grounds of neatness and consistency with
nearby
Hello Ishii-san,
On Thu, 01 Jul 2021 09:03:42 +0900 (JST)
Tatsuo Ishii wrote:
> > v13 patches gave a compiler warning...
> >
> > $ make >/dev/null
> > pgbench.c: In function ‘commandError’:
> > pgbench.c:3071:17: warning: unused variable ‘command’ [-Wunused-variable]
> > const Command
> 1 июля 2021 г., в 20:59, Mark Dilger
> написал(а):
>
>
>
>> On Jun 29, 2021, at 6:25 PM, Mark Dilger
>> wrote:
>>
>> Please find attached a new set of patches.
>
> And again, this time attaching a fifth patch which includes the work to allow
> users who belong to the right security
On Wed, Jun 30, 2021 at 10:30:12PM +, Jacob Champion wrote:
> Done in v3, with a second patch for the code motion.
I have gone through that, tweaking the documentation you have added as
that's the meat of the patch, reworking a bit the declarations of the
callbacks (no need for several
On Wed, 30 Jun 2021 at 05:11, David Christensen
wrote:
> 1) A basic refactor of the existing code to easily handle expanding the
> units we use into a table-based format. This also includes changing the
> return value of `pg_size_bytes()` from an int64 into a numeric, and
> minor test
On 2/7/21 21:23, Tom Lane wrote:
So I'm inclined to propose pushing this and seeing what happens.
+1
But why the Index type still uses for indexing of range table entries?
For example:
- we give int resultRelation value to create_modifytable_path() as Index
nominalRelation value.
-
On Fri, May 21, 2021 at 6:00 PM Ashutosh Bapat
wrote:
>
>
>
> On Fri, May 21, 2021 at 11:26 AM Amit Kapila wrote:
>>
>> On Thu, May 20, 2021 at 5:43 PM Ashutosh Bapat
>> wrote:
>> >
>> > Hi
>> > LogicalIncreaseRestartDecodingForSlot() has a debug log to report a
>> > new restart_lsn. But the
Hi all
The return value of function PQsendFlushRequest is 1 or 0.
---
Sends a request for the server to flush its output buffer.
int PQsendFlushRequest(PGconn *conn);
Returns 1 for success. Returns 0 on any failure.
On Wed, Jun 16, 2021 at 5:36 PM Kyotaro Horiguchi
wrote:
>
> Thanks!
>
> At Wed, 16 Jun 2021 16:52:11 +0900, Masahiko Sawada
> wrote in
> > On Fri, Jun 4, 2021 at 5:35 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > In a very common operation of accidentally specifying a recycled
> > > segment,
Le vendredi 2 juillet 2021, 10:39:44 CEST David Rowley a écrit :
> On Fri, 2 Jul 2021 at 19:54, Ronan Dunklau wrote:
> > I don't know if it's acceptable, but in the case where you add both an
> > aggregate with an ORDER BY clause, and another aggregate without the
> > clause, the output for the
Fabien COELHO писал 2021-07-04 23:29:
The important property of determinism is that if I set a seed, and
then make an identical set of calls to the random API, the results
will be identical every time, so that it's possible to write tests
with predictable/repeatable results.
Hmmm… I like my
On 2021/06/30 10:05, Masahiko Sawada wrote:
> On Fri, Jun 25, 2021 at 9:53 AM Masahiro Ikeda
> wrote:
>>
>> Hi Jamison-san, sawada-san,
>>
>> Thanks for testing!
>>
>> FWIF, I tested using pgbench with "--rate=" option to know the server
>> can execute transactions with stable throughput. As
I tried reviewing the remaining patches. It seems to work correctly,
and passes the tests on my laptop.
> In this pattern I flipped PointerGetDatum(a) to PointerGetDatum(ra.lower),
> because it seems to me correct. I've followed rule of thumb: every sort
> function must extract and use "lower"
On Mon, Jul 5, 2021 at 1:57 AM Tom Lane wrote:
>
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always". It is too d*mn long.
> It's a serious pain to type in any context where you don't have
>
69 matches
Mail list logo
