Re: Checking return value of SPI_execute

On Wed, Nov 06, 2019 at 06:54:16AM +0100, Pavel Stehule wrote: > Is generic question if this exception should not be raised somewhere in > spi.c - maybe at SPI_execute. > > When you look to SPI_execute_plan, then checked errors has a character +/- > assertions. All SQL errors are ended by a except

Re: Removing pg_pltemplate and creating "trustable" extensions

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 superuser permissions (e.g., because it creates C functions) can now be installed by a non-superuser i

Re: [proposal] recovery_target "latest"

This seems to also be related to this discussion: I like this idea. I don't like the name "latest". What does that mean? Other documentation talks about the "end of the archive". What does that mean? It

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

On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote: > On Wed, Nov 6, 2019 at 1:13 PM Michael Paquier wrote: >> "postgres_fdw foreign tables" sounds weird to me. Could "foreign >> tables using postgres_fdw" be a better wording? I am wondering as >> well if we should not split this info

Re: pause recovery if pitr target not reached

On 2019-09-17 13:23, Leif Gunnar Erlandsen wrote: This patch allows PostgreSQL to pause recovery before PITR target is reached if recovery_target_time is specified. Btw., this discussion/patch seems related: https://www.postgresql.org/message-id/flat/a3f650f1-fb0f-c913-a000-a4671f12a013%40post

Re: Remove unused function argument

On 2019-10-30 06:51, vignesh C wrote: On Tue, Oct 29, 2019 at 2:51 PM Peter Eisentraut wrote: The cache_plan argument to ri_PlanCheck has not been used since e8c9fd5fdf768323911f7088e8287f63b513c3c6. I propose to remove it. That commit said "I left it alone in case there is any future need f

Re: Logical replication wal sender timestamp bug

On Tue, Nov 05, 2019 at 01:19:37PM +0900, Michael Paquier wrote: > On Sat, Nov 02, 2019 at 09:54:54PM -0400, Jeff Janes wrote: >> Filling out the timestamp after the message has already been sent is taking >> "as late as possible" a little too far. It results in every message having >> a zero time

Re: Allow CREATE OR REPLACE VIEW to rename the columns

2019-10-31 21:01 に Fujii Masao さんは書きました: On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed wrote: On Thu, Oct 31, 2019 at 12:32 PM Fujii Masao wrote: On Thu, Oct 31, 2019 at 1:42 PM Tom Lane wrote: > > Fujii Masao writes: > > Currently CREATE OR REPLACE VIEW command fails if the column names

Re: cost based vacuum (parallel)

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) Allow the parallel workers and master backend to have a shared > >

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

Hi Michael-san, On Wed, Nov 6, 2019 at 1:13 PM Michael Paquier wrote: > "postgres_fdw foreign tables" sounds weird to me. Could "foreign > tables using postgres_fdw" be a better wording? I am wondering as > well if we should not split this information into two parts: one for > the actual error

Re: Checking return value of SPI_execute

st 6. 11. 2019 v 5:28 odesílatel Michael Paquier napsal: > On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote: > > please find attached a patch fixing a problem previously discussed [1] > about > > the code inappropriately ignoring the return value from SPI_execute. > > > > I will be add

Re: progress report for ANALYZE

Hi Alvaro! On 2019/11/05 22:38, Alvaro Herrera wrote: On 2019-Nov-05, Tatsuro Yamada wrote: == [Session1] \! pgbench -i create statistics pg_ext1 (dependencies) ON aid, bid from pgbench_accounts; create statistics pg_ext2 (mcv) ON aid, bid from pgbench_accounts; create statistics p

Re: pgbench - refactor init functions with buffers

Hello Andres, Attached v3 shorten some lines and adds "append_tablespace". A v4 which just extends the patch to newly added 'G'. I'd prefer not to expand the use of pqexpbuffer in more places, and instead rather see this use StringInfo, now that's also available to frontend programs. Fran

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

Hello Tom, Thomas, and Andrew, > Tom> That commit presumes that floats follow the IEEE bitwise > Tom> representation, I think; > > Correct. (It notably does _not_ make any assumptions about how floating > point arithmetic or comparisons work - all the computation is done in > integers.) > > Tom

Re: Include RELKIND_TOASTVALUE in get_relkind_objtype

On Tue, Nov 05, 2019 at 01:41:28PM -0500, Tom Lane wrote: > Pushed like that, then. Thanks for the commit. -- Michael signature.asc Description: PGP signature

Re: Checking return value of SPI_execute

On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote: > please find attached a patch fixing a problem previously discussed [1] about > the code inappropriately ignoring the return value from SPI_execute. > > I will be adding this to https://commitfest.postgresql.org/26/ > shortly. Yes, thi

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

On Wed, Nov 06, 2019 at 12:57:10PM +0900, Etsuro Fujita wrote: > Thanks for the patch! I added the commit message. Does that make > sense? If there are no objections, I'll apply the patch to all > supported branches. "postgres_fdw foreign tables" sounds weird to me. Could "foreign tables using

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

> "Tom" == Tom Lane writes: >> But PostgreSQL effectively requires IEEE 754 since commit >> 02ddd499322ab6f2f0d58692955dc9633c2150fc, right? Tom> That commit presumes that floats follow the IEEE bitwise Tom> representation, I think; Correct. (It notably does _not_ make any assumptions a

Re: Duplicate entries in pg_depend after REINDEX CONCURRENTLY

On Tue, Nov 05, 2019 at 06:26:56PM -0500, Bruce Momjian wrote: > Are there any bad effects of this bug on PG 12? Not that I could guess, except a bloat of pg_depend... The more you issue REINDEX CONCURRENTLY on an index, the more duplicated entries accumulate in pg_depend as the dependencies of t

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

Hi Gilles, On Tue, Nov 5, 2019 at 8:41 PM Gilles Darold wrote: > I have attached a single patch that include Etsuro Fujita's patch on > postgres_fdw documentation and mine on postgres_fdw error message with > the precision that it comes from postgres_fdw. The modification about > prepared transac

Re: The command tag of "ALTER MATERIALIZED VIEW RENAME COLUMN"

On Tue, Nov 5, 2019 at 11:19 PM Tom Lane wrote: > > Fujii Masao writes: > > I'm thinking to commit the patch. But I have one question; is it ok to > > back-patch? Since the patch changes the command tags for some commands, > > for example, which might break the existing event trigger functions >

Re: cost based vacuum (parallel)

Greetings, * Amit Kapila (amit.kapil...@gmail.com) wrote: > On Tue, Nov 5, 2019 at 1:42 AM Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > That's quite doable independent of parallelism, as we don't have tables > > > or indexes spanning more than one tablespace. True,

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

Thomas Munro writes: > On Wed, Nov 6, 2019 at 3:33 PM Yuya Watari wrote: >> However, this behavior depends on the platform architecture. As you >> have said, C language does not always follow IEEE-754. I think adding >> explicit checking of NaN is necessary. > I'm curious about this point. C ma

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

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 each backend, when shutting down > immediately. Currently the log output

RE: Global shared meta cache

>From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] >If the assumption that working set of backend (set of tables accessed by this >session) >is small enough to fit in backend's memory is true, then global meta cache is >not >needed at all: it is enough to limit size of local cache and

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

On Wed, Nov 6, 2019 at 3:33 PM Yuya Watari wrote: > However, this behavior depends on the platform architecture. As you > have said, C language does not always follow IEEE-754. I think adding > explicit checking of NaN is necessary. I'm curious about this point. C may not require IEEE 754 (for e

Re: cost based vacuum (parallel)

On Wed, Nov 6, 2019 at 7:55 AM Andres Freund wrote: > > Hi, > > On 2019-11-06 07:53:09 +0530, Amit Kapila wrote: > > As per feedback in this thread, it seems that for now, it is better, > > if we can allow a parallel vacuum only when I/O throttling is not > > enabled. We can later extend it based

Re: pgbench - refactor init functions with buffers

Hi, On 2019-10-24 08:33:06 +0200, Fabien COELHO wrote: > Attached v3 shorten some lines and adds "append_tablespace". I'd prefer not to expand the use of pqexpbuffer in more places, and instead rather see this use StringInfo, now that's also available to frontend programs. Greetings, Andres Fre

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

Hello Tom, Thank you for replying. On Wed, Nov 6, 2019 at 12:04 AM Tom Lane wrote: > > Yuya Watari writes: > > The added macro FLOAT8_FITS_IN_INT32() does not check NaN explicitly, > > but it sufficiently handles the case. > > Really? I don't think anything is guaranteed about how a NaN will >

Re: pgbench - extend initialization phase control

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. > > Because it removes one decla

Re: cost based vacuum (parallel)

Hi, On 2019-11-06 07:53:09 +0530, Amit Kapila wrote: > As per feedback in this thread, it seems that for now, it is better, > if we can allow a parallel vacuum only when I/O throttling is not > enabled. We can later extend it based on feedback from the field once > the feature starts getting used

Re: cost based vacuum (parallel)

On Tue, Nov 5, 2019 at 1:42 AM Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > > That's quite doable independent of parallelism, as we don't have tables > > or indexes spanning more than one tablespace. True, you could then make > > the processing of an individual vacuum fa

Re: v12.0: ERROR: could not find pathkey item to sort

On Wed, Nov 6, 2019 at 1:51 AM Tom Lane wrote: > Amit Langote writes: > > I have been thinking maybe add_child_rel_equivalences() doesn't need > > to translate EC members that reference multiple appendrels, because > > there top_parent_relids is always a singleton set, whereas em_relids > > of su

Checking return value of SPI_execute

Hackers, please find attached a patch fixing a problem previously discussed [1] about the code inappropriately ignoring the return value from SPI_execute. I will be adding this to https://commitfest.postgresql.org/26/ shortly. Mark Dilger [1] https://www.postgresql.org/message-id/24753.15581

Re: Make StringInfo available to frontend code.

Hi, On 2019-11-02 23:57:06 +0100, Daniel Gustafsson wrote: > > On 2 Nov 2019, at 03:21, Andres Freund wrote: > > On 2019-11-01 23:19:33 +0100, Daniel Gustafsson wrote: > > >> + * StringInfo provides an extensible string data type. It can be used to > >> > >> It might be useful to point out the

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

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 each backend, when shutting down immediately. Currently the log output for that, with just two sessions connected, is the follo

Re: Duplicate entries in pg_depend after REINDEX CONCURRENTLY

On Mon, Oct 28, 2019 at 03:01:31PM +0900, Michael Paquier wrote: > On Fri, Oct 25, 2019 at 03:43:18PM +0900, Michael Paquier wrote: > > Attached is a patch to fix the issue. As we know that the old index > > will have a definition and dependencies that match with the old one, I > > think that we s

Re: [HACKERS] WAL logging problem in 9.4.3?

On Tue, Nov 05, 2019 at 04:16:14PM -0500, Robert Haas wrote: > On Fri, Oct 25, 2019 at 9:21 AM Kyotaro Horiguchi > wrote: > > This is the fixed verison v22. > > I'd like to offer a few thoughts on this thread and on these patches, > which is now more than 4 years old and more than 150 messages i

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

Hi, On 2019-10-29 23:32:09 -0700, Andres Freund wrote: > On 2019-10-29 16:31:11 -0400, Tom Lane wrote: > > Andres Freund writes: > > > one of the most frequent conflicts I see is that two patches add files > > > to OBJS (or one of its other spellings), and there are conflicts because > > > anothe

Re: deferrable FK constraints on partitioned rels

On 2019-Nov-05, Alvaro Herrera wrote: > While messing around, I noticed that SET CONSTRAINTS ... DEFERRED > does not work with partitioned tables. I had some code to cover this > case, but it has a bug that prevents it from working at all: the sanity > check that verifies whether triggers exist f

Re: pgbench - extend initialization phase control

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. Because it removes one declaration and reduces the scope of one variable? If there is the reason why t

Re: [HACKERS] WAL logging problem in 9.4.3?

On Fri, Oct 25, 2019 at 9:21 AM Kyotaro Horiguchi wrote: > This is the fixed verison v22. I'd like to offer a few thoughts on this thread and on these patches, which is now more than 4 years old and more than 150 messages in length. First, I'd like to restate my understanding of the problem just

Re: Why overhead of SPI is so large?

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, there are lot of > application that depends on this behave. > > It is well know trick how to

Re: alternative to PG_CATCH

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 error context stack, which means that any error thrown within that s

deferrable FK constraints on partitioned rels

While messing around, I noticed that SET CONSTRAINTS ... DEFERRED does not work with partitioned tables. I had some code to cover this case, but it has a bug that prevents it from working at all: the sanity check that verifies whether triggers exist fails. The attached patch fixes this problem: i

Re: [Proposal] Arbitrary queries in postgres_fdw

On Tue, Nov 05, 2019 at 11:09:34AM +0100, rto...@carto.com wrote: > On Sun, Oct 27, 2019 at 7:07 PM David Fetter wrote: > > There's a SQL MED standard feature for CREATE ROUTINE MAPPING that > > does something similar to this. Might it be possible to incorporate > > it into the previous patch tha

Re: Include RELKIND_TOASTVALUE in get_relkind_objtype

Michael Paquier writes: > On Mon, Nov 04, 2019 at 03:31:27PM -0500, Tom Lane wrote: >> I'd rather do something like the attached, which makes it more of an >> explicit goal that we won't fail on bad input. (As written, we'd only >> fail on bad classId, which is a case that really shouldn't happen

Re: Standard-conforming datetime years parsing

On 05/11/2019 02:45, Alexander Korotkov wrote: > 3) Do we like to change behavior to_date()/to_timestamp()? Or just > jsonpath .datetime() and future CAST(... AS ... FORMAT ...) defined in > SQL 2016? I don't want to hijack this thread, but I would like the CAST feature to call to_timestamp() an

Re: Removing unneeded self joins

v.21 in attechment fix small bug: Now we move all non-mergejoinable clauses from joininfo to base restrict info because of the relation will not be joined. On 30/09/2019 13:29, Konstantin Knizhnik wrote: Slightly refactored version of the patch with more comments. -- Andrey Lepikhov Postgr

Re: d25ea01275 and partitionwise join

Amit Langote writes: > On Mon, Oct 14, 2019 at 5:02 AM Justin Pryzby wrote: >> I can't say much about the patch; there's a little typo: >> "The nullability of inner relation keys prevents them to" >> ..should say "prevent them from". > Thanks, will fix. Just to leave a breadcrumb in this thread

Re: v12.0: ERROR: could not find pathkey item to sort

Amit Langote writes: > On Sun, Nov 3, 2019 at 4:43 AM Tom Lane wrote: >> Also, I thought we should try to put more conditions on whether we >> invoke add_child_join_rel_equivalences at all. In the attached I did >> if ((enable_partitionwise_join || enable_partitionwise_aggregate) && >>

Re: [Proposal] Arbitrary queries in postgres_fdw

> On Fri, Oct 25, 2019 at 12:38 PM Tom Lane wrote: > > end of things. And allowing arbitrary queries to go over a postgres_fdw > > connection would be absolutely disastrous from a debuggability and > > maintainability standpoint, because they might change the remote > > session's state in ways th

Re: segmentation fault when cassert enabled

On Fri, 25 Oct 2019 12:28:38 -0400 Tom Lane wrote: > Jehan-Guillaume de Rorthais writes: > > When investigating for the bug reported in thread "logical replication - > > negative bitmapset member not allowed", I found a way to seg fault > > postgresql only when cassert is enabled. > > ... > > I

Re: pgbench - extend initialization phase control

On Thu, Oct 31, 2019 at 11:54 PM Fabien COELHO wrote: > > > Hello Masao-san, > > > + snprintf(sql, sizeof(sql), > > + "insert into pgbench_branches(bid,bbalance) " > > + "select bid, 0 " > > + "from generate_series(1, %d) as bid", scale); > > > > "scale" should be "nbranches * scale". > > Yep, eve

Re: Do we have a CF manager for November?

Hi Michael, On Tue, Nov 5, 2019 at 7:18 AM Michael Paquier wrote: > On Mon, Nov 04, 2019 at 10:54:52AM -0500, Tom Lane wrote: > > It's time to start the next commitfest. I seem to recall somebody > > saying back in September that they'd run the next one, but I forget > > who. Anyway, we need

Re: cost based vacuum (parallel)

On Tue, Nov 5, 2019 at 8:49 PM Andres Freund wrote: > > Hi, > > On November 5, 2019 7:16:41 AM PST, Dilip Kumar wrote: > >On Tue, Nov 5, 2019 at 2:40 PM Amit Kapila > >wrote: > >> > >> On Mon, Nov 4, 2019 at 11:58 PM Andres Freund > >wrote: > >> > > >> > Hi, > >> > > >> > On 2019-11-04 12:59:02

Re: [Patch] Optimize dropping of relation buffers using dlist

Hi Kirk, On Tue, Nov 05, 2019 at 09:58:22AM +, k.jami...@fujitsu.com wrote: Hi, Another one that I'd need feedback of is the use of new dlist operations for this cached buffer list. I did not use in this patch the existing Postgres dlist architecture (ilist.h) because I want to save

Re: cost based vacuum (parallel)

Hi, On November 5, 2019 7:16:41 AM PST, Dilip Kumar wrote: >On Tue, Nov 5, 2019 at 2:40 PM Amit Kapila >wrote: >> >> On Mon, Nov 4, 2019 at 11:58 PM Andres Freund >wrote: >> > >> > Hi, >> > >> > On 2019-11-04 12:59:02 -0500, Jeff Janes wrote: >> > > On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila >

Re: cost based vacuum (parallel)

On Tue, Nov 5, 2019 at 2:40 PM Amit Kapila wrote: > > On Mon, Nov 4, 2019 at 11:58 PM Andres Freund wrote: > > > > Hi, > > > > On 2019-11-04 12:59:02 -0500, Jeff Janes wrote: > > > On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila > > > wrote: > > > > > > > For parallel vacuum [1], we were discussing

Re: v12 and pg_restore -f-

On 2019-Nov-05, Tom Lane wrote: > Sure, because there wasn't any practical way to provide a transition > period. I think that case is entirely not comparable to this one, > either as to whether a transition period is possible, or as to whether > the benefits of the change merit forced breakage.

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

Yuya Watari writes: > The added macro FLOAT8_FITS_IN_INT32() does not check NaN explicitly, > but it sufficiently handles the case. Really? I don't think anything is guaranteed about how a NaN will compare when using C's non-NaN-aware comparison operators. My thought about this was to annotate

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On 2019-Oct-08, Craig Ringer wrote: > On Fri, 12 Jul 2019 at 01:27, Robert Haas wrote: > > > We have steadfastly refused to provide protocol-level tools for things > > like "please change my user ID, and don't let anyone change it again > > via SQL," and that's a huge problem for things like con

Re: v12 and pg_restore -f-

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> In this case, not in the least: we would simply be imposing the sort > >> of *orderly* feature introduction that I thought was the plan from > >> the very beginning [1]. That

Re: v12 and pg_restore -f-

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> In this case, not in the least: we would simply be imposing the sort >> of *orderly* feature introduction that I thought was the plan from >> the very beginning [1]. That is, first make "-f -" available, and >> make it required onl

Re: v12 and pg_restore -f-

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > In this case, not in the least: we would simply be imposing the sort > of *orderly* feature introduction that I thought was the plan from > the very beginning [1]. That is, first make "-f -" available, and > make it required only in some later v

Re: v12 and pg_restore -f-

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2019-11-05 15:11, Stephen Frost wrote: > >We don't guarantee this kind of compatibility between major versions. > > We do generally ensure compatibility of client side tools across major > versions. I don't recall a cas

Re: v12 and pg_restore -f-

Stephen Frost writes: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 2019-11-04 15:53, Alvaro Herrera wrote: No, I'm not proposing a full revert. But there's certainly room to consider reverting the part that says you*must* write "-f -" to get output to stdou

Re: v12 and pg_restore -f-

On 2019-11-05 15:11, Stephen Frost wrote: We don't guarantee this kind of compatibility between major versions. We do generally ensure compatibility of client side tools across major versions. I don't recall a case where we broke compatibility in a comparable way without a generous transitio

Re: The command tag of "ALTER MATERIALIZED VIEW RENAME COLUMN"

Fujii Masao writes: > I'm thinking to commit the patch. But I have one question; is it ok to > back-patch? Since the patch changes the command tags for some commands, > for example, which might break the existing event trigger functions > using TG_TAG if we back-patch it. Or we should guarantee th

Re: v12 and pg_restore -f-

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2019-11-04 15:53, Alvaro Herrera wrote: > >>No, I'm not proposing a full revert. But there's certainly room to > >>consider reverting the part that says you*must* write "-f -" to get > >>output to stdout. > >I don't thi

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On 2019-10-12 05:05, Tom Lane wrote: Andres Freund writes: On 2019-10-11 16:30:17 -0400, Robert Haas wrote: But, if it does need to be changed, it seems like a terrible idea to allow it to be done via SQL. Otherwise, the user can break the driver by using SQL to set the list to something that

Re: v12 and pg_restore -f-

On 2019-11-04 15:53, Alvaro Herrera wrote: No, I'm not proposing a full revert. But there's certainly room to consider reverting the part that says you*must* write "-f -" to get output to stdout. I don't think this will buy us anything, if we get past branches updated promptly. Users with wi

Re: progress report for ANALYZE

On 2019-Nov-05, Tatsuro Yamada wrote: > == > [Session1] > \! pgbench -i > create statistics pg_ext1 (dependencies) ON aid, bid from pgbench_accounts; > create statistics pg_ext2 (mcv) ON aid, bid from pgbench_accounts; > create statistics pg_ext3 (ndistinct) ON aid, bid from pgbench_ac

Re: v12 and pg_restore -f-

On 2019-Nov-04, Alvaro Herrera wrote: > On 2019-Nov-04, Stephen Frost wrote: > > > > Alvaro Herrera writes: > > > > > +1 for this, FWIW. Let's get it done before next week minors. Is > > > > anybody writing a patch? If not, I can do it. > > Turns out that this is a simple partial cherry-pic

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Sun, 3 Nov 2019 at 19:40, Thomas Munro wrote: > On Wed, Oct 16, 2019 at 6:49 PM Dave Cramer wrote: > > Here's an updated patch that addresses some of Andres' concerns > specifically does not use strtok. > > Hi Dave, > > I think you need to s/strncasecmp/pg_strncasecmp/ to make this build on >

Re: Binary support for pgoutput plugin

On Sun, 3 Nov 2019 at 21:47, Thomas Munro wrote: > On Thu, Oct 31, 2019 at 3:03 AM Dave Cramer wrote: > > Ok, I've rebased and reverted logicalrep_read_insert > > Hi Dave, > > From the code style police (actually just from cfbot, which is set up > to complain about declarations after statements,

Re: log bind parameter values on error

Hi Anders and Alvaro, I must have missed this conversation branch when sending in v011. Sorry about that. > I think it might be worthwhile to cross-reference > log_min_error_statement, as log_parameters_on_error will only take effect when the > statement is logged due to log_min_error_statemen

Re: progress report for ANALYZE

Hi Alvaro, vignesh, I rebased the patch on 2a4d96eb, and added new column "ext_compute_count" in pg_stat_progress_analyze vie to report a number of computing extended stats. It is like a "index_vacuum_count" in vacuum progress reporter or "index_rebuild_count" in cluster progress reporter. :) Pl

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

Hello Tom and Horiguchi-san, On Tue, Nov 5, 2019 at 1:59 PM Kyotaro Horiguchi wrote: > At Mon, 04 Nov 2019 12:53:48 -0500, Tom Lane wrote in > > I do concur with creating a macro that encapsulates a correct version > > of this test, maybe like > > > > #define DOUBLE_FITS_IN_INT64(num) \ > >

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

Hi Esturo, Le 05/11/2019 à 10:35, Etsuro Fujita a écrit : > Hi Gilles, > > On Sat, Nov 2, 2019 at 1:29 AM Gilles Darold wrote: >> As per the following code, t1 is a remote table through postgres_fdw: >> test=# BEGIN; >> BEGIN >> test=# SELECT * FROM t1; >> ... >> >> test=# PREPARE TRANSACTION 'gx

Re: tableam vs. TOAST

>From the stack trace shared by Prabhat, I understand that the checkpointer process panicked due to one of the following two reasons: 1) The fsync() failed in the first attempt itself and the reason for the failure was not due to file being dropped or truncated i.e. fsync failed with the error oth

Re: [proposal] recovery_target "latest"

Attached new version of a patch with TAP test. On 11/5/19 11:51 AM, Grigory Smolkin wrote: Thank you for you interest in this topic! On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote: Hello. At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin wrote in Hello, hackers! I`d like to propose a new a

Re: Refactor parse analysis of EXECUTE command

Hello. At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut wrote in > 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 is called from > >> tran

Re: [Proposal] Arbitrary queries in postgres_fdw

On Sun, Oct 27, 2019 at 7:07 PM David Fetter wrote: > There's a SQL MED standard feature for CREATE ROUTINE MAPPING that > does something similar to this. Might it be possible to incorporate > it into the previous patch that implemented that feature? Supporting CREATE ROUTINE MAPPING goes a leve

RE: [Patch] Optimize dropping of relation buffers using dlist

Hi, > Another one that I'd need feedback of is the use of new dlist operations > for this cached buffer list. I did not use in this patch the existing > Postgres dlist architecture (ilist.h) because I want to save memory space > as much as possible especially when NBuffers become large. Both d

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

Hi Gilles, On Sat, Nov 2, 2019 at 1:29 AM Gilles Darold wrote: > As per the following code, t1 is a remote table through postgres_fdw: > test=# BEGIN; > BEGIN > test=# SELECT * FROM t1; > ... > > test=# PREPARE TRANSACTION 'gxid1'; > ERROR: cannot prepare a transaction that modified remote tabl

Re: cost based vacuum (parallel)

On Tue, Nov 5, 2019 at 1:12 AM Andres Freund wrote: > On 2019-11-04 14:33:41 -0500, Stephen Frost wrote: > > > I've been wondering if the accounting system should consider the cost > > per tablespace when there's multiple tablespaces involved, instead of > > throttling the overall process without

Re: cost based vacuum (parallel)

On Mon, Nov 4, 2019 at 11:58 PM Andres Freund wrote: > > Hi, > > On 2019-11-04 12:59:02 -0500, Jeff Janes wrote: > > On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila wrote: > > > > > For parallel vacuum [1], we were discussing what is the best way to > > > divide the cost among parallel workers but we

Re: [proposal] recovery_target "latest"

Thank you for you interest in this topic! On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote: Hello. At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin wrote in Hello, hackers! I`d like to propose a new argument for recovery_target parameter, which will stand to recovering until all available WAL

Re: Wrong value in metapage of GIN INDEX.

Dear Tom Lane. On Tue, Nov 5, 2019 at 3:55 AM Tom Lane wrote: > > "imai.yoshik...@fujitsu.com" writes: > > Moon-san, kuroda.keisuke-san > > On Thu, Aug 29, 2019 at 8:20 AM, Moon, Insung wrote: > >> The patch is very simple. > >> Fix to increase the value of nEntries only when a non-duplicate GIN

Exposure related to GUC value of ssl_passphrase_command

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 "passphrase" or call to another get of passphrase application. I think that this