On Thu, Oct 28, 2021 at 04:52:48PM -0700, Andres Freund wrote:
> I suspect the reverse lock order release could be tad faster. But I probably
> wouldn't change it either - I was more thinking of some of the other cases
> that deleted the first element, here it's a bit harder to know wether there's
On Friday, October 29, 2021 12:35 PM, Amit Kapila
wrote:
>
> On Thu, Oct 28, 2021 at 9:55 AM vignesh C wrote:
> >
> > Thanks for committing the patch, please find the remaining patches attached.
> > Thanks Hou Zhijie and Greg Nancarrow for sharing a few comments
> > offline, I have fixed those
On Thu, Oct 28, 2021 at 7:47 PM vignesh C wrote:
>
> On Thu, Oct 21, 2021 at 10:30 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Oct 20, 2021 at 12:33 PM Greg Nancarrow wrote:
> > >
> > > On Mon, Oct 18, 2021 at 12:34 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > I've attached updated patches
On Thu, Oct 28, 2021 at 7:40 PM Amit Kapila wrote:
>
> On Thu, Oct 28, 2021 at 10:36 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Oct 27, 2021 at 7:02 PM Amit Kapila wrote:
> > >
> > > On Thu, Oct 21, 2021 at 10:29 AM Masahiko Sawada
> > > wrote:
> > > >
> > > >
> > > > I've attached updated p
Hi all,
Since 911e702 (13~), it is possible to define opclass parameters for
index attributes as of CREATE INDEX, but we lack an equivalent grammar
for ALTER INDEX. I was looking at that, and it seems natural to me to
do the same thing as what we do for SET STATISTICS, where we use a
column numbe
On Thu, Oct 28, 2021 at 9:55 AM vignesh C wrote:
>
> Thanks for committing the patch, please find the remaining patches attached.
> Thanks Hou Zhijie and Greg Nancarrow for sharing a few comments
> offline, I have fixed those in the attached patch.
>
Pushed the first test case patch. About
v48-00
On Fri, Oct 29, 2021 at 2:36 AM Robert Haas wrote:
>
> On Thu, Oct 28, 2021 at 3:52 PM Bossart, Nathan wrote:
> > When I apply the patch, it changes the PANIC message in the
> > XLOG_CHECKPOINT_ONLINE section, not the XLOG_END_OF_RECOVERY one.
>
> Well that's a good point. *facepalm*
>
Oops... :
On Tue, Oct 5, 2021 at 4:21 PM Thomas Munro wrote:
> On Thu, Sep 30, 2021 at 11:32 PM Thomas Munro wrote:
> > I managed to produce a case where live data is written to an unlinked
> > file and lost
In conclusion, there *is* something else that would break, so I'm
withdrawing this CF entry (#3030
On Sun, Oct 24, 2021 at 10:50 PM Thomas Munro wrote:
> Sadly, although the attached proof-of-concept patch allows a
> PREFERRED_SEMAPHORES=FUTEX build to pass tests on macOS (which also
> lacks native unnamed semas), FreeBSD and Linux (which don't need this
> but are interesting to test), and it a
On Thu, Oct 28, 2021 at 3:25 PM vignesh C wrote:
>
> Thanks for committing the patch, please find the remaining patches attached.
A few comments on the v48-0002 patch:
(1) The quoting of TABLE/SCHEMA looks a bit odd in the patch comment
(2) src/backend/catalog/system_views.sq
ON should be capit
On Thu, Oct 28, 2021 at 03:55:12PM +0200, Ronan Dunklau wrote:
> Interesting ideas, thanks. For the record, the time drops from ~4.5s to 3s on
> average on my machine.
> I think if you reduce the size of the generate_series batches, this should
> probably be reduced everywhere. With what we do t
On 2021-10-29 01:14, Tom Lane wrote:
Mark Dilger writes:
The only intentional backward compatibility break in this patch set is
the the behavior of CREATEROLE. The general hope is that such a
compatibility break will help far more than it hurts, as CREATEROLE
does not appear to be a well ado
On Thu, Oct 28, 2021 at 09:25:43AM +0530, Amul Sul wrote:
> Thanks a lot, Michael.
So.. The buildfarm members running on Windows and running the
recovery tests are jacana (MinGW) and fairywren (Msys), both reporting
green. drongo (MSVC) skips those tests, but I have tested MSVC by
myself so I th
At Thu, 28 Oct 2021 11:39:52 -0400, Robert Haas wrote
in
> I previously reported[1] that CreateReplicationSlot() was accessing
> the global variable ThisTimeLineID when it might not be initialized.
> Today I realized that the code in basebackup.c has the same problem.
> perform_base_backup() bli
On Thu, Oct 28, 2021 at 6:34 PM Amit Kapila wrote:
>
> On Thu, Oct 28, 2021 at 10:56 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Oct 28, 2021 at 1:29 PM Amit Kapila wrote:
> > >
> > > On Wed, Oct 27, 2021 at 4:07 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Oct 27, 2021 at 8:32 AM Masa
On Thu, Oct 28, 2021 at 5:07 PM Andres Freund wrote:
> > I think that, in order to have
> > any chance of being acceptable, this would need to be restructured so
> > that it pulls data from an existing relcache entry that is known to be
> > valid, without attempting to create a new one. That is,
>
Hi,
On 2021-10-28 19:24:08 -0400, Tom Lane wrote:
> "Bossart, Nathan" writes:
> > On 10/28/21, 3:25 PM, "Tom Lane" wrote:
> >> Does it matter what order we're releasing the locks in?
>
> > I'm not seeing anything that indicates the ordering matters. AFAICT
> > either approach would work in thi
"Bossart, Nathan" writes:
> On 10/28/21, 3:25 PM, "Tom Lane" wrote:
>> Does it matter what order we're releasing the locks in?
> I'm not seeing anything that indicates the ordering matters. AFAICT
> either approach would work in this case. IMO changing the order is
> scarier than switching to
On 10/28/21, 3:25 PM, "Tom Lane" wrote:
> Andres Freund writes:
>> Which leads to to wonder whether the better fix would be to switch to
>> deleting
>> the last element, but still use the while (!empty) style. That should convert
>> the O(n^2) due to 1cff1b9 back to O(n). It might or might not b
The docs have said this for 8 years:
| "As of PostgreSQL 9.3, complete coverage exists only for errors in SQLSTATE
class 23 (integrity constraint violation), but this is likely to be expanded in
future."
Is there any appetite for a patch like this one to improve that ?
One might argue that COLU
On 10/28/21, 3:15 PM, "Andres Freund" wrote:
> Which leads to to wonder whether the better fix would be to switch to deleting
> the last element, but still use the while (!empty) style. That should convert
> the O(n^2) due to 1cff1b9 back to O(n). It might or might not be faster/slower
> than usin
Andres Freund writes:
> Which leads to to wonder whether the better fix would be to switch to deleting
> the last element, but still use the while (!empty) style. That should convert
> the O(n^2) due to 1cff1b9 back to O(n). It might or might not be faster/slower
> than using foreach(), but it sho
Hi,
On 2021-10-28 15:07:48 -0700, Andres Freund wrote:
> On 2021-10-28 15:57:51 +0900, Kyotaro Horiguchi wrote:
> > I found several other instances of the pattern
> > "while(list){list_delete_first(); /*no-break*/}" in
> > llvm_release_context, gistProcessEmptyingQueue, AtEOXact_Namespace and
> >
Hi,
On 2021-10-28 15:57:51 +0900, Kyotaro Horiguchi wrote:
> I found several other instances of the pattern
> "while(list){list_delete_first(); /*no-break*/}" in
> llvm_release_context, gistProcessEmptyingQueue, AtEOXact_Namespace and
> maybe transformGraph and processState in trgm_regexp.c. We m
Hi,
On Wed, Oct 27, 2021 at 06:39:46AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> Thank you for your comment.
> The attached patch stops message splitting.
> This patch also limits the timing of message output when huge_pages = try and
> HugePages is not used.
Thanks for updating the pa
On Thu, Oct 28, 2021 at 2:19 PM David Rowley wrote:
> On Fri, 29 Oct 2021 at 04:43, Zhihong Yu wrote:
> > I noticed that the dummy relation is skipped in the loop over
> rel->live_parts.
> > I wonder if the following change is sensible.
>
> I made the definition of live_parts to be partitions th
On Fri, 29 Oct 2021 at 04:43, Zhihong Yu wrote:
> I noticed that the dummy relation is skipped in the loop over rel->live_parts.
> I wonder if the following change is sensible.
I made the definition of live_parts to be partitions that survived
partition pruning. There's a few reasons why a RELOP
Hi,
On 2021-10-28 16:24:22 -0400, Robert Haas wrote:
> On Wed, Oct 27, 2021 at 2:56 AM Drouvot, Bertrand wrote:
> > So you have in mind to check for XLogLogicalInfoActive() first, and if
> > true, then open the relation and call
> > RelationIsAccessibleInLogicalDecoding()?
>
> I think 0001 is u
On Thu, Oct 28, 2021 at 3:52 PM Bossart, Nathan wrote:
> When I apply the patch, it changes the PANIC message in the
> XLOG_CHECKPOINT_ONLINE section, not the XLOG_END_OF_RECOVERY one.
Well that's a good point. *facepalm*
--
Robert Haas
EDB: http://www.enterprisedb.com
Andres Freund writes:
> Imo the code now is a bit odd, because we first switch (type) setting base,
> and then separately have branches for the different bases.
It'd be hard to merge, I think, given that the cases in the switch
don't line up one-for-one with the different bases. You could
probab
Hi,
On 2021-10-28 13:46:49 -0400, Tom Lane wrote:
> Personally, I failed to measure any speedup at all on pgbench, either
> in the init phase or regular transactions; whatever difference there
> may be is below the noise level. However, I wrote a simple C function
> with a tight loop around snpri
On Wed, Oct 27, 2021 at 2:56 AM Drouvot, Bertrand wrote:
> So you have in mind to check for XLogLogicalInfoActive() first, and if true,
> then open the relation and call
> RelationIsAccessibleInLogicalDecoding()?
I think 0001 is utterly unacceptable. We cannot add calls to
table_open() in low-le
On 10/28/21, 12:52 PM, "Bossart, Nathan" wrote:
> On 10/28/21, 12:23 PM, "Robert Haas" wrote:
>> On Thu, Oct 28, 2021 at 8:59 AM Amul Sul wrote:
>>> In xlog_redo, for end-of-recovery case error message describes the
>>> record as a checkpoint record which seems to be incorrect; the
>>> attached
On 10/28/21, 12:23 PM, "Robert Haas" wrote:
> On Thu, Oct 28, 2021 at 8:59 AM Amul Sul wrote:
>> In xlog_redo, for end-of-recovery case error message describes the
>> record as a checkpoint record which seems to be incorrect; the
>> attached patch corrects that.
>
> The analysis and patch appear
Thank you Asif. A rebased patch is attached.
On Thu, Oct 28, 2021 at 11:04 AM Asif Rehman wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Docum
On Thu, Oct 28, 2021 at 8:59 AM Amul Sul wrote:
> In xlog_redo, for end-of-recovery case error message describes the
> record as a checkpoint record which seems to be incorrect; the
> attached patch corrects that.
The analysis and patch appear correct to me.
--
Robert Haas
EDB: http://www.enter
On Mon, Oct 25, 2021 at 11:56 AM Robert Haas wrote:
> This version looks fine, so I have committed it (and my
> enable_timeout_every patch also, as a necessary prerequisite).
I was fooling around with a test setup today, working on an unrelated
problem, and this happened:
2021-10-28 14:21:23.145
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
The patch does not apply on HEAD anymore. Looks like it needs to be rebased.
> On Oct 27, 2021, at 1:10 PM, Robert Haas wrote:
>
> This is effectively the same thing as Mark's proposal, but just using
> a new kind of object (TENANT) where Mark used an existing kind of
> object (ROLE). And it addresses Noah's concern, perhaps, because with
> the approach the tenant admi
Chapman Flack writes:
> On 10/27/21 18:18, Arjan van de Ven wrote:
>> +/*
>> + * Special case each of the possible base values (8, 10, 16) to
>> avoid an
>> + * expensive divide operation
>> + * (the compiler will use a multiply, shift or boolean ops for this)
>> +
On 10/28/21, 12:58 AM, "Michael Paquier" wrote:
> On Thu, Oct 28, 2021 at 03:57:51PM +0900, Kyotaro Horiguchi wrote:
>> However, I'm fine with fixing only StandbyRelaseLockList(), which
>> actually suffers from list_delete_first().
>
> I can also see a large gap between one technique and the other
On Thu, Oct 28, 2021 at 12:02:30PM -0400, Chapman Flack wrote:
> On 10/28/21 10:37, Bruce Momjian wrote:
>
> > I know of no plans to implement 64-bit transaction ids in community
> > Postgres because of the longer tuple header and file format changes.
> > It is discussed occasionally though.
>
>
Mark Dilger writes:
> The only intentional backward compatibility break in this patch set is the
> the behavior of CREATEROLE. The general hope is that such a compatibility
> break will help far more than it hurts, as CREATEROLE does not appear to be a
> well adopted feature. I would expect t
On 10/28/21 10:37, Bruce Momjian wrote:
> I know of no plans to implement 64-bit transaction ids in community
> Postgres because of the longer tuple header and file format changes.
> It is discussed occasionally though.
Is there anything you can use a SubTransactionId for outside of C code?
PL/J
Le 28/10/2021 à 16:31, Bruce Momjian a écrit :
> On Thu, Oct 28, 2021 at 11:30:27AM +0200, Gilles Darold wrote:
>> Fixed with new patch version v7 attached. It also fixes unwanted change
>> of some regression tests output reported by the cfbot because I forgot
>> to change my locale.
>>
>>
>> I wil
Hi,
I was looking at:
commit 475dbd0b718de8ac44da144f934651b959e3b705
Author: David Rowley
Date: Tue Aug 3 11:47:24 2021 +1200
Track a Bitmapset of non-pruned partitions in RelOptInfo
I noticed that the dummy relation is skipped in the loop
over rel->live_parts.
I wonder if the following
I previously reported[1] that CreateReplicationSlot() was accessing
the global variable ThisTimeLineID when it might not be initialized.
Today I realized that the code in basebackup.c has the same problem.
perform_base_backup() blithely uses the variable six times without
doing anything at all to i
> On Oct 27, 2021, at 7:32 PM, Shinya Kato
> wrote:
>
> I was able to add the membership of a role with a different owner.
> In brief, "a" was able to change the membership of owner "shinya".
> Is this the correct behavior?
I believe it is required for backwards compatibility. In a green fi
> On 26 Oct 2021, at 21:31, Mahendra Singh Thalor wrote:
> I took v3[1] patch from this thread and re-based on commit
> head(5fedf7417b69295294b154a21).
>
> Please find the attached patch for review.
Cool! There is a Commitfest starting soon, as the previous entry was closed
you need to open
On Thu, Oct 28, 2021 at 10:29:52AM -0400, Chapman Flack wrote:
> Hi,
>
> According to a reported PL/Java issue [0], SubTransactionId in
> Postgres PRO EE 13 has become a typedef uint64 rather than uint32.
>
> What are the plans for this type upstream? I notice it is still uint32
> here, even for
On Thu, Oct 28, 2021 at 11:30:27AM +0200, Gilles Darold wrote:
> Fixed with new patch version v7 attached. It also fixes unwanted change
> of some regression tests output reported by the cfbot because I forgot
> to change my locale.
>
>
> I will also add a pg_dump test to verify that ALTER ... SE
Hi,
According to a reported PL/Java issue [0], SubTransactionId in
Postgres PRO EE 13 has become a typedef uint64 rather than uint32.
What are the plans for this type upstream? I notice it is still uint32
here, even for 14. Are there plans for it to become uint64 at some point?
Or to become somet
On Thursday, October 21, 2021 10:19 AM Masahiko Sawada
wrote:
> On Mon, Oct 18, 2021 at 7:03 PM Amit Kapila
> wrote:
> >
> > On Thu, Oct 14, 2021 at 9:23 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > On Thursday, September 30, 2021 12:15 PM Amit Kapila
> > >
> > > >
> > > > These all views
Le jeudi 28 octobre 2021, 14:31:36 CEST Michael Paquier a écrit :
> On Wed, Oct 27, 2021 at 10:11:00AM +0200, Ronan Dunklau wrote:
> > Sorry I sent an intermediary version of the patch, here is the correct
> > one.
>
> While looking at this patch, I have figured out a simple way to make
> the test
Hi,
I stumbled across a few places that depend on the inheritance appends being
applied at a later date, so I quickly abandoned that idea. I thought a bit
about the indexlist, in particular the inhparent, and I am not sure what
depends on get_relation_info working in that way.
Therefore I pr
On 10/22/21 11:41 AM, David Steele wrote:
I noticed recently that permissions checking is done differently for the
server certificate key than the client key. Specifically, on the server
the key can have 640 perms if it is owned by root.
On the server side this change was made in 9a83564c an
Hi,
In xlog_redo, for end-of-recovery case error message describes the
record as a checkpoint record which seems to be incorrect; the
attached patch corrects that.
--
Regards,
Amul Sul
EDB: http://www.enterprisedb.com
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlo
On Thu, Oct 28, 2021 at 12:41 PM Masahiko Sawada wrote:
>
> On Thu, Oct 28, 2021 at 11:44 AM Bharath Rupireddy
> wrote:
> >
> > On Thu, Oct 28, 2021 at 7:11 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Wed, 27 Oct 2021 14:26:11 -0500, Justin Pryzby
> > > wrote in
> > > > On Wed, Oct 27, 2021
On Wed, Oct 27, 2021 at 10:11:00AM +0200, Ronan Dunklau wrote:
> Sorry I sent an intermediary version of the patch, here is the correct one.
While looking at this patch, I have figured out a simple way to make
the tests faster without impacting the coverage. The size of the WAL
segments archived
On Thu, Oct 21, 2021 at 10:30 AM Masahiko Sawada wrote:
>
> On Wed, Oct 20, 2021 at 12:33 PM Greg Nancarrow wrote:
> >
> > On Mon, Oct 18, 2021 at 12:34 PM Masahiko Sawada
> > wrote:
> > >
> > > I've attached updated patches that incorporate all comments I got so far.
> > >
> >
> > Minor commen
On Thu, Oct 28, 2021 at 10:36 AM Masahiko Sawada wrote:
>
> On Wed, Oct 27, 2021 at 7:02 PM Amit Kapila wrote:
> >
> > On Thu, Oct 21, 2021 at 10:29 AM Masahiko Sawada
> > wrote:
> > >
> > >
> > > I've attached updated patches.
>
> Thank you for the comments!
>
> >
> > Few comments:
> > ===
Thanks, the "group by" is fixed
Yet another crash (on v58 patches), reproduced with:
psql -t -c "create global temp table t(b text)
with(on_commit_delete_rows=true); create index idx_b on t (b); insert into
t values('test'); alter table t alter b type varchar;"
server closed the connection unexpe
On Thu, Oct 28, 2021 at 10:48 AM Masahiko Sawada wrote:
>
> On Thu, Oct 28, 2021 at 1:05 PM Amit Kapila wrote:
> >
> > On Thu, Oct 28, 2021 at 7:49 AM Masahiko Sawada
> > wrote:
> > >
> > > >
> > > > Either from the error messages in the server log or from the new view
> > > > we are planning t
On Thu, Oct 28, 2021 at 10:56 AM Masahiko Sawada wrote:
>
> On Thu, Oct 28, 2021 at 1:29 PM Amit Kapila wrote:
> >
> > On Wed, Oct 27, 2021 at 4:07 PM Amit Kapila wrote:
> > >
> > > On Wed, Oct 27, 2021 at 8:32 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, Oct 26, 2021 at 7:29 PM Ami
On Thu, Oct 28, 2021 at 4:35 PM houzj.f...@fujitsu.com
wrote:
> As there are basically two separate issues mentioned in the thread, I tried to
> summarize the discussion so far which might be helpful to others.
>
> * The first issue[1]:
>
> If we include both the partitioned table and (explicitly)
On Thu, Oct 28, 2021 at 03:57:51PM +0900, Kyotaro Horiguchi wrote:
> I found several other instances of the pattern
> "while(list){list_delete_first(); /*no-break*/}" in
> llvm_release_context, gistProcessEmptyingQueue, AtEOXact_Namespace and
> maybe transformGraph and processState in trgm_regexp.c
Hi,
As there are basically two separate issues mentioned in the thread, I tried to
summarize the discussion so far which might be helpful to others.
* The first issue[1]:
If we include both the partitioned table and (explicitly) its child partitions
in the publication when set publish_via_partit
Op 27-10-2021 om 18:02 schreef Gilles Darold:
Otherwise, build, make check, chekc-world are OK. Also the pdf builds
ok.
Thanks Erik, new version v6 attached.
Hi,
Anther small thing: the test_decoding module was overlooked, I think.
Below is output from make check-world (this error does no
On Thu, Oct 28, 2021 at 11:44 AM Bharath Rupireddy
wrote:
>
> On Thu, Oct 28, 2021 at 7:11 AM Kyotaro Horiguchi
> wrote:
> >
> > At Wed, 27 Oct 2021 14:26:11 -0500, Justin Pryzby
> > wrote in
> > > On Wed, Oct 27, 2021 at 07:05:10PM +, Bossart, Nathan wrote:
> > > > My vote is to just chang
69 matches
Mail list logo
