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

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: 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

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: 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: 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: 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: 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: 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: [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: 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: 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: [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: 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: 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: 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

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: 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: 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: 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 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: 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: 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: [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: 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: 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: 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: 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: 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: 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

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: 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

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

> > 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 delete permission >> on that table. This feels like it's just supposed to be a convenience

Re: DELETE CASCADE

On Thu, Jun 3, 2021 at 4:15 PM Isaac Morland wrote: > On Thu, 3 Jun 2021 at 16:49, David Christensen < > david.christen...@crunchydata.com> wrote: > >> Hi -hackers, >> >> Presented for discussion is a POC for a DELETE CASCADE functionality, >> which will allow you one-shot usage of treating exist

Re: DELETE CASCADE

On Thu, Jun 3, 2021 at 4:48 PM David G. Johnston wrote: > On Thu, Jun 3, 2021 at 1:49 PM David Christensen < > david.christen...@crunchydata.com> wrote: > >> Presented for discussion is a POC for a DELETE CASCADE functionality, >> which will allow you one-shot usage of treating existing NO ACTION

Re: CALL versus procedures with output-only arguments

Peter Eisentraut writes: > On 03.06.21 22:21, Tom Lane wrote: >> An example is that (AFAICT) the spec allows having both >> create procedure divide(x int, y int, OUT q int) ... >> create procedure divide(x int, y int, OUT q int, OUT r int) ... >> which I want to reject because they have

Re: DELETE CASCADE

On Thu, Jun 3, 2021 at 1:49 PM David Christensen < david.christen...@crunchydata.com> wrote: > Presented for discussion is a POC for a DELETE CASCADE functionality, > which will allow you one-shot usage of treating existing NO ACTION and > RESTRICT FK constraints as if they were originally defined

Re: CALL versus procedures with output-only arguments

On 03.06.21 22:21, Tom Lane wrote: Once you do, you'll possibly notice that PG's rules for which combinations of signatures are allowed are different from the spec's. I believe that we're largely more generous than the spec, but there are a few cases where this proposal isn't. An example is tha

Re: alter table set TABLE ACCESS METHOD

On Thu, 2021-05-06 at 17:24 -0700, Jeff Davis wrote: > It's the table AM's responsibility to detoast out-of-line datums and > toast any values that are too large (see > heapam.c:heap_prepare_insert()). Do we have general agreement on this point? Did I miss another purpose of detoasting in tablecmd

Re: CALL versus procedures with output-only arguments

Peter Eisentraut writes: > On 02.06.21 02:04, Tom Lane wrote: >> Hmm, actually we could make step 2 a shade tighter: if a candidate >> routine is a function, match against proargtypes. If it's a procedure, >> match against coalesce(proallargtypes, proargtypes). If we find >> multiple matches, ra

Re: CALL versus procedures with output-only arguments

On 6/3/21 4:50 PM, Tom Lane wrote: > Andrew Dunstan writes: >> Not sure I follow the "other datatypes" bit. Are you saying the spec >> won't let you have this?: >> create procedure divide(x int, y int, OUT q int); >> create procedure divide(x int, y int, OUT q float); > In fact it won't,

Re: DELETE CASCADE

On Thu, 3 Jun 2021 at 16:49, David Christensen < david.christen...@crunchydata.com> wrote: > Hi -hackers, > > Presented for discussion is a POC for a DELETE CASCADE functionality, > which will allow you one-shot usage of treating existing NO ACTION and > RESTRICT FK constraints as if they were ori

Re: Support for NSS as a libpq TLS backend

> On 3 Jun 2021, at 23:11, Tom Lane wrote: > > Bruce Momjian writes: >> I wonder if we should use SSL/TLS in more places in our documentation. > > No objection to doing that in the docs; I'm just questioning > switching the code-visible names. As long as it's still searchable by "SSL", "TLS" a

Re: CALL versus procedures with output-only arguments

On 02.06.21 02:04, Tom Lane wrote: I wrote: It's possible that we could revert proargtypes and still accommodate the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining some rules along the line of: 1. If arg list contains any parameter modes, then it must be PG syntax, so interpr

Re: Support for NSS as a libpq TLS backend

Bruce Momjian writes: > I wonder if we should use SSL/TLS in more places in our documentation. No objection to doing that in the docs; I'm just questioning switching the code-visible names. regards, tom lane

Re: pgsql: Add regression test for recovery pause.

On 6/3/21 4:45 PM, Tom Lane wrote: > Andrew Dunstan writes: >> My suspicion was correct. Fix pushed. > Great, thanks. > > Do we need to worry about back-patching that? It seems only > accidental if no existing back-branch test cases hit this. Well, we haven't had breakage, but its also useful

Re: Support for NSS as a libpq TLS backend

On Thu, Jun 3, 2021 at 04:55:45PM -0400, Tom Lane wrote: > Daniel Gustafsson writes: > > It might also put us a hard spot if the next TLS spec ends up being called > > something other than TLS? It's clearly happened before =) > > Good point. I'm inclined to just stick with the SSL terminology.

Re: Support for NSS as a libpq TLS backend

> On 3 Jun 2021, at 22:55, Tom Lane wrote: >>> Also, do we have precedent for GUC aliases? That might be a little >>> weird. > >> I don't think we do currently, but I have a feeling the topic has surfaced >> here >> before. > > We do, look for "sort_mem" in guc.c. I knew it seemed familiar bu

Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path

On 6/3/21 10:52 PM, Zhihong Yu wrote: > ... > > Sent a bit too soon. > > The above function still exists. > But startup_new_fractional was nowhere to be found. Actually, there are two comments /* XXX maybe we should have startup_new_fractional? */ in the patch I posted - I completely f

Re: Support for NSS as a libpq TLS backend

Daniel Gustafsson writes: > It might also put us a hard spot if the next TLS spec ends up being called > something other than TLS? It's clearly happened before =) Good point. I'm inclined to just stick with the SSL terminology. >> Also, do we have precedent for GUC aliases? That might be a lit

Re: CALL versus procedures with output-only arguments

Andrew Dunstan writes: > Not sure I follow the "other datatypes" bit. Are you saying the spec > won't let you have this?: > create procedure divide(x int, y int, OUT q int); > create procedure divide(x int, y int, OUT q float); In fact it won't, because the spec's rule is simply "you can

DELETE CASCADE

Hi -hackers, Presented for discussion is a POC for a DELETE CASCADE functionality, which will allow you one-shot usage of treating existing NO ACTION and RESTRICT FK constraints as if they were originally defined as CASCADE constraints. I can't tell you how many times this functionality would hav

Re: Support for NSS as a libpq TLS backend

> On 3 Jun 2021, at 22:14, Jeff Davis wrote: > > On Thu, 2021-06-03 at 15:53 -0400, Andrew Dunstan wrote: >> Yeah, but it's annoying to have to start every talk I give touching >> this >> subject with the slide that says "When we say SSL we really means >> TLS". >> Maybe release 15 would be a goo

Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path

On Thu, Jun 3, 2021 at 1:50 PM Zhihong Yu wrote: > > > On Thu, Jun 3, 2021 at 11:12 AM Tomas Vondra < > tomas.von...@enterprisedb.com> wrote: > >> Hi, >> >> On 6/3/21 7:17 PM, Arne Roland wrote: >> > Hi, >> > >> > >> > I haven't tested the parallel case, but I think we should sort out (3) >> > ge

Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path

On Thu, Jun 3, 2021 at 11:12 AM Tomas Vondra wrote: > Hi, > > On 6/3/21 7:17 PM, Arne Roland wrote: > > Hi, > > > > > > I haven't tested the parallel case, but I think we should sort out (3) > > get_cheapest_fractional_path_for_pathkeys as mentioned above. > > > > Not sure what you refer to by "a

Re: pgsql: Add regression test for recovery pause.

Andrew Dunstan writes: > My suspicion was correct. Fix pushed. Great, thanks. Do we need to worry about back-patching that? It seems only accidental if no existing back-branch test cases hit this. regards, tom lane

Re: pgsql: Add regression test for recovery pause.

On 6/2/21 6:25 PM, Andrew Dunstan wrote: > > > Looks to me like we're getting munged by the msys shell, and unlike on > msys2 there isn't a way to disable it: > https://stackoverflow.com/questions/7250130/how-to-stop-mingw-and-msys-from-mangling-path-names-given-at-the-command-line > > > c.f. com

Re: CALL versus procedures with output-only arguments

On 6/3/21 4:21 PM, Tom Lane wrote: > Andrew Dunstan writes: >> So AIUI your suggestion is that ALTER/DROP ROUTINE will look for an >> ambiguity. If it doesn't find one it proceeds, otherwise it complains in >> which case the user will have to fall back to ALTER/DROP >> FUNCTION/PROCEDURE. Is tha

Re: Race condition in recovery?

On Thu, May 27, 2021 at 2:26 AM Dilip Kumar wrote: > Changed as suggested. I don't think the code as written here is going to work on Windows, because your code doesn't duplicate enable_restoring's call to perl2host or its backslash-escaping logic. It would really be better if we could use enable

Re: CALL versus procedures with output-only arguments

Andrew Dunstan writes: > So AIUI your suggestion is that ALTER/DROP ROUTINE will look for an > ambiguity. If it doesn't find one it proceeds, otherwise it complains in > which case the user will have to fall back to ALTER/DROP > FUNCTION/PROCEDURE. Is that right? It seems a reasonable approach, an

Re: Support for NSS as a libpq TLS backend

On Thu, 2021-06-03 at 15:53 -0400, Andrew Dunstan wrote: > Yeah, but it's annoying to have to start every talk I give touching > this > subject with the slide that says "When we say SSL we really means > TLS". > Maybe release 15 would be a good time to rename user-visible option > names etc, with s

Make unlogged table resets detectable

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 server crashes, you'll be missing only one s

Re: Support for NSS as a libpq TLS backend

On 6/3/21 1:47 PM, Daniel Gustafsson wrote: >> On 3 Jun 2021, at 19:37, Jeff Davis wrote: >> >> On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote: >>> Maybe we should just have --with-ssl={openssl,nss}? That'd avoid >>> needing >>> to check for errors. >> [ apologies for the late reply ] >>

Re: CALL versus procedures with output-only arguments

On 6/3/21 2:29 PM, Tom Lane wrote: > I wrote: >> Hmm, actually we could make step 2 a shade tighter: if a candidate >> routine is a function, match against proargtypes. If it's a procedure, >> match against coalesce(proallargtypes, proargtypes). If we find >> multiple matches, raise ambiguity e

Re: security_definer_search_path GUC

čt 3. 6. 2021 v 21:11 odesílatel Mark Dilger napsal: > > > > On Jun 3, 2021, at 12:06 PM, Pavel Stehule > wrote: > > > > > > > > čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger < > mark.dil...@enterprisedb.com> napsal: > > > > > > > On Jun 3, 2021, at 9:38 AM, Pavel Stehule > wrote: > > > > > > Th

Re: speed up verifying UTF-8

On 03/06/2021 22:16, Heikki Linnakangas wrote: On 03/06/2021 22:10, John Naylor wrote: On Thu, Jun 3, 2021 at 3:08 PM Heikki Linnakangas mailto:hlinn...@iki.fi>> wrote: >                 x1 = half1 + UINT64CONST(0x7f7f7f7f7f7f7f7f); >                 x2 = half2 + UINT64CONST(0x7f7f7f7f7f7f7f

Re: [PATCH] expand the units that pg_size_pretty supports on output

New versions attached to address the initial CF feedback and rebase on HEAD as of now. 0001-Expand-the-units-that-pg_size_pretty-numeric-knows-a.patch - expands the units that pg_size_pretty() can handle up to YB. 0002-Expand-the-supported-units-in-pg_size_bytes-to-cover.patch - expands the uni

Re: speed up verifying UTF-8

On 03/06/2021 22:10, John Naylor wrote: On Thu, Jun 3, 2021 at 3:08 PM Heikki Linnakangas > wrote: >                 x1 = half1 + UINT64CONST(0x7f7f7f7f7f7f7f7f); >                 x2 = half2 + UINT64CONST(0x7f7f7f7f7f7f7f7f); > >                 /* then check that the

Re: speed up verifying UTF-8

On Thu, Jun 3, 2021 at 3:08 PM Heikki Linnakangas wrote: > > On 03/06/2021 17:33, Greg Stark wrote: > >> 3. It's probably cheaper perform the HAS_ZERO check just once on (half1 > > | half2). We have to compute (half1 | half2) anyway. > > > > Wouldn't you have to check (half1 & half2) ? > > Ah, you

Re: security_definer_search_path GUC

> On Jun 3, 2021, at 12:06 PM, Pavel Stehule wrote: > > > > čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger > napsal: > > > > On Jun 3, 2021, at 9:38 AM, Pavel Stehule wrote: > > > > This design looks good for extensions, but I am not sure if it is good for > > users. Some declarative wa

Re: speed up verifying UTF-8

On 03/06/2021 17:33, Greg Stark wrote: 3. It's probably cheaper perform the HAS_ZERO check just once on (half1 | half2). We have to compute (half1 | half2) anyway. Wouldn't you have to check (half1 & half2) ? Ah, you're right of course. But & is not quite right either, it will give false pos

Re: security_definer_search_path GUC

čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger napsal: > > > > On Jun 3, 2021, at 9:38 AM, Pavel Stehule > wrote: > > > > This design looks good for extensions, but I am not sure if it is good > for users. Some declarative way without necessity to programming or install > some extension can be nic

Re: speed up verifying UTF-8

On Thu, Jun 3, 2021 at 9:16 AM Heikki Linnakangas wrote: > Some ideas: > > 1. Better to check if any high bits are set first. We care more about > the speed of that than of detecting zero bytes, because input with high > bits is valid but zeros are an error. > > 2. Since we check that there are n

Re: security_definer_search_path GUC

I thought everybody was already doing this, but maybe not. I put the following in all my function definitions: SET search_path FROM CURRENT (with the exception of a very few functions which explicitly need to use the caller's search path) It seems to me that if this was the default (note: I'

Re: CALL versus procedures with output-only arguments

I wrote: > Hmm, actually we could make step 2 a shade tighter: if a candidate > routine is a function, match against proargtypes. If it's a procedure, > match against coalesce(proallargtypes, proargtypes). If we find > multiple matches, raise ambiguity error. Where do we stand on this topic? I'

Re: security_definer_search_path GUC

> On Jun 3, 2021, at 9:38 AM, Pavel Stehule wrote: > > This design looks good for extensions, but I am not sure if it is good for > users. Some declarative way without necessity to programming or install some > extension can be nice. I agree, though "some declarative way" is a bit vague. I

Re: SSL SNI

I wrote: > It looks like the immediate problem can be resolved by just adding > a check for conn->pghost not being NULL, ... scratch that. There's another problem here, which is that this code should not be looking at conn->pghost AT ALL. That will do the wrong thing with a multi-element host li

Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path

Hi, On 6/3/21 7:17 PM, Arne Roland wrote: > Hi, > > > I haven't tested the parallel case, but I think we should sort out (3) > get_cheapest_fractional_path_for_pathkeys as mentioned above. > Not sure what you refer to by "above" - it's probably better to reply in-line to existing message, whic

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

On Mon, 2020-12-21 at 13:44 -0500, Tom Lane wrote: > Hm. I'm less concerned about that scenario than about somebody > snooping > the on-the-wire traffic. If we're going to invent a connection > setting > for this, I'd say that in addition to "ok to send cleartext password" > and "never ok to send

Re: SSL SNI

I wrote: > Jacob Champion writes: >> It looks like this code needs some guards for a NULL conn->pghost. For >> example when running >> psql 'dbname=postgres sslmode=require hostaddr=127.0.0.1' >> with no PGHOST in the environment, psql is currently segfaulting for >> me. > Duplicated here: It l

Re: Support for NSS as a libpq TLS backend

> On 3 Jun 2021, at 19:37, Jeff Davis wrote: > > On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote: >> Maybe we should just have --with-ssl={openssl,nss}? That'd avoid >> needing >> to check for errors. > > [ apologies for the late reply ] > > Would it be more proper to call it --with-tls=

Re: SSL SNI

Jacob Champion writes: > It looks like this code needs some guards for a NULL conn->pghost. For > example when running > psql 'dbname=postgres sslmode=require hostaddr=127.0.0.1' > with no PGHOST in the environment, psql is currently segfaulting for > me. Duplicated here: Program terminated

Re: Support for NSS as a libpq TLS backend

On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote: > Maybe we should just have --with-ssl={openssl,nss}? That'd avoid > needing > to check for errors. [ apologies for the late reply ] Would it be more proper to call it --with-tls={openssl,nss} ? Regards, Jeff Davis

Re: SSL SNI

On Wed, 2021-04-07 at 15:32 +0200, Peter Eisentraut wrote: > Committed like that. (Default to on, but it's easy to change if there > are any further thoughts.) Hi Peter, It looks like this code needs some guards for a NULL conn->pghost. For example when running psql 'dbname=postgres sslmo

Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path

Hi, I haven't tested the parallel case, but I think we should sort out (3) get_cheapest_fractional_path_for_pathkeys as mentioned above. I am lost about the comment regarding startup_new_fractional. Could you elaborate what you mean by that? Apart from that, I'd argue for a small test case.

Re: missing GRANT on pg_subscription columns

"Euler Taveira" writes: > I was checking the GRANT on pg_subscription and noticed that the command is > not > correct. There is a comment that says "All columns of pg_subscription except > subconninfo are readable". However, there are columns that aren't included: > oid > and subsynccommit. It s

Re: security_definer_search_path GUC

čt 3. 6. 2021 v 18:30 odesílatel Mark Dilger napsal: > > > > On Jun 3, 2021, at 9:03 AM, Pavel Stehule > wrote: > > > > I agree so some possibility of locking search_path or possibility to > control who and when can change it can increase security. This should be a > core feature. It's maybe mor

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

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 patch of subscriber-side > work [1] which uses that code as wel

Re: security_definer_search_path GUC

On Thu, Jun 3, 2021 at 7:30 PM Mark Dilger wrote: > > On Jun 3, 2021, at 9:03 AM, Pavel Stehule > wrote: > > > > I agree so some possibility of locking search_path or possibility to > control who and when can change it can increase security. This should be a > core feature. It's maybe more gener

Re: security_definer_search_path GUC

> On Jun 3, 2021, at 9:03 AM, Pavel Stehule wrote: > > I agree so some possibility of locking search_path or possibility to control > who and when can change it can increase security. This should be a core > feature. It's maybe more generic issue - same functionality can be required > for w

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

On 2021-Jun-02, Michael Paquier wrote: > After 12 runs of VACUUM FULL on my laptop, I have removed the two > highest and the two lowest to remove some noise, and did an average of > the rest: > - HEAD, 100 text columns: 5720ms > - REL_13_STABLE, 100 text columns: 4308ms > - HEAD, 200 text columns:

Re: security_definer_search_path GUC

čt 3. 6. 2021 v 17:54 odesílatel Marko Tiikkaja napsal: > On Thu, Jun 3, 2021 at 9:14 AM Joel Jacobson wrote: > >> On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote: >> >> They still show up everywhere when looking at "public". So this is only >> slightly better, and a maintenance burden. >>

Re: security_definer_search_path GUC

On Thu, Jun 3, 2021 at 9:14 AM Joel Jacobson wrote: > On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote: > > They still show up everywhere when looking at "public". So this is only > slightly better, and a maintenance burden. > > > Good point. I find this annoying as well sometimes. > > It's e

Re: security_definer_search_path GUC

čt 3. 6. 2021 v 8:14 odesílatel Joel Jacobson napsal: > On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote: > > On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote: > > But if running a recent PostgreSQL version, with support for extensions, I > think an even cleaner solution > would be to pack

Re: speed up verifying UTF-8

I wrote: > On Thu, Jun 3, 2021 at 10:42 AM Greg Stark wrote: > > > > If > > we're processing much more than 128 bits and happy to detect NUL > > errors only at the end after wasting some work then you could hoist > > that has_zero check entirely out of the loop (removing the branch > > though it

Re: speed up verifying UTF-8

On Thu, Jun 3, 2021 at 10:42 AM Greg Stark wrote: > > I haven't looked at the surrounding code. Are we processing all the > COPY data in one long stream or processing each field individually? It happens on 64kB chunks. > If > we're processing much more than 128 bits and happy to detect NUL > err

Re: Asynchronous Append on postgres_fdw nodes.

On 3/6/21 14:49, Etsuro Fujita wrote: On Tue, May 11, 2021 at 6:55 PM Etsuro Fujita wrote: On Tue, May 11, 2021 at 6:27 PM Andrey Lepikhov wrote: On 11/5/21 12:24, Etsuro Fujita wrote: -> Append (actual rows=3000 loops=1) -> Async Foreign Scan on f1 (actual rows=0 loops

Re: Multi-Column List Partitioning

> Approach 1 sounds better. It sounds like approach 1 might help us > implement support for allowing NULLs in range partition bounds in the > future, if at all. For now, it might be better to not allocate the > isnull array except for list partitioning. Thanks for confirming. > I'll wait for yo

Re: speed up verifying UTF-8

I haven't looked at the surrounding code. Are we processing all the COPY data in one long stream or processing each field individually? If we're processing much more than 128 bits and happy to detect NUL errors only at the end after wasting some work then you could hoist that has_zero check entirel

  1   2   >