Re: heapam_index_build_range_scan's anyvisible

On Wed, Sep 25, 2019 at 10:24:05PM -0700, Ashwin Agrawal wrote: > Thanks for reporting, I did indeed missed out contrib. Please find attached > the v2 of the patch which includes the change required in contrib as well. Okay, that makes sense. The patch looks good to me so I have switched it to re

Re: pgbench - extend initialization phase control

2019-11-06 11:31 に Fujii Masao さんは書きました: On Wed, Nov 6, 2019 at 6:23 AM Fabien COELHO wrote: Hello, >>> - for (step = initialize_steps; *step != '\0'; step++) >>> + for (const char *step = initialize_steps; *step != '\0'; step++) > > But I still wonder why we should apply such change here.

Re: Add SQL function to show total block numbers in the relation

btkimurayuzk writes: I propose new simple sql query, which shows total block numbers in the relation. ... Of cource, we can know this value such as select (pg_relation_size('t') / current_setting('block_size')::bigint)::int; I don't really see why the existing solution isn't sufficient. I th

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hi Kyotaro, Le 07/11/2019 à 08:10, Kyotaro Horiguchi a écrit : > Hello. > > At Wed, 6 Nov 2019 20:13:10 +0900, Etsuro Fujita > wrote in >> Hi Michael-san, >> >> On Wed, Nov 6, 2019 at 4:35 PM Michael Paquier wrote: >>> On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote: On Wed,

Re: Do we have a CF manager for November?

On Tue, Nov 05, 2019 at 08:50:54PM +0500, Ibrar Ahmed wrote: > On Tue, Nov 5, 2019 at 7:18 AM Michael Paquier wrote: >> That may have been me. I can take this one if there is nobody else >> around. Okay, so it is. I have begun browsing the patch history, and we have a lt of work ahead. > I

Re: Collation versioning

On Mon, Nov 4, 2019 at 9:59 PM Thomas Munro wrote: > > On Tue, Nov 5, 2019 at 4:18 AM Julien Rouhaud wrote: > > On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud wrote: > > > On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro > > > wrote: > > > > Here are some problems to think about: > > > > > > > > *

Re: pgbench - extend initialization phase control

I think that it may break --no-vacuum, and I thought that there may be other option which remove things, eventually. Also, having a NO-OP looks ok to me. As far as I read the code, checkInitSteps() checks the initialization steps that users specified. The initialization steps string that "v"

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Horiguchi-san, On Thu, Nov 7, 2019 at 4:11 PM Kyotaro Horiguchi wrote: > At Wed, 6 Nov 2019 20:13:10 +0900, Etsuro Fujita > wrote in > > On Wed, Nov 6, 2019 at 4:35 PM Michael Paquier wrote: > > > On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote: > > > > On Wed, Nov 6, 2019 at 1:1

Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )

Hello Horiguchi-san, On Thu, Nov 7, 2019 at 3:10 PM Kyotaro Horiguchi wrote: > Mmm? See the bit in the patch cited below (v5). > > + /* Range check */ > + if (unlikely(!FLOAT8_FITS_IN_INT32(num)) || isnan(num)) > > If compiler doesn't any fancy, num is fed to an arithmetic before > ch

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hello Gilles. I made a silly mistake. At Thu, 7 Nov 2019 09:05:55 +0100, Gilles Darold wrote in > > FWIW, I see it a bit weird, too. And perhaps "prepare" should be in > > upper case letters. Plus, any operation including a SELECT on a > > temporary table inhibits PREAPRE TRANSACTION, but the sa

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hello, Fujita-san. At Thu, 7 Nov 2019 17:20:07 +0900, Etsuro Fujita wrote in > Only two people complaining about the wording? Considering as well > that we use that wording in the docs and there were no complains about > that IIRC, I don't feel a need to change that, TBH. > > > And perhaps "p

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

At Thu, 07 Nov 2019 17:27:47 +0900 (JST), Kyotaro Horiguchi wrote in > "modified" is my mistake as in the just posted mail. But the most > significant point in the previous mail is using "foreign tables using > postgres_fdw" instead of "postgres_fdw foreign tables". And the other > point is usin

Re: Minimal logical decoding on standbys

Hi Amit, I am reading about this feature and reviewing it. To start with, I reviewed the patch: 0005-Doc-changes-describing-details-about-logical-decodin.patch. >prevent VACUUM from removing required rows from the system catalogs, >hot_standby_feedback should be set on the standby. In spite of th

Re: TAP tests aren't using the magic words for Windows file access

On Thu, Nov 7, 2019 at 1:57 AM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > In any case, the patch will fail as written - on the Msys 1 system I > just tested Win32::API is not available to the DTK perl we need to use > to run TAP tests. > > May I ask which version of Msys is that s

Re: pgbench - extend initialization phase control

On Thu, Nov 7, 2019 at 5:18 PM Fabien COELHO wrote: > > > >>> I think that it may break --no-vacuum, and I thought that there may be > >>> other option which remove things, eventually. Also, having a NO-OP looks > >>> ok to me. > >> > >> As far as I read the code, checkInitSteps() checks the initi

Re: Add SQL function to show total block numbers in the relation

Hello, Kimura-san. At Thu, 07 Nov 2019 17:04:51 +0900, btkimurayuzk wrote in > > btkimurayuzk writes: > >> I propose new simple sql query, which shows total block numbers in the > >> relation. > >> ... > >> Of cource, we can know this value such as > >> select (pg_relation_size('t') / > >> cur

Re: alternative to PG_CATCH

On 2019-11-06 15:49, Tom Lane wrote: Peter Eisentraut writes: On 2019-11-04 16:01, Tom Lane wrote: Now that I've actually looked at the patched code, there's a far more severe problem with it. Namely, that use of PG_FINALLY means that the "finally" segment is run without having popped the err

Re: Resume vacuum and autovacuum from interruption and cancellation

+ VACOPT_RESUME = 1 << 8/* resume from the previous point */ I think this unused ENUM value is not needed. Regards, Yu Kimura

Re: Collation versioning

On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud wrote: > > On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro wrote: > > > > Unfortunately I haven't had time to work on it seriously, but here's a > > quick rebase to get the proof-of-concept back into working shape. Thanks! I also removed the test for R

Re: Does 'instead of delete' trigger support modification of OLD

> I looked in the CREATE TRIGGER manual page and found this: > https://www.postgresql.org/docs/12/sql-createtrigger.html > If the trigger fires before or instead of the event, the trigger > can skip the operation for the current row, or change the row > being insert

Re: [proposal] recovery_target "latest"

On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in On 11/6/19 1:55 PM, Grigory Smolkin wrote: On 11/6/19 12:56 PM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: On 11/6/19 10:39 AM, Peter Eisentraut wrote:

Re: Does 'instead of delete' trigger support modification of OLD

Hello Eugen, Thursday, November 7, 2019, 11:20:32 AM, you wrote: >> I looked in the CREATE TRIGGER manual page and found this: >> https://www.postgresql.org/docs/12/sql-createtrigger.html >> If the trigger fires before or instead of the event, the trigger >> can skip the

Re: [Proposal] Global temporary tables

> 2019年11月7日 上午12:08，Konstantin Knizhnik 写道： > > > > On 06.11.2019 16:24, 曾文旌(义从) wrote: >> Dear Hackers >> >> >> I attached the patch of GTT implementationI base on PG12. >> The GTT design came from my first email. >> Some limitations in patch will be eliminated in later versions. >> >>

Re: pgbench - extend initialization phase control

Hello Masao-san, I do not think that this is desirable. It would be a regression, and allowing a no-op is not an issue in anyway. Why is that regression, you think? Because "pgbench -I ' d'" currently works and it would cease to work after the patch. I think that's an oversight. If I'm m

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Horiguchi-san, On Thu, Nov 7, 2019 at 5:28 PM Kyotaro Horiguchi wrote: > At Thu, 7 Nov 2019 17:20:07 +0900, Etsuro Fujita > wrote in > > Only two people complaining about the wording? Considering as well > > that we use that wording in the docs and there were no complains about > > that IIRC,

Re: [Proposal] Global temporary tables

čt 7. 11. 2019 v 10:30 odesílatel 曾文旌(义从) napsal: > > > > 2019年11月7日 上午12:08，Konstantin Knizhnik 写道： > > > > > > > > On 06.11.2019 16:24, 曾文旌(义从) wrote: > >> Dear Hackers > >> > >> > >> I attached the patch of GTT implementationI base on PG12. > >> The GTT design came from my first email. > >> S

Re: [Patch proposal] libpq portal support

Hello everybody, Yes, we will be happy to put our patch under the PostgreSQL License. Patch is attached to this email, master was rebased to head prior to creating the patch. We are using a C++ wrapper on top of libpq for using database connections in multithreaded asynchronous applications. For

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Wed, Nov 6, 2019 at 11:33 AM vignesh C wrote: > > I have made one change to the configuration file in > contrib/test_decoding directory, with that the coverage seems to be > fine. I have seen that the coverage is almost like the code before > applying the patch. I have attached the test change

Re: [proposal] recovery_target "latest"

At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in > > On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: > > At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin > > wrote in > >> On 11/6/19 1:55 PM, Grigory Smolkin wrote: > >>> On 11/6/19 12:56 PM, Fujii Masao wrote: > What happens if

Re: tableam vs. TOAST

On 2019-11-06 18:00, Andres Freund wrote: I'd like an AM to have the *option* of implementing something better, or at least go in the direction of making that possible. I don't think the presented design prevents that. An AM can just return false from relation_needs_toast_table in all cases a

Re: pgbench - extend initialization phase control

On Thu, Nov 7, 2019 at 6:35 PM Fabien COELHO wrote: > > > Hello Masao-san, > > >> I do not think that this is desirable. It would be a regression, and > >> allowing a no-op is not an issue in anyway. > > > > Why is that regression, you think? > > Because "pgbench -I ' d'" currently works and it wo

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Thu, Nov 7, 2019 at 3:19 PM Amit Kapila wrote: > > On Wed, Nov 6, 2019 at 11:33 AM vignesh C wrote: > > > > I have made one change to the configuration file in > > contrib/test_decoding directory, with that the coverage seems to be > > fine. I have seen that the coverage is almost like the cod

Re: Parallel leader process info in EXPLAIN

On Mon, 4 Nov 2019 at 00:30, Thomas Munro wrote: > On Mon, Nov 4, 2019 at 12:11 PM Thomas Munro > wrote: > > I guess I thought of that as a debugging feature and took it out > > because it was too verbose, but maybe it just needs to be controlled > > by the VERBOSE switch. Do you think we shoul

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Horiguchi-san, On Thu, Nov 7, 2019 at 5:31 PM Kyotaro Horiguchi wrote: > I forgot to mention that the comment in XACT_EVENT_PRE_PREPARE > contains the same mistake and needs more or less the same fix. Good catch! How about rewriting "We disallow remote transactions that modified anything" in th

Re: Using multiple extended statistics for estimates

On Thu, Nov 07, 2019 at 01:38:20PM +0900, Kyotaro Horiguchi wrote: Hello. At Wed, 6 Nov 2019 20:58:49 +0100, Tomas Vondra wrote in >Here is a slightly polished v2 of the patch, the main difference being >that computing clause_attnums was moved to a separate function. > This time with the att

Re: Add Change Badges to documentation

Hello Corey, Attached is a patch to implement change badges in our documentation. More precisely, it is a POC to show that the infra works. It adds 3 badges on various entries. Patch applies cleanly, compiles, and indeed (too) green boxes show up. Good. Maybe it would be better with ba

Re: Reorderbuffer crash during recovery

On Thu, Nov 07, 2019 at 11:01:17AM +0530, Dilip Kumar wrote: On Thu, Nov 7, 2019 at 9:55 AM vignesh C wrote: On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote: > > On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote: > > > > Hi, > > > > ... > > > > Issue1 it seems like if all the reorderbuffer has

Re: pgbench - extend initialization phase control

Hello, I think that the actual oversight is that the checkInitSteps should be called at the beginning of processing initialization steps rather than while processing -I, because currently other places modify the initialization string (no-vacuum, foreign key) and thus are not checked. As far

Re: Reorderbuffer crash during recovery

On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra wrote: > > I'm a bit confused - does this happen only with the logical_work_mem > patches, or with clean master too? > This occurs with the clean master. This is a base code problem revealed while doing stress testing of logical_work_mem patches. --

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Thu, Nov 7, 2019 at 3:50 PM Dilip Kumar wrote: > > On Thu, Nov 7, 2019 at 3:19 PM Amit Kapila wrote: > > > What do you think? > I have reviewed your changes and looks fine to me. > Okay, thanks. I am also happy with the two patches I have posted in my last email [1]. Tomas, would you like t

Re: Why overhead of SPI is so large?

Hello. At Tue, 5 Nov 2019 22:14:40 +0100, Pavel Stehule wrote in > Hi > > pá 23. 8. 2019 v 16:32 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > > > > > > > On 23.08.2019 14:42, Pavel Stehule wrote: > > > > > > In reality it is not IMMUTABLE function. On second hand, t

Re: Why overhead of SPI is so large?

čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi napsal: > Hello. > > At Tue, 5 Nov 2019 22:14:40 +0100, Pavel Stehule > wrote in > > Hi > > > > pá 23. 8. 2019 v 16:32 odesílatel Konstantin Knizhnik < > > k.knizh...@postgrespro.ru> napsal: > > > > > > > > > > > On 23.08.2019 14:42, Pavel Steh

Re: [Proposal] Global temporary tables

> 2019年11月7日 下午5:40，Pavel Stehule 写道： > > > > čt 7. 11. 2019 v 10:30 odesílatel 曾文旌(义从) > napsal: > > > > 2019年11月7日 上午12:08，Konstantin Knizhnik > > 写道： > > > > > > > > On 06.11.2019 16:24, 曾文旌(义从) wrote: > >> Dear H

Re: [Proposal] Global temporary tables

čt 7. 11. 2019 v 13:17 odesílatel 曾文旌(义从) napsal: > > > 2019年11月7日 下午5:40，Pavel Stehule 写道： > > > > čt 7. 11. 2019 v 10:30 odesílatel 曾文旌(义从) > napsal: > >> >> >> > 2019年11月7日 上午12:08，Konstantin Knizhnik 写道： >> > >> > >> > >> > On 06.11.2019 16:24, 曾文旌(义从) wrote: >> >> Dear Hackers >> >> >> >>

Re: Remove HAVE_LONG_LONG_INT

On 2019-10-30 14:49, Peter Eisentraut wrote: HAVE_LONG_LONG_INT is now implied by the requirement for C99, so the separate Autoconf check can be removed. The uses are almost all in ecpg code, and AFAICT the check was originally added specifically for ecpg. committed -- Peter Eisentraut

Re: [proposal] recovery_target "latest"

On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in On 11/6/19 1:55 PM, Grigory Smolkin wrote: On 11/6/19 12:56 PM, Fujii Masao w

Re: TAP tests aren't using the magic words for Windows file access

On 11/7/19 3:42 AM, Juan José Santamaría Flecha wrote: > > On Thu, Nov 7, 2019 at 1:57 AM Andrew Dunstan > > wrote: > > > In any case, the patch will fail as written - on the Msys 1 system I > just tested Win32::API is not available to the DTK perl

Re: TAP tests aren't using the magic words for Windows file access

On 2019-Nov-07, Andrew Dunstan wrote: > The test I'm running is: > >     perl -MWin32::API -e ';' > > And perl reports it can't find the module. That's a curious test to try, given that the module is called Win32API::File. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreS

Re: TAP tests aren't using the magic words for Windows file access

On 11/7/19 8:53 AM, Alvaro Herrera wrote: > On 2019-Nov-07, Andrew Dunstan wrote: > >> The test I'm running is: >> >>     perl -MWin32::API -e ';' >> >> And perl reports it can't find the module. > That's a curious test to try, given that the module is called > Win32API::File. > The patch says:

Re: tableam vs. TOAST

On Thu, Nov 7, 2019 at 1:15 AM Ashutosh Sharma wrote: > @Robert, Myself and Prabhat have tried running the test-cases that > caused the checkpointer process to crash earlier multiple times but we > are not able to reproduce it both with and without the patch. However, > from the stack trace shared

Re: TAP tests aren't using the magic words for Windows file access

On 2019-Nov-07, Andrew Dunstan wrote: > On 11/7/19 8:53 AM, Alvaro Herrera wrote: > > That's a curious test to try, given that the module is called > > Win32API::File. > > The patch says: > > +        require Win32::API; > +        Win32::API->import; Oh, you're right, it does. I wonder why,

Re: TAP tests aren't using the magic words for Windows file access

On 11/7/19 9:12 AM, Alvaro Herrera wrote: > On 2019-Nov-07, Andrew Dunstan wrote: > >> On 11/7/19 8:53 AM, Alvaro Herrera wrote: >>> That's a curious test to try, given that the module is called >>> Win32API::File. >> The patch says: >> >> +        require Win32::API; >> +        Win32::API->impo

Re: Missing test of SPI copy functionality

On 11/6/19 6:27 PM, Michael Paquier wrote: On Wed, Nov 06, 2019 at 04:16:14PM -0800, Mark Dilger wrote: While working on cleaning up the SPI interface, I found that one of the SPI error codes, SPI_ERROR_COPY, is never encountered in any test case when running `make check-world`. This case is

Re: TAP tests aren't using the magic words for Windows file access

On 11/7/19 9:12 AM, Alvaro Herrera wrote: >> >> The patch says: >> >> +        require Win32::API; >> +        Win32::API->import; > Oh, you're right, it does. I wonder why, though: > On further inspection I think those lines are unnecessary. The remainder of the patch doesn't use this at all,

Re: tableam vs. TOAST

On Thu, Nov 7, 2019 at 7:35 PM Robert Haas wrote: > > On Thu, Nov 7, 2019 at 1:15 AM Ashutosh Sharma wrote: > > @Robert, Myself and Prabhat have tried running the test-cases that > > caused the checkpointer process to crash earlier multiple times but we > > are not able to reproduce it both with

Re: 64 bit transaction id

On Tue, Nov 5, 2019 at 09:34:52AM +1300, Thomas Munro wrote: > On Tue, Nov 5, 2019 at 8:45 AM Tomas Vondra > > Agreed. I think code complexity is part of the trade-off. IMO it's fine > > to hack existing heap AM initially, and only explore the separate AM if > > that turns out to be promising. >

Re: Index Skip Scan

> On Sun, Nov 03, 2019 at 05:45:47PM +0100, Dmitry Dolgov wrote: > > * The extra scankeys that you are using in most of the new nbtsearch.c > > code is an insertion scankey -- not a search style scankey. I think > > that you should try to be a bit clearer on that distinction in > > comments. It is

Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )

Yuya Watari writes: > On Thu, Nov 7, 2019 at 3:10 PM Kyotaro Horiguchi > wrote: >> + if (unlikely(!FLOAT8_FITS_IN_INT32(num)) || isnan(num)) >> If compiler doesn't any fancy, num is fed to an arithmetic before >> checking if it is NaN. That seems have a chance of exception. > Thank you for

Re: Reorderbuffer crash during recovery

Hi, On 2019-11-07 17:03:44 +0530, Amit Kapila wrote: > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra > wrote: > > > > I'm a bit confused - does this happen only with the logical_work_mem > > patches, or with clean master too? > > > > This occurs with the clean master. This is a base code problem

Re: [Proposal] Global temporary tables

On 07.11.2019 12:30, 曾文旌(义从) wrote: May be the assumption is that all indexes has to be created before GTT start to be used. Yes, Currently, GTT's index is only supported and created in an empty table state, and other sessions are not using it. There has two improvements pointer: 1 Index

Re: SKIP_LOCKED test causes random buildfarm failures

Michael Paquier writes: > On Wed, Nov 06, 2019 at 03:01:11PM -0800, Andres Freund wrote: >> I don't know what lead us to doing so, but it doesn't seem reasonable to >> allow the user to see whether the table has actually been vacuumed. I >> would assume that one uses SKIP_LOCKED partially to avoid

Re: RFC: split OBJS lines to one object per line

Michael Paquier writes: > On Tue, Nov 05, 2019 at 02:47:55PM -0800, Andres Freund wrote: >> Pushed a patch going with the former. Let's see what the buildfarm >> says... > Thanks Andres. On a rather related note, would it make sense to do > the same for regression and isolation tests in our in-c

plpythonu -> python3

The docs currently say The language named plpythonu implements PL/Python based on the default Python language variant, which is currently Python 2. (This default is independent of what any local Python installations might consider to be their default, for example,

Re: Checking return value of SPI_execute

On 11/6/19 7:11 AM, Alvaro Herrera wrote: On 2019-Nov-06, Pavel Stehule wrote: My comment was about maybe obsolescence of this API. Probably it was designed before exception introduction. For example - syntax error is ended by exception. Wrong numbers of argument is signalized by error stat

Re: RFC: split OBJS lines to one object per line

Hi, On 2019-11-07 11:24:37 +0900, Michael Paquier wrote: > On Tue, Nov 05, 2019 at 02:47:55PM -0800, Andres Freund wrote: > > Pushed a patch going with the former. Let's see what the buildfarm > > says... > > Thanks Andres. On a rather related note, would it make sense to do > the same for regre

Re: heapam_index_build_range_scan's anyvisible

Hi, On 2019-11-07 17:02:36 +0900, Michael Paquier wrote: > On Wed, Sep 25, 2019 at 10:24:05PM -0700, Ashwin Agrawal wrote: > > Thanks for reporting, I did indeed missed out contrib. Please find attached > > the v2 of the patch which includes the change required in contrib as well. > > Okay, that

Re: deferrable FK constraints on partitioned rels

On 2019-Nov-05, Alvaro Herrera wrote: > Uh, somehow I posted a previous version of the patch that implements my > rejected approach, instead of the final version I described. Here's the > real patch (which also includes tests). This was broken in pg11 also. Pushed to all branches. -- Álvaro H

Re: ssl passphrase callback

On 11/4/19 4:43 PM, Thomas Munro wrote: > > It looks like the new declarations in libpq-be.h are ifdef'd out in a > non-USE_SSL build, but then we still try to build the new test module > and it fails: > > https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.64071 I think this

Re: plpythonu -> python3

Christoph Berg writes: > The docs currently say > The language named plpythonu implements > PL/Python based on the default Python language variant, which is > currently Python 2. (This default is independent of what any > local Python installations might consider to be >

Re: Application name for pg_basebackup and friends

On 11/7/19 1:51 AM, Michael Paquier wrote: I don't think we need a new comand line switch for it. +1. Please note that I have marked this patch as rejected in the CF app, per the arguments upthread. Ok, agreed. Thanks for the feedback ! Best regards, Jesper

Re: plpythonu -> python3

Re: Tom Lane 2019-11-07 <14186.1573147...@sss.pgh.pa.us> > > And probably drop python2 support altogether. > > I think it'll be quite some time before that happens. People who > are still using ancient versions of Postgres are not likely to be > impressed by arguments about how python2 is out of

Re: Checking return value of SPI_execute

On 2019-Nov-07, Mark Dilger wrote: > I'd like to keep the status codes for (a) but deprecate error codes for (b) > in favor of elog(ERROR). I don't see that these elogs should ever be a > problem, since getting one in testing would indicate the need to fix bad C > code, not the need to catch an e

Re: plpythonu -> python3

On Thu, Nov 7, 2019 at 6:04 PM Christoph Berg wrote: > How do other packagers handle that? Are you still supporting python2? > Would it be ok to make plpythonu.control point at python3 in PG12 in > Debian, even the upstream default is still python2? Speaking for Fedora and RHEL, I'd say the best w

Re: plpythonu -> python3

I wrote: > Christoph Berg writes: >> As python2 is EOL very soon, I'd say that point is now, i.e. we should >> make plpythonu.control point at plpython3u in PG13+. > We're starting to work on that; it's not a trivial change. Among other > things, pg_pltemplate has got pointers at plpython2 as we

Re: Removing pg_pltemplate and creating "trustable" extensions

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 2019-08-21 21:29, Tom Lane wrote: > >> Patch 0001 below addresses this problem by inventing a concept of > >> "trustable" (not necessarily trusted) extensions. An extension that > >> would normally require superu

Re: Removing pg_pltemplate and creating "trustable" extensions

Stephen Frost writes: >> Peter Eisentraut writes: >>> Using GUCs to control some of this creates yet another place where >>> permission information is kept, and with it questions about how to get >>> to it, how to edit it, or to back it up and restore it, etc. Also, >>> list-based parameters

Re: Removing pg_pltemplate and creating "trustable" extensions

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > >> Peter Eisentraut writes: > >>> Using GUCs to control some of this creates yet another place where > >>> permission information is kept, and with it questions about how to get > >>> to it, how to edit it, or to back

Re: Removing pg_pltemplate and creating "trustable" extensions

On 11/7/19 2:13 PM, Stephen Frost wrote: >> That doesn't seem like a big objection from here. We could fix it >> by making a separate privilege bit, but I doubt that it's worth using >> up one of our limited set of spare bits for. > > I do not agree that we should just shift to using default rol

Re: Removing pg_pltemplate and creating "trustable" extensions

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >>> Two things- first, this doesn't actually cover everything that the >>> proposed GUCs do- specifically, the proposed GUCs give you a way to >>> limit what specific extensions are allowed to be installed, an

Re: Removing pg_pltemplate and creating "trustable" extensions

Chapman Flack writes: > So isn't this more a proposal to add another boolean attribute > to pg_authid, along the lines of rolcreatedb or rolbypassrls? I think we've mostly concluded that default roles are superior to pg_authid attributes. The latter are legacy things rather than a model to keep

Re: define bool in pgtypeslib_extern.h

I wrote: > I'm inclined to think that we need to make ecpglib.h's bool-related > definitions exactly match c.h, which will mean that it has to pull in > on most platforms, which will mean adding a control symbol > for that to ecpg_config.h. I do not think we should export > HAVE_STDBOOL_H and SIZ

Re: Does 'instead of delete' trigger support modification of OLD

On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote: > Hello Eugen, > > Thursday, November 7, 2019, 11:20:32 AM, you wrote: > > >> I looked in the CREATE TRIGGER manual page and found this: > > >> https://www.postgresql.org/docs/12/sql-createtrigger.html > >> If the trig

Re: Safeguards against incorrect fd flags for fsync()

On 10/8/19 11:26 PM, Michael Paquier wrote: Hi all, After the set of issues discussed here, it seems to me that it would be a good thing to have some safeguards against incorrect flags when opening a fd which would be used for fsync(): https://www.postgresql.org/message-id/16039-196fc97cc05e1.

Re: log bind parameter values on error

So, if some parameters are large (they can be up to 1 GB-1, remember) then we can bloat the log file severely. I think we need to place an upper limit on the strings that we're going to log -- as inspiration, callers of ExecBuildValueDescription uses 64 chars per value maximum. Something like that

Re: log bind parameter values on error

On 2019-Nov-07, Alvaro Herrera wrote: > So, if some parameters are large (they can be up to 1 GB-1, remember) > then we can bloat the log file severely. I think we need to place an > upper limit on the strings that we're going to log -- as inspiration, > callers of ExecBuildValueDescription uses

Re: TestLib::command_fails_like enhancement

On 10/31/19 10:02 AM, Andrew Dunstan wrote: This small patch authored by my colleague Craig Ringer enhances Testlib's command_fails_like by allowing the passing of extra keyword type arguments. The keyword initially recognized is 'extra_ipcrun_opts'. The value for this keyword needs to be an

Re: Does 'instead of delete' trigger support modification of OLD

On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote: > On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote: > > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am > > >> not sure how much work it would take to allow that, but it seems like it > > >> is a v

SPI refactoring

Hackers, As discussed with Tom in [1] and again with Pavel and Alvaro in [2], here is a partial WIP refactoring of the SPI interface. The goal is to remove as many of the SPI_ERROR_xxx codes as possible from the interface, replacing them with elog(ERROR), without removing the ability of call

Re: log bind parameter values on error

Hi, On 2019-11-05 12:07:50 +, Alexey Bashtanov wrote: > > What I'm suggesting is that PortalStart() would build a string > > representation out of the parameter list (using > > ParamExternData.textValue if set, calling the output function > > otherwise), and stash that in the portal. > > > >

Collation versions on Windows (help wanted, apply within)

Hello hackers, Here's a draft patch that teaches PostgreSQL how to ask for collation versions on Windows. It receives a pair of DWORDs, which, it displays as hex. The values probably have an internal structure that is displayed in a user-friendly way by software like Active Directory and SQL Ser

Re: Should we make scary sounding, but actually routine, errors less scary?

Hi, On 2019-11-05 22:00:58 -0500, Chapman Flack wrote: > On 11/05/19 18:54, Andres Freund wrote: > > Hi, > > > > There's a few errors that we issue that are, often, much less bad than > > they sound. The most common cases I immediately can recall are: > > > > > > 1) Mentioning crash, once for e

Re: Should we make scary sounding, but actually routine, errors less scary?

Hi, On 2019-11-06 17:36:09 +0900, Kyotaro Horiguchi wrote: > At Tue, 5 Nov 2019 15:54:22 -0800, Andres Freund wrote > in > > Hi, > > > > There's a few errors that we issue that are, often, much less bad than > > they sound. The most common cases I immediately can recall are: > > > > > > 1) M

Re: SKIP_LOCKED test causes random buildfarm failures

On Thu, Nov 07, 2019 at 11:50:25AM -0500, Tom Lane wrote: > Michael Paquier writes: >> Good question. That's a historical choice, still I have seen cases >> where those warnings are helpful while not making the logs too >> verbose to see some congestion in the jobs. > > I kind of feel that NOTIC

Re: heapam_index_build_range_scan's anyvisible

On Thu, Nov 07, 2019 at 09:25:40AM -0800, Andres Freund wrote: > Let me take a look this afternoon. Swapped out of my brain right now > unfortunately. Thanks for the update. -- Michael signature.asc Description: PGP signature

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

On Thu, Nov 07, 2019 at 06:40:36PM +0900, Etsuro Fujita wrote: > On Thu, Nov 7, 2019 at 5:28 PM Kyotaro Horiguchi > wrote: >> At Thu, 7 Nov 2019 17:20:07 +0900, Etsuro Fujita >> wrote in >>> Only two people complaining about the wording? Considering as well That's like.. Half the folks partic

Re: Add SQL function to show total block numbers in the relation

On Thu, Nov 07, 2019 at 06:01:34PM +0900, Kyotaro Horiguchi wrote: > Sorry, but I also vote -1 for the new function. So do I. If there are no objections, I will mark the patch as rejected in the CF app. > If they need it so frequently, a user-defined function is easily > made up. Yep. -- Michae

Re: pg_waldump and PREPARE

On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote: > Sorry for the long delay... Yes, I will update the patch if necessary. Fujii-san, are you planning to update this patch then? I have switched it as waiting on author. -- Michael signature.asc Description: PGP signature

Re: add a MAC check for TRUNCATE

On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote: > On 2019-Sep-30, Joe Conway wrote: > > > I am not sure I will get to this today. I assume it is ok for me to move > > it forward e.g. next weekend, or is that not in line with commitfest rules? > > You can commit whatever patch when

Re: pg_waldump and PREPARE

On Fri, Nov 8, 2019 at 9:41 AM Michael Paquier wrote: > > On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote: > > Sorry for the long delay... Yes, I will update the patch if necessary. > > Fujii-san, are you planning to update this patch then? I have > switched it as waiting on author.

Re: Collation versioning

On Thu, Nov 7, 2019 at 10:20 PM Julien Rouhaud wrote: > Attached 4th patch handles default collation. I went with an > ignore_systempin flag in recordMultipleDependencies. Thanks for working on this! I haven't looked closely or tested yet, but this seems reasonable. Obviously it assumes that t

  1   2   >