On Mon, Jul 12, 2021 at 5:28 PM Ashutosh Bapat
wrote:
>
> On Mon, Jul 12, 2021 at 8:39 AM Amit Kapila wrote:
>>
>> On Mon, Jul 5, 2021 at 12:54 PM Masahiko Sawada
>> wrote:
>> >
>> > On Fri, May 21, 2021 at 6:00 PM Ashutosh Bapat
>> > wrote:
>> > >
>> > > It's there in CF. I am fine with
On Fri, Aug 6, 2021 at 9:57 PM Japin Li wrote:
>
> >
> > Hmm yes, it cannot cover all cases. I had somehow misunderstood that
> > the subscriber knows which relations are associated with which
> > publications. Given that the subscriber doesn’t know which relations
> > are associated with which
Michael Paquier writes:
> On Fri, Aug 06, 2021 at 10:48:40AM -0400, Tom Lane wrote:
>> Given that it took this long to notice the problem at all, maybe
>> this is not a fix to cram in on the weekend before the release wrap.
>> But I don't see why we need to settle for "mostly works" when
>>
On Fri, Aug 06, 2021 at 10:48:40AM -0400, Tom Lane wrote:
> AFAICT that works and generates the identical parse tree to the original
> coding. The only place touched by the patch where it's a bit difficult to
> make the syntax unambiguous this way is
>
> "CREATE TEMP TABLE %s
On Fri, Jul 30, 2021 at 3:01 PM Peter Geoghegan wrote:
> The RMT discussed this recently. We are concerned about this issue,
> including how it has been handled so far.
>
> If you're unable to resolve the issue (or at least commit time to
> resolving the issue) then the RMT will call for the
On 8/6/21 3:07 PM, David Rowley wrote:
On Wed, 4 Aug 2021 at 02:10, Tomas Vondra wrote:
A review would be nice, although it can wait - It'd be interesting to
know if those patches help with the workload(s) you've been looking at.
I tried out the v2 set of patches using the attached scripts.
Rebased. Also added a stronger check to see if the standby is stuck in
recovery_min_apply_delay:
$node_standby->poll_query_until('postgres', qq{
SELECT wait_event = 'RecoveryApplyDelay' FROM pg_stat_activity
WHERE backend_type='startup';
}) or die "Timed out checking if startup is in
On Fri, Aug 6, 2021 at 2:50 PM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 10:09 AM Amit Kapila wrote:
> >
> > On Fri, Aug 6, 2021 at 5:09 AM Masahiko Sawada
> > wrote:
> > >
> >
> > But, isn't this happening because of your suggestion to compare the
> > current set of relations with
Hi Drouvot,
I can reproduce the issue you mentioned on REL_12_STABLE as well as Master
branch, but the patch doesn't apply to REL_12_STABLE. After applied it to
Master branch, it returns some wired result when run the query in the first
time.
As you can see in the log below, after the first
On Fri, 6 Aug 2021 at 21:26, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
> >> Looks plausible by eyeball (I've not tested).
>
> > So, I have back-branch patches for this ready to go. The question is,
> > is it better to push now, or wait until after
Dean Rasheed writes:
> On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
>> Looks plausible by eyeball (I've not tested).
> So, I have back-branch patches for this ready to go. The question is,
> is it better to push now, or wait until after next week's releases?
I'd push now, given we have a
I wrote:
> I just came across this issue while preparing the release notes.
> ISTM that people have expended a great deal of effort on a fundamentally
> unreliable solution, when a reliable one is easily available.
Concretely, I propose the attached.
regards, tom lane
On Fri, 6 Aug 2021 at 17:15, Tom Lane wrote:
>
> > I guess the best thing to do is just test the value against
> > PG_INT32_MIN/MAX, which is what int84() does. There are 2 other places
> > in numeric.c that use similar code to check for int16/32 overflow, so
> > it's possible that they're broken
Daniel Gustafsson writes:
> Until there is an animal running OpenSSL 3.0.0 in the buildfarm I think this
> should be HEAD only. Further down the line we need to support OpenSSL 3 in
> all
> backbranches IMO since they are all equally likely to be compiled against it,
> but not until we can
> On 6 Aug 2021, at 21:01, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> Are you going to commit these?
Absolutely, a combination of unplanned home renovations and vacations changed
my plans a bit recently.
> Note that with release wraps scheduled for Monday, we are probably
> already past
Peter Eisentraut writes:
> Are you going to commit these?
Note that with release wraps scheduled for Monday, we are probably
already past the time when it'd be wise to push anything that has
a significant chance of introducing portability issues. There's
just not much time to deal with it if
I've pushed the first draft for $SUBJECT at
https://git.postgresql.org/pg/commitdiff/2f38ec6a157b60291ece1deb072bfff84f317334
Please send comments/corrections by Sunday.
regards, tom lane
On Fri, 6 Aug 2021 at 21:17, Dilip Kumar wrote:
>
> On Fri, Aug 6, 2021 at 8:53 PM Himanshu Upadhyaya
> wrote:
> >
> > Hi Sadhu,
> >
> > Patch working as expected with shared tables, just one Minor comment on the
> > patch.
> > + if (!dbentry)
> > + return;
> > +
> > +
On 20.07.21 01:23, Daniel Gustafsson wrote:
So I think your proposed patch is sound and a good short-term and low-risk
solution
The attached 0001 disables the padding. I've tested this with OpenSSL 1.0.1,
1.0.2, 1.1.1 and Git HEAD at e278127cbfa2709d.
Another aspect of OpenSSL 3
Hi,
Sorry for the late reply. Having read this thread, the problem is caused by
misunderstanding the AlterSubscription_refresh(). My apologies.
On Fri, 06 Aug 2021 at 14:12, Masahiko Sawada wrote:
> On Fri, Aug 6, 2021 at 1:39 PM Amit Kapila wrote:
>>
>> On Fri, Aug 6, 2021 at 5:09 AM
Dean Rasheed writes:
> So the "test for overflow by reverse-conversion" obviously isn't
> working as intended, and it's going through power_var_int() when it
> shouldn't. I don't think there's anything wrong with that code, so I
> think this is a compiler bug.
Yeah, looks like one.
> I guess
On Fri, 6 Aug 2021 at 03:58, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 5 Aug 2021 at 17:04, Tom Lane wrote:
> >> It looks like castoroides is not happy with this patch:
> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroides=2021-08-01%2008%3A52%3A43
>
> > Hmm,
On Fri, Aug 6, 2021 at 8:53 PM Himanshu Upadhyaya
wrote:
>
> Hi Sadhu,
>
> Patch working as expected with shared tables, just one Minor comment on the
> patch.
> + if (!dbentry)
> + return;
> +
> + /*
> +* We simply throw away all the shared table entries by
Hi Sadhu,
Patch working as expected with shared tables, just one Minor comment on the
patch.
+ if (!dbentry)
+ return;
+
+ /*
+* We simply throw away all the shared table entries by recreating
new
+* hash table for them.
+*/
+ if
Michael Paquier writes:
> On Wed, Jun 02, 2021 at 03:44:45PM +0530, Bharath Rupireddy wrote:
>> Thanks.The changes with that approach are very minimal. PSA v5 and let
>> me know if any more changes are needed.
> Simple enough, so applied and back-patched.
I just came across this issue while
On Thu, Aug 5, 2021 at 4:12 PM Andres Freund wrote:
> I have wondered before whether we should have syscache definitions
generate
> code specific to each syscache definition. I do think that'd give a good
bit
> of performance boost. But I don't see a trivial way to get there without
> notational
Hi Everyone,
I've ran into an issue where the OpenSSL API function "ssl_get_fd" fails, due
to the underlying BIO object created by Postgres is not being flagged properly.
Previous to OpenSSL version 1.1.0, the BIO methods object would be copied
directly from the existing socket type and then
Hi
Commit 6bf0bc842 replaced float.c's CHECKFLOATVAL() macro with static inline
subroutines,
but the fix introduced a performance regression as Tom Lane pointed out and
fixed at 607f8ce74.
Found obsolete CHECKFLOATVAL usage in contrib/btree_gist, and tried to fix it
according to 607f8ce74.
On Mon, Aug 2, 2021 at 7:20 PM Amit Kapila wrote:
>
> On Fri, Jul 23, 2021 at 3:39 PM Ajin Cherian wrote:
> >
>
> Let's first split the patch for prepared and non-prepared cases as
> that will help to focus on each of them separately.
As a first shot, I have split the patch into prepared and
On Fri, Aug 6, 2021 at 4:02 PM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 2:16 PM vignesh C wrote:
> >
> > On Thu, Aug 5, 2021 at 3:54 PM Amit Kapila wrote:
> > >
> > >
> > > Few more comments:
> > > ===
> > > 1. Do we need the previous column 'puballtables' after adding
On Wed, 4 Aug 2021 at 02:10, Tomas Vondra wrote:
> A review would be nice, although it can wait - It'd be interesting to
> know if those patches help with the workload(s) you've been looking at.
I tried out the v2 set of patches using the attached scripts. The
attached spreadsheet includes the
On 8/5/21 11:29 PM, Andres Freund wrote:
> Hi,
>
> When testing EXEC_BACKEND on linux I see occasional test failures as long as I
> don't disable ASLR. There's a code comment to that effect:
>
>* If testing EXEC_BACKEND on Linux, you should run this as root before
>* starting the
On Fri, 6 Aug 2021 at 17:40, Himanshu Upadhyaya
wrote:
>
> Hi Sadhu,
>
>
> > The call to “pg_stat_reset“ does reset all the statistics data for
> > tables belonging to the current database but does not take care of
> > shared tables e.g pg_attribute.
>
> pg_attribute is not a shared catalog, is
Hi Sadhu,
> The call to “pg_stat_reset“ does reset all the statistics data for
> tables belonging to the current database but does not take care of
> shared tables e.g pg_attribute.
pg_attribute is not a shared catalog, is the mentioned scenario is also
applicable for few others tables?
I have
On Fri, 6 Aug 2021 at 13:56, Sadhuprasad Patro wrote:
>
> Hi,
>
> The call to “pg_stat_reset“ does reset all the statistics data for
> tables belonging to the current database but does not take care of
> shared tables e.g pg_attribute. Similarly to reset the statistics at
> table level, the call
On Fri, Aug 6, 2021 at 2:02 PM vignesh C wrote:
>
> On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila wrote:
> >
> > On Tue, Aug 3, 2021 at 8:38 PM vignesh C wrote:
>
> > 6.
> > + {PublicationSchemaRelationId, /* PUBLICATIONSCHEMAMAP */
> > + PublicationSchemaPsnspcidPspubidIndexId,
> > + 2,
> > + {
>
On Fri, Aug 6, 2021 at 2:16 PM vignesh C wrote:
>
> On Thu, Aug 5, 2021 at 3:54 PM Amit Kapila wrote:
> >
> >
> > Few more comments:
> > ===
> > 1. Do we need the previous column 'puballtables' after adding pubtype
> > or pubkind in pg_publication?
>
> I felt this should be
Hi
I saw some inaccurate comments for AlterPublicationStmt structure when
reviewing patches related to publication[1].
The variable tables are used for 'ALTER PUBLICATION ... ADD/DROP/SET TABLE',
but the comments only say 'ADD/DROP'. How about add 'SET' to the comments?
typedef struct
On Thu, Aug 5, 2021 at 3:54 PM Amit Kapila wrote:
>
> On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila
wrote:
> >
> > On Tue, Aug 3, 2021 at 8:38 PM vignesh C wrote:
> > >
> > > Thanks for reporting this, this is fixed in the v18 patch attached.
> > >
> >
> > I have started looking into this patch
On Wed, Aug 4, 2021 at 8:08 PM tanghy.f...@fujitsu.com <
tanghy.f...@fujitsu.com> wrote:
>
> On Tuesday, August 3, 2021 11:08 PM vignesh C wrote:
> >
> > Thanks for reporting this, this is fixed in the v18 patch attached.
>
> Thanks for fixing it.
>
> Few suggestions for V18:
>
> 1.
> +# Clean up
Hi,
I have been working on analyzing the performance of sending the tuple
from workers to the Gather using the tuple queue. In the past there
were many off-list discussions around this area, basically, the main
point is that when the "shm_mq" was implemented that time maybe this
was one of the
On Wed, Aug 4, 2021 at 12:08 AM vignesh C wrote:
>
> On Tue, Aug 3, 2021 at 12:00 PM tanghy.f...@fujitsu.com
> wrote:
> >
> > On Monday, August 2, 2021 11:40 PM vignesh C wrote:
> > >
> > > Thanks for the comments, attached v17 patches has the fixes for the same.
> >
> > Thanks for your new
Hi,
The call to “pg_stat_reset“ does reset all the statistics data for
tables belonging to the current database but does not take care of
shared tables e.g pg_attribute. Similarly to reset the statistics at
table level, the call to “pg_stat_reset_single_table_counters“ does
not take care of
At Fri, 6 Aug 2021 00:21:34 +, "Bossart, Nathan"
wrote in
> On 8/5/21, 12:39 AM, "Kyotaro Horiguchi" wrote:
> > Honestly I don't like having this initialization in XLogWrite. We
> > should and I think can initialize it earlier. It seems to me the most
> > appropriate timing to initialize
On Fri, Aug 6, 2021 at 1:39 PM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 5:09 AM Masahiko Sawada wrote:
> >
> > On Thu, Aug 5, 2021 at 11:40 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > > To summary, I think that what we want to do in DROP SUBSCRIPTION cases
> > > > is to
> > > > drop
Hi,
On Thu, Aug 5, 2021, at 22:20, Yura Sokolov wrote:
> Andres Freund писал 2021-08-06 06:49:
> > Hi,
> >
> > On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
> >> Why don't use simplehash or something like that? Open-addressing
> >> schemes
> >> show superior cache locality.
> >
> > I
46 matches
Mail list logo
