Re: DELETE CASCADE

On Thu, 3 Jun 2021 at 18:08, David Christensen < david.christen...@crunchydata.com> wrote: > On Thu, Jun 3, 2021 at 4:15 PM Isaac Morland > wrote: > >> >> What happens if I don't have delete permission on the referencing table? >> When a foreign key reference delete cascades, I can cause records

Re: DELETE CASCADE

On Thu, 3 Jun 2021 at 18:25, David Christensen < david.christen...@crunchydata.com> wrote: > What happens if I don't have delete permission on the referencing table? >>> When a foreign key reference delete cascades, I can cause records to >>> disappear from a referencing table even if I don't have

checking return value from unlink in write_relcache_init_file

Hi, I was looking at write_relcache_init_file() where an attempt is made to unlink the tempfilename. However, the return value is not checked. If the tempfilename is not removed (the file exists), I think we should log a warning and proceed. Please comment on the proposed patch. Thanks check-u

Re: checking return value from unlink in write_relcache_init_file

On Thu, Jun 03, 2021 at 03:44:13PM -0700, Zhihong Yu wrote: > Hi, > I was looking at write_relcache_init_file() where an attempt is made to > unlink the tempfilename. > > However, the return value is not checked. > If the tempfilename is not removed (the file exists), I think we should log > a war

Re: checking return value from unlink in write_relcache_init_file

Zhihong Yu writes: > Please comment on the proposed patch. If the unlink fails, there's only really a problem if the subsequent open() fails to overwrite the file --- and that stanza is perfectly capable of complaining for itself. So I think the code is fine and there's no need for a separate me

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Tomas Vondra writes: > As mentioned in the previous message, I've reverted most of 39b66a91bd. Should this topic be removed from the open-items list now? regards, tom lane

Re: DELETE CASCADE

On Thu, Jun 3, 2021 at 3:29 PM Isaac Morland wrote: > Surely you mean if we don't have DELETE permission on the referencing > table? I don't see why we need to be a member of the table owner role. > I would reverse the question - why does this feature need to allow the more broad DELETE permissi

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

On Thu, Jun 03, 2021 at 12:04:48PM -0400, Alvaro Herrera wrote: > If the check for recompression is this expensive, then yeah I agree that > we should take it out. If recompression is actually occurring, then I > don't think this is a good test :-) I have done no recompression here, so I was just

Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path

Hi, thanks for the quick reply! From: Tomas Vondra Sent: Thursday, June 3, 2021 20:11 To: Arne Roland; pgsql-hackers Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path > I haven't tested the parallel case, but I think we should sort out (3) > get_cheapest_f

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

On Sun, 2020-09-13 at 19:04 +0300, Nikolay Shaplov wrote: > Moving reloptions to AM code is the goal I am slowly moving to. I've > started > some time ago with big patch > https://commitfest.postgresql.org/14/992/ and > have been told to split it into smaller parts. So I did, and this > patch is

Re: A few source files have the wrong copyright year

On Fri, 4 Jun 2021 at 00:16, David Rowley wrote: > I noticed earlier today when working in brin_minmax_multi.c that the > copyright year was incorrect. That caused me to wonder if any other > source files have the incorrect year. > The attached fixes. Pushed. David

Re: A few source files have the wrong copyright year

On Fri, Jun 04, 2021 at 12:21:16PM +1200, David Rowley wrote: > Pushed. Thanks. -- Michael signature.asc Description: PGP signature

Re: Documentation missing for PGSSLCRLDIR

On Thu, Jun 03, 2021 at 02:08:02PM +0200, Daniel Gustafsson wrote: > While looking at this I found another nearby oversight which needs a backport > down to 13 where it was introduced. The PGSSLMAXPROTOCOLVERSION documentation > is linking to the minimum protocol version docs. Fixed in the attach

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On 6/3/21 7:30 PM, Tom Lane wrote: > Tomas Vondra writes: >> As mentioned in the previous message, I've reverted most of 39b66a91bd. > Should this topic be removed from the open-items list now? > > Yep. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.

Re: Documentation missing for PGSSLCRLDIR

On Thu, Jun 03, 2021 at 01:42:20PM +0900, Kyotaro Horiguchi wrote: > Ugg.. Thanks for finding that. I don't find a similar mistake in the > same page. Thanks for double-checking. Applied. -- Michael signature.asc Description: PGP signature

Re: RFC: Table access methods and scans

Hi, On Wed, 2021-03-31 at 22:10 +0200, Mats Kindahl wrote: > As an example of how this is useful, I noticed the work by Heikki and > Ashwin [1], where they return a `TableScanDesc` that contains > information about what columns to scan, which looks very useful. > Since > the function `table_begins

Re: checking return value from unlink in write_relcache_init_file

On 2021-Jun-03, Tom Lane wrote: > If the unlink fails, there's only really a problem if the subsequent > open() fails to overwrite the file --- and that stanza is perfectly > capable of complaining for itself. So I think the code is fine and > there's no need for a separate message about the unli

Re: BUG #16079: Question Regarding the BUG #16064

On Thu, Jun 03, 2021 at 11:02:56AM -0700, Jeff Davis wrote: > My feeling after all of that discussion is that the next step would be > to move to some kind of negotiation between client and server about > which methods are mutually acceptable. Right now, the protocol is > structured around the serv

Re: checking return value from unlink in write_relcache_init_file

Alvaro Herrera writes: > On 2021-Jun-03, Tom Lane wrote: >> If the unlink fails, there's only really a problem if the subsequent >> open() fails to overwrite the file --- and that stanza is perfectly >> capable of complaining for itself. So I think the code is fine and >> there's no need for a se

Re: checking return value from unlink in write_relcache_init_file

On Thu, Jun 3, 2021 at 6:16 PM Tom Lane wrote: > Alvaro Herrera writes: > > On 2021-Jun-03, Tom Lane wrote: > >> If the unlink fails, there's only really a problem if the subsequent > >> open() fails to overwrite the file --- and that stanza is perfectly > >> capable of complaining for itself.

RE: [BUG]Update Toast data failure in logical replication

On Thu, Jun 3, 2021 7:45 PMDilip Kumar wrote: > > I have fixed all the pending issues, I see there is already a test > case for this so I have changed the output for that. Thanks for your patch. I tested it for all branches(10,11,12,13,HEAD) and all of them passed.(This bug was introduced in PG

Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command

On Thu, Jun 3, 2021 at 10:08 PM Jeff Davis wrote: > > On Thu, 2021-06-03 at 09:29 +0530, Amit Kapila wrote: > > The idea is to support two_phase via protocol with a subscriber-side > > work where we can test it as well. The code to support it via > > replication protocol is present in the first pa

Re: Transactions involving multiple postgres foreign servers, take 2

On Thu, Jun 3, 2021 at 1:56 PM Masahiro Ikeda wrote: > > > > On 2021/05/25 21:59, Masahiko Sawada wrote: > > On Fri, May 21, 2021 at 5:48 PM Masahiro Ikeda > > wrote: > >> > >> On 2021/05/21 13:45, Masahiko Sawada wrote: > >>> > >>> Yes. We also might need to be careful about the order of foreig

Re: [BUG]Update Toast data failure in logical replication

On Fri, Jun 4, 2021 at 8:25 AM tanghy.f...@fujitsu.com wrote: > > On Thu, Jun 3, 2021 7:45 PMDilip Kumar wrote: > > > > I have fixed all the pending issues, I see there is already a test > > case for this so I have changed the output for that. > > Thanks for your patch. I tested it for all branch

Re: Are we missing (void) when return value of fsm_set_and_search is ignored?

On Thu, Jun 03, 2021 at 02:57:42PM +0200, Peter Eisentraut wrote: > On 03.06.21 12:54, Bharath Rupireddy wrote: > > It looks like for some of the fsm_set_and_search calls whose return > > value is ignored (in fsm_search and RecordPageWithFreeSpace), there's > > no (void). Is it intentional? In the

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

On Fri, Jun 04, 2021 at 08:54:48AM +0900, Michael Paquier wrote: > I have done no recompression here, so I was just stressing the extra > test for the recompression. Sorry for the confusion. I am not sure yet which way we are going, but cleaning up this code involves a couple of things: - Clean u

Re: alter table set TABLE ACCESS METHOD

On Thu, Jun 03, 2021 at 02:36:15PM -0700, Jeff Davis wrote: > Do we have general agreement on this point? Did I miss another purpose > of detoasting in tablecmds.c, or can we just remove that part of the > patch? Catching up with this thread.. So, what you are suggesting here is that we have no n

Re: Teaching users how they can get the most out of HOT in Postgres 14

On Mon, May 31, 2021 at 10:30:08AM +0900, Masahiko Sawada wrote: > On Fri, May 28, 2021 at 9:53 AM Peter Geoghegan wrote: >> Another concern with this approach is what it >> means for the VACUUM command itself. I haven't added an 'auto' >> spelling that is accepted by the VACUUM command in this PO

Re: RFC: Table access methods and scans

Hi Jeff, On Fri, Jun 4, 2021 at 2:52 AM Jeff Davis wrote: > Hi, > > On Wed, 2021-03-31 at 22:10 +0200, Mats Kindahl wrote: > > As an example of how this is useful, I noticed the work by Heikki and > > Ashwin [1], where they return a `TableScanDesc` that contains > > information about what column

Re: security_definer_search_path GUC

On Thu, Jun 3, 2021, at 20:42, Isaac Morland wrote: > I also want to mention that I consider any suggestion to eliminate the > search_path concept as a complete non-starter. > > It would be no different from proposing that the next version of a > programming language eliminate (or stop using) th

Re: Make unlogged table resets detectable

On 03/06/2021 23:04, Jeff Davis wrote: One problem with unlogged tables is that the application has no way to tell if they were reset, or they just happen to be empty. This can be a problem with sharding, where you might have different shards of an unlogged table on different servers. If one ser

Re: security_definer_search_path GUC

Hi > > I realise "eliminate" is not really necessary, it would suffice to just > allow setting a a sane default per database, and make that value immutable, > then all data structures and code using wouldn't need to change, one would > then only need to change the code that can mutate search_path

Re: Transactions involving multiple postgres foreign servers, take 2

> 2021/06/04 12:28、Masahiko Sawada のメール: > > On Thu, Jun 3, 2021 at 1:56 PM Masahiro Ikeda > wrote: >> >> >> >> On 2021/05/25 21:59, Masahiko Sawada wrote: >>> On Fri, May 21, 2021 at 5:48 PM Masahiro Ikeda >>> wrote: On 2021/05/21 13:45, Masahik

<    1   2