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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: adding partitioned tables to publications

Hello Rafia, On Tue, Nov 5, 2019 at 12:41 AM Rafia Sabih wrote: > On Fri, 11 Oct 2019 at 08:06, Amit Langote wrote: >> Thanks for sharing this case. I hadn't considered it, but you're >> right that it should be handled sensibly. I have fixed table sync >> code to handle this case properly.

Re: dropdb --force

On Thu, Nov 7, 2019 at 11:29 AM Pavel Stehule wrote: > čt 7. 11. 2019 v 6:56 odesílatel Amit Kapila napsal: >> >> Okay, no problem. I will pick the previous version and do this. I >> will post the patch in a day or so for your review. > > > Thank you very much > Did you get a chance to look

Re: [Patch proposal] libpq portal support

On Thu, 7 Nov 2019 at 17:43, Sergei Fedorov wrote: > 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

Re: TestLib::command_fails_like enhancement

On Fri, 8 Nov 2019 at 06:28, Mark Dilger wrote: > > > 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

Re: [Patch proposal] libpq portal support

On Thu, 7 Nov 2019 at 17:43, Sergei Fedorov wrote: > 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

Handy describe_pg_lock function

Hi all I recently found the need to pretty-print the contents of pg_locks. So here's a little helper to do it, for anyone else who happens to have that need. pg_identify_object is far from adequate for the purpose. Reckon I should turn it into C and submit? CREATE FUNCTION describe_pg_lock(IN

Re: Exposure related to GUC value of ssl_passphrase_command

Hello. On Tue, Nov 5, 2019 at 5:15 PM Moon, Insung wrote: > Deal Hackers. > > The value of ssl_passphrase_command is set so that an external command > is called when the passphrase for decrypting an SSL file such as a > private key is obtained. > Therefore, easily set to work with echo

Re: Refactor parse analysis of EXECUTE command

po 4. 11. 2019 v 8:53 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-11-02 16:00, Tom Lane wrote: > > Peter Eisentraut writes: > >> This patch moves the parse analysis component of ExecuteQuery() and > >> EvaluateParams() into a new transformExecuteStmt() that

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

Le 07/11/2019 à 11:52, Etsuro Fujita a écrit : > 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

Re: Refactor parse analysis of EXECUTE command

On 2019-11-08 08:13, Pavel Stehule wrote: I dug into repository and found that transformExecuteStmt existed at the time of implementing PREPARE-EXECUTE statements(28e82066a1) and removed by the commit b9527e9840 which is related to plan-invalidation. git show -s --format=%B

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

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

pá 8. 11. 2019 v 6:39 odesílatel Amit Kapila napsal: > On Thu, Nov 7, 2019 at 11:29 AM Pavel Stehule > wrote: > > čt 7. 11. 2019 v 6:56 odesílatel Amit Kapila > napsal: > >> > >> Okay, no problem. I will pick the previous version and do this. I > >> will post the patch in a day or so for

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

Hello Tom, Thank you for your comments. On Fri, Nov 8, 2019 at 1:30 AM Tom Lane wrote: > failure: not only did you fail to add any commentary about the new macros, > but you removed most of the commentary that had been in-line in the > existing usages. I apologize for the insufficient

Re: cost based vacuum (parallel)

On Fri, Nov 8, 2019 at 9:39 AM Dilip Kumar wrote: > > I have done some experiments on this line. I have first produced a > case where we can show the problem with the existing shared costing > patch (worker which is doing less I/O might pay the penalty on behalf > of the worker who is doing more

Re: SPI refactoring

pá 8. 11. 2019 v 0:39 odesílatel Mark Dilger napsal: > 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,

Re: Refactor parse analysis of EXECUTE command

út 5. 11. 2019 v 11:28 odesílatel Kyotaro Horiguchi napsal: > Hello. > > At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote in > > On 2019-11-02 16:00, Tom Lane wrote: > > > Peter Eisentraut writes: > > >> This patch moves the parse analysis

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

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

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

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

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

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/

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

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

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

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

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

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

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

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

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

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

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

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: define bool in pgtypeslib_extern.h

On Fri, Nov 8, 2019 at 2:17 AM Tom Lane wrote: > > 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

Re: cost based vacuum (parallel)

On Fri, Nov 8, 2019 at 8:18 AM Masahiko Sawada wrote: > > On Wed, 6 Nov 2019 at 15:45, Amit Kapila wrote: > > > > On Tue, Nov 5, 2019 at 11:28 AM Amit Kapila wrote: > > > > > > On Mon, Nov 4, 2019 at 11:42 PM Andres Freund wrote: > > > > > > > > > > > > > The two approaches to solve this

Re: pg_waldump and PREPARE

On 08/11/2019 05:53, Fujii Masao wrote: 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

Re: pg_waldump and PREPARE

At Fri, 8 Nov 2019 09:53:07 +0900, Fujii Masao wrote in > 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

Re: adding partitioned tables to publications

Sorry about the delay. On Mon, Nov 4, 2019 at 8:00 PM Peter Eisentraut wrote: > This patch seems excessively complicated to me. Why don't you just add > the actual partitioned table to pg_publication_rel and then expand the > partition hierarchy in pgoutput (get_rel_sync_entry() or >

Re: pg_waldump and PREPARE

Hello. At Fri, 8 Nov 2019 08:23:41 +0500, Andrey Lepikhov wrote in > > Can I switch the status back to "Needs review"? > > Regards, > > > > One issue is that your patch provides small information. WAL errors > Investigation often requires information on xid, subxacts, >

Re: Collation versioning

On Fri, 2019-11-08 at 15:04 +1300, Thomas Munro wrote: > So we have three proposals: > > 1. Assume that pre-13 indexes that depend on collations are > potentially corrupted and complain until they are reindexed. This > could be done by having pg_upgrade run ALTER INDEX ... DEPENDS ON >

Re: Parallel leader process info in EXPLAIN

On Thu, Nov 7, 2019 at 11:37 PM Rafia Sabih wrote: > I was reviewing this patch and here are a few comments, Hi Rafia, Thanks! > +static void > +ExplainNodePerProcess(ExplainState *es, bool *opened_group, > + int worker_number, Instrumentation *instrument) > +{ > > A small description about

Re: cost based vacuum (parallel)

On Wed, 6 Nov 2019 at 15:45, Amit Kapila wrote: > > On Tue, Nov 5, 2019 at 11:28 AM Amit Kapila wrote: > > > > On Mon, Nov 4, 2019 at 11:42 PM Andres Freund wrote: > > > > > > > > > > The two approaches to solve this problem being discussed in that > > > > thread [1] are as follows: > > > > (a)

Re: [proposal] recovery_target "latest"

On 11/7/19 4:36 PM, Grigory Smolkin wrote: 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

Re: cost based vacuum (parallel)

On Fri, Nov 8, 2019 at 8:37 AM Amit Kapila wrote: >> On Fri, Nov 8, 2019 at 8:18 AM Masahiko Sawada > wrote: > > > > On Wed, 6 Nov 2019 at 15:45, Amit Kapila wrote: > > > > > > On Tue, Nov 5, 2019 at 11:28 AM Amit Kapila > > > wrote: > > > > > > > > On Mon, Nov 4, 2019 at 11:42 PM Andres

Re: Minimal logical decoding on standbys

On Thu, 7 Nov 2019 at 14:02, Rahila Syed wrote: > > 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. Thanks for picking up the patch review. Your reply somehow spawned a new

Re: pg_waldump and PREPARE

On 08/11/2019 09:26, Kyotaro Horiguchi wrote: Hello. At Fri, 8 Nov 2019 08:23:41 +0500, Andrey Lepikhov wrote in Can I switch the status back to "Needs review"? Regards, One issue is that your patch provides small information. WAL errors Investigation often requires information on xid,

RE: Planning counters in pg_stat_statements (using pgss_store)

On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > [0002 patch] > > In pgss_planner_hook: > > > > + /* calc differences of buffer counters. */ > > + bufusage = compute_buffer_counters(bufusage_start, > > pgBufferUsage); > > + > > + /* > > +

Re: Reorderbuffer crash during recovery

On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote: > > 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? >

Re: Remove HeapTuple and Buffer dependency for predicate locking functions

On Thu, Aug 8, 2019 at 6:53 AM Ashwin Agrawal wrote: >>> - I wonder if CheckForSerializableConflictOutNeeded() shouldn't have a >>> portion of it's code as a static inline. In particular, it's a shame >>> that we currently perform external function calls at quite the >>> frequency when

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

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

Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY

On Mon, Oct 28, 2019 at 05:17:52AM +, imai.yoshik...@fujitsu.com wrote: > According to the commit 3c8404649 [1], transactional update in > pg_index is not safe in non-MVCC catalog scans before PG9.4. > But it seems to me that we can use transactional update in pg_index > after the commit

Re: Collation versioning

On Fri, Nov 08, 2019 at 02:23:54PM +1300, Thomas Munro wrote: > Right, so this is basically a policy decision: do we assume that all > pre-13 indexes that depend on collations are potentially corrupted, or > assume that they are not? The "correct" thing to do would be to > assume they are

Re: Collation versioning

On Thu, Nov 7, 2019 at 1:27 AM Peter Eisentraut wrote: > As I was working on that lately, I came to the conclusion that we should > get *this* patch done first. Cool. Let's aim to get this into 13! > > * Some have expressed doubt that pg_depend is the right place for > > this; let's see if any

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

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

  1   2   >