Failures with gcd functions with GCC snapshots GCC and -O3 (?)

Hi all, serinus has been complaining about the new gcd functions in 13~: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-06-03%2003%3A44%3A14 The overflow detection is going wrong the way up and down, like here: SELECT gcd((-9223372036854775808)::int8, (-92233720368547758

Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?)

On Thu, 3 Jun 2021 at 08:26, Michael Paquier wrote: > > Hi all, > > serinus has been complaining about the new gcd functions in 13~: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-06-03%2003%3A44%3A14 > > The overflow detection is going wrong the way up and down, like he

Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?)

Hello I build gcc version 12.0.0 20210603 (experimental) locally, then tried REL_13_STABLE with same CFLAGS as serinus ./configure --prefix=/home/melkij/tmp/pgdev/inst CFLAGS="-O3 -ggdb -g3 -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers" --

Re: Asynchronous Append on postgres_fdw nodes.

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=1) > > >>-

pg_upgrade is failed for 'plpgsql_call_handler' handler

Hi, In one of my testing scenario, i found pg_upgrade is failed for 'plpgsql_call_handler' handler Steps to reproduce - ( on any supported version of PG) Perform initdb ( ./initdb -D  d1 ;  ./initdb -D d2) Start d1 cluster(./pg_ctl -D d1 start) , connect to postgres (./psql postgres)  and c

Re: [HACKERS] logical decoding of two-phase transactions

On Wed, Jun 2, 2021 at 4:34 AM Peter Smith wrote: > > Please find attached the latest patch set v82* > Few comments on 0001: 1. + /* + * BeginTransactionBlock is necessary to balance the EndTransactionBlock + * called within the PrepareTransactionBlock below. + */ + BeginTran

Re: locking [user] catalog tables vs 2pc vs logical rep

On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com wrote: > > On Tuesday, June 1, 2021 4:33 PM Peter Smith > > To: Andres Freund > > Cc: PostgreSQL-development ; Amit Kapila > > ; Markus Wanner > > > > Subject: Re: locking [user] catalog tables vs 2pc vs logical rep > > > > Hi. > > > >

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

Hi, 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 code base, we generally have (void) when non-void return value of a function is ignored. Thoughts? With Regards, Bhar

Re: pg_upgrade is failed for 'plpgsql_call_handler' handler

> On 3 Jun 2021, at 11:53, tushar wrote: > In one of my testing scenario, i found pg_upgrade is failed for > 'plpgsql_call_handler' handle This isn't really a pg_upgrade issue but a pg_dump issue. The handler, inline nd validator functions will be looked up among the functions loaded into pg_d

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

On Thu, Jun 3, 2021 at 4:24 PM Bharath Rupireddy wrote: > > Hi, > > 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? Basically, fsm_set_and_search, serve both "set" and "sear

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

On Thu, Jun 3, 2021 at 4:47 PM Dilip Kumar wrote: > > On Thu, Jun 3, 2021 at 4:24 PM Bharath Rupireddy > wrote: > > > > Hi, > > > > 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 in

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

On Wed, Jun 2, 2021 at 7:23 PM Dilip Kumar wrote: > > On Wed, Jun 2, 2021 at 7:20 PM Kuntal Ghosh > wrote: > > > > On Wed, Jun 2, 2021 at 3:10 PM Dilip Kumar wrote: > > > > > > Yes, you are right. I will change it in the next version, along with > > > the test case. > > > > > +/* > > +

Re: Skip partition tuple routing with constant partition key

Hou-san, On Tue, Jun 1, 2021 at 5:43 PM houzj.f...@fujitsu.com wrote: > From: Amit Langote > > > > Where are you thinking to cache the partidx list? Inside > > > > PartitionDesc or some executor struct? > > > > > > I was thinking cache the partidx list in PartitionDescData which is in > > > rel

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

On Thu, Jun 3, 2021 at 6:54 PM 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 code base, we generally have > (void) when non-void return

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

On Thu, Jun 3, 2021 at 5:11 PM Bharath Rupireddy wrote: > > On Thu, Jun 3, 2021 at 4:47 PM Dilip Kumar wrote: > > > > On Thu, Jun 3, 2021 at 4:24 PM Bharath Rupireddy > > wrote: > > > > > > Hi, > > > > > > It looks like for some of the fsm_set_and_search calls whose return > > > value is ignored

Re: Documentation missing for PGSSLCRLDIR

> On 3 Jun 2021, at 05:13, Michael Paquier wrote: > I have noticed that the documentation for PGSSLCRLDIR is missing. > That seems like an oversight in f5465fa. +1 on applying this. While looking at this I found another nearby oversight which needs a backport down to 13 where it was introduced.

A few source files have the wrong copyright year

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. git grep -E "Portions Copyright \(c\) ([0-9]{4}-[0-9]{4}|[0-9]{4}), PostgreSQL Global Development Group" | grep -Ev "2021"

Re: A few source files have the wrong copyright year

> On 3 Jun 2021, at 14:16, David Rowley wrote: > git grep -E "Portions Copyright \(c\) ([0-9]{4}-[0-9]{4}|[0-9]{4}), > PostgreSQL Global Development Group" | grep -Ev "2021" > > Seems fairly good at finding them. 14 in total. src/tools/copyright.pl finds these as well as contrib/pageinspect/gis

Re: improve installation short version

On 6/2/21 5:36 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 6/2/21 4:58 PM, Mark Dilger wrote: >>> Prior to where your patch makes changes, the docs say, "If you are building >>> PostgreSQL for Microsoft Windows, read this chapter if you intend to build >>> with MinGW or Cygwin". I think

Re: A few source files have the wrong copyright year

On Fri, 4 Jun 2021 at 00:30, Daniel Gustafsson wrote: > src/tools/copyright.pl finds these as well as contrib/pageinspect/gistfuncs.c > which also ends the range in 2020, might want to include that one too when > pushing this. Thanks. I wasn't aware of that. David

Re: Support for CREATE MODULE?

On 02.06.21 16:43, Jim Mlodgenski wrote: It's already quite hard to tell which part of a multiply.qualified.name is which, given that SQL says that you can optionally put a "catalog" (database) name in front of the others. I really doubt there is a way to shoehorn sub-schemas in there without cre

Re: Duplicate history file?

At Tue, 01 Jun 2021 13:03:22 +0900, Tatsuro Yamada wrote in > Hi Horiguchi-san, > > On 2021/05/31 16:58, Kyotaro Horiguchi wrote: > > So, I started a thread for this topic diverged from the following > > thread. > > https://www.postgresql.org/message-id/4698027d-5c0d-098f-9a8e-8cf09e36a...@nttc

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

On Thu, Jun 3, 2021 at 5:22 PM Julien Rouhaud wrote: > > On Thu, Jun 3, 2021 at 6:54 PM 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

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

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 code base, we generally have (void) when non-void return value of a function i

Re: improve installation short version

On 02.06.21 23:27, Andrew Dunstan wrote: It's not the fault of your patch, but the docs seem to be misleading in ways that your comments don't fix. (Or perhaps my Windows knowledge is just too lacking to realize why these instructions are ok?) Prior to where your patch makes changes, the do

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On 03.06.21 06:17, Tom Lane wrote: David Rowley writes: There are quite a few other places in that file that should be using DatumGetCString() instead of DatumGetPointer(). Should we fix those too for PG14? +1. I'm surprised we are not getting compiler warnings. Well, DatumGetPointer() ret

Re: parent foreign tables and row marks

On Thu, Jun 3, 2021 at 10:07 AM Amit Langote wrote: > On Thu, Jun 3, 2021 at 3:39 AM Tom Lane wrote: > > > > Amit Langote writes: > > > I noticed that 428b260f87e8 (v12) broke the cases where a parent > > > foreign table has row marks assigned. > > > > Indeed :-(. Fix pushed. I tweaked the com

Re: speed up verifying UTF-8

On 02/06/2021 19:26, John Naylor wrote: For v10, I've split the patch up into two parts. 0001 uses pure C everywhere. This is much smaller and easier to review, and gets us the most bang for the buck. One concern Heikki raised upthread is that platforms with poor unaligned-memory access will

missing GRANT on pg_subscription columns

Hi, 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 seems an oversight in the commits 6

Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?)

Michael Paquier writes: > serinus has been complaining about the new gcd functions in 13~: moonjelly, which also runs a bleeding-edge gcc, started to fail the same way at about the same time. Given that none of our code in that area has changed, it's hard to think it's anything but a broken comp

Re: pg_upgrade is failed for 'plpgsql_call_handler' handler

Daniel Gustafsson writes: >> On 3 Jun 2021, at 11:53, tushar wrote: >> In one of my testing scenario, i found pg_upgrade is failed for >> 'plpgsql_call_handler' handle > This is intentional since the language template work in 8.1, before then > pg_dump would look up support functions in pg_cata

Re: pg_upgrade is failed for 'plpgsql_call_handler' handler

> On 3 Jun 2021, at 16:12, Tom Lane wrote: > > Daniel Gustafsson writes: >>> On 3 Jun 2021, at 11:53, tushar wrote: >>> In one of my testing scenario, i found pg_upgrade is failed for >>> 'plpgsql_call_handler' handle > >> This is intentional since the language template work in 8.1, before th

Re: speed up verifying UTF-8

> 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) ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >