Re: Possible performance regression in version 10.1 with pgbench read-write tests.

On Fri, Jul 20, 2018 at 7:56 AM, Tom Lane wrote: > Alvaro Herrera writes: >> On 2018-Jul-19, Amit Kapila wrote: >>> It appears so. I think we should do something about it as the >>> regression is quite noticeable. > > It's not *that* noticeable, as I failed to demonstrate any performance >

Re: Make foo=null a warning by default.

On Thu, Jul 19, 2018 at 06:37:39AM -0400, Fabien COELHO wrote: > > Hello David, > > All is nearly well, although "make docs" found a typo. I should have tested > doc building before, sorry for this new round which should have been > avoided. > > "null_expression" > > s///; Fixed. > Also,

Re: de-deduplicate code in DML execution hooks in postgres_fdw

On Thu, Jul 19, 2018 at 05:35:11PM +0900, Etsuro Fujita wrote: > +1 for the general idea. (Actually, I also thought the same thing before.) > But since this is definitely a matter of PG12, ISTM that it's wise to work > on this after addressing the issue in [1]. My concern is: if we do this >

Re: [HACKERS] Restricting maximum keep segments by repslots

On Fri, Jul 20, 2018 at 10:13:58AM +0900, Masahiko Sawada wrote: > Also, I'm not sure it's a good way to show the distance as LSN. LSN is > a monotone increasing value but in your patch, a value of the "remain" > column can get decreased. If that can happen, I think that this is a very, very bad

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Andres Freund writes: > I'm a bit hesitant to just revert without further evaluation - it's just > about as likely we'll regress on other hardware / kernel > versions. I looked into the archives for the discussion that led up to ecb0d20a9, and found it here:

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Hi Andres, On Fri, Jul 20, 2018 at 1:21 AM, Andres Freund wrote: > Hi, > > On 2018-01-24 00:06:44 +0530, Mithun Cy wrote: > > Server: > > ./postgres -c shared_buffers=8GB -N 200 -c min_wal_size=15GB -c > > max_wal_size=20GB -c checkpoint_timeout=900 -c > > maintenance_work_mem=1GB -c

Re: partition tree inspection functions

Hi Jesper, On 2018/07/19 23:18, Jesper Pedersen wrote: > I'm thinking about how to best use these functions to generate a graph > that represents the partition hierarchy. > > What about renaming pg_partition_tree_tables() to pg_partition_children(), > and have it work like > > select * from

Re: [HACKERS] Restricting maximum keep segments by repslots

On Fri, Jul 13, 2018 at 5:40 PM, Kyotaro HORIGUCHI wrote: > Hello. > > At Wed, 11 Jul 2018 15:09:23 +0900, Masahiko Sawada > wrote in >> On Mon, Jul 9, 2018 at 2:47 PM, Kyotaro HORIGUCHI >> >> min_keep_lsn in pg_replication_slots currently shows the same value in >> every slots but I felt

Re: documentation about explicit locking

Horiguchi-san, Thanks for taking a look. On 2018/07/19 18:23, Kyotaro HORIGUCHI wrote: > Hello. > > At Thu, 19 Jul 2018 13:17:14 +0900, Amit Langote wrote: >> On 2018/07/18 18:30, Peter Eisentraut wrote: >>> The reason this is mentioned is that CREATE COLLATION takes a SHARE ROW >>> EXCLUSIVE

Re: missing toast table for pg_policy

On 2018-07-20 08:56:32 +0900, Michael Paquier wrote: > On Thu, Jul 19, 2018 at 04:50:06PM -0700, Andres Freund wrote: > > On 2018-07-20 08:46:50 +0900, Michael Paquier wrote: > >> On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote: > >> I have found the argument about circular dependencies

Re: missing toast table for pg_policy

On Thu, Jul 19, 2018 at 04:50:06PM -0700, Andres Freund wrote: > On 2018-07-20 08:46:50 +0900, Michael Paquier wrote: >> On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote: >> I have found the argument about circular dependencies rather sensible >> FWIW. So at the end it seems to me that we

Re: missing toast table for pg_policy

On 2018-07-20 08:46:50 +0900, Michael Paquier wrote: > On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote: > > Andres Freund writes: > >> FWIW, I was off the last few days. I personally think the reasoning to > >> leave out pg_class, pg_index etc. is bad. We should just make them work > >>

Re: missing toast table for pg_policy

On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote: > Andres Freund writes: >> FWIW, I was off the last few days. I personally think the reasoning to >> leave out pg_class, pg_index etc. is bad. We should just make them work >> and create toast tables as well. > > If it's easy to make

Re: missing toast table for pg_policy

Hi, On 2018-07-20 07:49:11 +0900, Michael Paquier wrote: > On Wed, Jul 18, 2018 at 01:02:35PM +0900, Michael Paquier wrote: > > So, I have been playing with the previous patch and tortured it through > > a couple of upgrade scenarios, where it proves to work. Attached is an > > updated patch

Re: pread() and pwrite()

On Thu, Jul 12, 2018 at 1:55 PM, Thomas Munro wrote: > I guess the only remaining reason to use FileSeek() is to get the file > size? So I wonder why SEEK_SET remains valid in the patch... if my > suspicion is correct that only SEEK_END still has a reason to exist, > perhaps we should just kill

Re: missing toast table for pg_policy

On Wed, Jul 18, 2018 at 01:02:35PM +0900, Michael Paquier wrote: > So, I have been playing with the previous patch and tortured it through > a couple of upgrade scenarios, where it proves to work. Attached is an > updated patch which adds toast tables except for pg_class, pg_attribute, > pg_index

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

Hi, On 2018-07-19 12:42:08 -0700, Andres Freund wrote: > I actually think the balance of all the solutions discussed in this > thread seem to make neutering pruning *a bit* by far the most palatable > solution. We don't need to fully prevent removal of such tuple chains, > it's sufficient that we

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Thu, 19 Jul 2018 at 21:04, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > > * Just to clarify - the iterating through all the partitions, is it the > > > best > > > way of finding matching ranges? Correct me if I'm wrong, but from what > > > I see > > > in the comments for

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 01:46:12PM -0700, Andres Freund wrote: > On 2018-07-19 15:42:46 -0500, Nico Williams wrote: > > Yes, but that's in libc. None of that is in the PG code itself. > > That's simply entirely completely wrong. PG has a good chunk of memory > management layers (facilitating

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2018-07-19 15:44:23 -0500, Nico Williams wrote: > On Thu, Jul 19, 2018 at 03:42:46PM -0500, Nico Williams wrote: > > On Thu, Jul 19, 2018 at 01:38:52PM -0700, Andres Freund wrote: > > > Uhm, this'd already require a fair bit of threadsafety. Like at least > > > all of the memory allocator /

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2018-07-19 15:42:46 -0500, Nico Williams wrote: > On Thu, Jul 19, 2018 at 01:38:52PM -0700, Andres Freund wrote: > > On 2018-07-19 15:27:06 -0500, Nico Williams wrote: > > > No, the other thread does NOT continue to do whatever -- it > > > blocks/sleeps forever waiting for the coming exit(3). >

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 03:42:46PM -0500, Nico Williams wrote: > On Thu, Jul 19, 2018 at 01:38:52PM -0700, Andres Freund wrote: > > Uhm, this'd already require a fair bit of threadsafety. Like at least > > all of the memory allocator / context code. Nor is having threads > > around unproblematic

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 01:38:52PM -0700, Andres Freund wrote: > On 2018-07-19 15:27:06 -0500, Nico Williams wrote: > > No, the other thread does NOT continue to do whatever -- it > > blocks/sleeps forever waiting for the coming exit(3). > > > > I.e., quickdie() would look like this: > > > >

Re: Recovery performance of standby for multiple concurrent truncates on large tables

On 2018-07-19 00:53:14 +, Jamison, Kirk wrote: > Hi, > Thank you for your replies. > > On Tue, July 10, 2018 4:15 PM, Andres Freund wrote: > >I think you'd run into a lot of very hairy details with this approach. > >Consider what happens if client processes need fresh buffers and need to >

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hi, On 2018-07-19 15:27:06 -0500, Nico Williams wrote: > No, the other thread does NOT continue to do whatever -- it > blocks/sleeps forever waiting for the coming exit(3). > > I.e., quickdie() would look like this: > > /* Marshall info in to an automatic */ > struct

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 01:35:02PM -0700, Andres Freund wrote: > On 2018-07-19 15:17:26 -0500, Nico Williams wrote: > > You can create that thread with a really small stack given that its only > > purpose is to do this error reporting and exit. > > You still have a full kernel process backing it,

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hi, On 2018-07-19 16:16:31 -0400, Tom Lane wrote: > Nico Williams writes: > > I dunno if it is or isn't helpful. But I do know that this must be done > > in an async-signal-safe way. > > I haven't actually heard a convincing reason why that's true. As per > the previous discussion, if we

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2018-07-19 15:17:26 -0500, Nico Williams wrote: > On Thu, Jul 19, 2018 at 01:10:14PM -0700, Andres Freund wrote: > > On 2018-07-19 15:04:15 -0500, Nico Williams wrote: > > > Besides making ereport() async-signal-safe, which is tricky, you could > > > write(2) the arguments to a pipe that

Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM)

Hi, On 2018-07-18 14:34:34 -0400, Robert Haas wrote: > On Sat, Jul 7, 2018 at 4:01 PM, Andres Freund wrote: > > FWIW, here's a rebased version of this patch. Could probably be polished > > further. One might argue that we should do a bit more wide ranging > > changes, to convert scanint8 and

Re: Bug in gin insert redo code path during re-compression of empty gin data leaf pages

Thu, Jul 19, 2018 at 9:29 PM Alvaro Herrera wrote: > On 2018-Jul-19, Alexander Korotkov wrote: > > > Pushed, thanks! > > I think you missed branch REL_11_STABLE ... > Thank you for noticing! I also have just discovered that while looking at buildfarm. Fixed. -- Alexander Korotkov

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 01:10:14PM -0700, Andres Freund wrote: > On 2018-07-19 15:04:15 -0500, Nico Williams wrote: > > Besides making ereport() async-signal-safe, which is tricky, you could > > write(2) the arguments to a pipe that another thread in the same process > > is reading from and which

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Nico Williams writes: > I dunno if it is or isn't helpful. But I do know that this must be done > in an async-signal-safe way. I haven't actually heard a convincing reason why that's true. As per the previous discussion, if we happen to service the SIGQUIT at an unfortunate moment, we might

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2018-07-19 14:54:52 -0500, Nico Williams wrote: > On Thu, Jul 19, 2018 at 12:20:53PM -0700, Andres Freund wrote: > > On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > > > Ugh. Yeah, in wal_quickdie, and other aux process *_quickdie() handlers, I > > > agree we should just _exit(2). All

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2018-07-19 15:04:15 -0500, Nico Williams wrote: > Besides making ereport() async-signal-safe, which is tricky, you could > write(2) the arguments to a pipe that another thread in the same process > is reading from and which will then call ereport() and exit(3). This > would be less work if

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hi, On 2018-07-19 15:49:35 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > >> The regular backend's quickdie() function is more tricky. It should also > >> call _exit(2) rather than exit(2). But it also tries to ereport a WARNING, > >>

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 04:04:01PM -0400, Tom Lane wrote: > Nico Williams writes: > > What I'd do is have a volatile sig_atomic_t in_signal_handler_context > > variable to indicate that we're dying, and then when that is non-zero, > > ereport() and friends could use all-async-signal-safe

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jun 22, 2017 at 03:10:31PM -0400, Tom Lane wrote: > Andres Freund writes: > > Or, probably more robust: Simply _exit(2) without further ado, and rely > > on postmaster to output an appropriate error message. Arguably it's not > > actually useful to see hundreds of "WARNING: terminating

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Nico Williams writes: > What I'd do is have a volatile sig_atomic_t in_signal_handler_context > variable to indicate that we're dying, and then when that is non-zero, > ereport() and friends could use all-async-signal-safe codepaths. I eagerly await your patch with an async-safe implementation

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 03:49:35PM -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > >> The regular backend's quickdie() function is more tricky. It should also > >> call _exit(2) rather than exit(2). But it also tries to ereport a

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Alvaro Herrera writes: > On 2018-Jul-19, Amit Kapila wrote: >> It appears so. I think we should do something about it as the >> regression is quite noticeable. It's not *that* noticeable, as I failed to demonstrate any performance difference before committing the patch. I think some more

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Jul 19, 2018 at 12:20:53PM -0700, Andres Freund wrote: > On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > > Ugh. Yeah, in wal_quickdie, and other aux process *_quickdie() handlers, I > > agree we should just _exit(2). All we want to do is to exit the process > > immediately. > >

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Hi, On 2018-07-19 15:39:44 -0400, Alvaro Herrera wrote: > On 2018-Jul-19, Amit Kapila wrote: > > > On Thu, Feb 22, 2018 at 7:55 PM, Robert Haas wrote: > > > On Wed, Feb 21, 2018 at 10:03 PM, Mithun Cy > > > wrote: > > >> seeing futex in the call stack andres suggested that following commit >

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Hi, On 2018-01-24 00:06:44 +0530, Mithun Cy wrote: > Server: > ./postgres -c shared_buffers=8GB -N 200 -c min_wal_size=15GB -c > max_wal_size=20GB -c checkpoint_timeout=900 -c > maintenance_work_mem=1GB -c checkpoint_completion_target=0.9 & Which kernel & glibc version does this server have?

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Andres Freund writes: > On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: >> The regular backend's quickdie() function is more tricky. It should also >> call _exit(2) rather than exit(2). But it also tries to ereport a WARNING, >> and that is quite useful. There's already an on_exit_reset

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

Hi, On 2018-07-18 16:08:37 +0200, Tomas Vondra wrote: > Anyway, I have no clear idea what changes would be necessary to the original > design of logical decoding to make implementing this easier now. The > decoding in general is quite constrained by how our transam and WAL stuff > works. I

Re: Problem on pg_dump RANGE partition with expressions

Yugo Nagata writes: > Attached is a patch to get rid of "appears more than once" restriction. Pushed. (Again, it'd have been helpful if you updated the regression tests.) regards, tom lane

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

Hi, On 2018-07-18 10:56:31 -0400, Robert Haas wrote: > Are you talking about HOT updates, or HOT pruning? Disabling the > former wouldn't help, and disabling the latter would break VACUUM, > which assumes that any tuple not removed by HOT pruning is not a dead > tuple (cf.

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

On 2018-Jul-19, Amit Kapila wrote: > On Thu, Feb 22, 2018 at 7:55 PM, Robert Haas wrote: > > On Wed, Feb 21, 2018 at 10:03 PM, Mithun Cy > > wrote: > >> seeing futex in the call stack andres suggested that following commit could > >> be the reason for regression > >> > >> commit

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hi, On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > On 19/07/18 03:26, Asim R P wrote: > > On Thu, Jun 22, 2017 at 10:50 AM, Andres Freund wrote: > > > > > > Or, probably more robust: Simply _exit(2) without further ado, and rely > > > on postmaster to output an appropriate error

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On Tue, 17 Jul 2018 at 11:58, Ashutosh Bapat > wrote: > > On Sun, Jul 15, 2018 at 11:13 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > >> On Thu, 28 Jun 2018 at 07:54, Amit Langote > >> wrote: > >> > >> On 2018/06/27 22:21, Ashutosh Bapat wrote: > >> > On Wed, Jun 27, 2018 at 12:28 PM,

Re: Bug in gin insert redo code path during re-compression of empty gin data leaf pages

On 2018-Jul-19, Alexander Korotkov wrote: > Pushed, thanks! I think you missed branch REL_11_STABLE ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Bug in gin insert redo code path during re-compression of empty gin data leaf pages

On Thu, Jul 19, 2018 at 6:17 PM R, Siva wrote: > > On Thu, Jul 19, 2018 at 2:43 PM Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > > It appears that we need to handle empty posting list pages also > in disassembleLeaf(). Updated patch is attached. I'm > > going to commit it. >

Re: GiST VACUUM

> 19 июля 2018 г., в 16:28, Heikki Linnakangas написал(а): > Hmm. So, while we are scanning the right sibling, which was moved to > lower-numbered block because of a concurrent split, the original page is > split again? That's OK, we've already scanned all the tuples on the original > page,

Re: Possible bug in logical replication.

On 2018-Jul-19, Michael Paquier wrote: > On Thu, Jul 19, 2018 at 12:38:53AM -0400, Alvaro Herrera wrote: > > On 2018-Jul-19, Michael Paquier wrote: > >> I am fine either way if you want to have the last call. So please feel > >> free to choose what you prefer here. That's no big deal. > > > >

Re: [COMMITTERS] pgsql: Give a better error message on invalid hostaddr option.

On Thu, Jul 19, 2018 at 1:28 PM, Heikki Linnakangas wrote: > Seems that I broke this shortly afterwards, by commit 7b02ba62e9. Pushed, > thanks! Oh, OK. Thanks! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [COMMITTERS] pgsql: Give a better error message on invalid hostaddr option.

On 19/07/18 17:07, Robert Haas wrote: On Fri, Jun 9, 2017 at 6:06 AM, Heikki Linnakangas wrote: Give a better error message on invalid hostaddr option. If you accidentally pass a host name in the hostaddr option, e.g. hostaddr=localhost, you get an error like: psql: could not translate host

Re: psql's \d versus included-index-column feature

On Thursday, July 19, 2018, Tom Lane wrote: > > > Given that the documentation refers to included columns as "non-key > > columns", it seems natural to me to name the \d output column "Key?" and > > use "yes/no" as the values. > > WFM, anyone want to argue against? > Works for me as well.

Re: psql's \d versus included-index-column feature

Oleksandr Shulgin writes: > I don't think there is an established practice on how to display this sort > of info, but I see that both styles already exist, namely: > =# \dL >List of languages > Name| Owner | Trusted | Description >

Re: pgbench-ycsb

On 2018-07-19 16:50, Dmitry Dolgov wrote: On Thu, 19 Jul 2018 at 15:36, Fabien COELHO wrote: Hello Anthony, > applications with pgbench under different real-life-like load. So that > they will be able to see what's going to happen on production. > > YCSB (Yahoo! Cloud Serving Benchmark) was

Re: partition tree inspection functions

Hi Amit, On 07/19/2018 04:39 AM, Amit Langote wrote: I think pg_partition_tree_tables should have an option to exclude the table that is being queried from the result (bool include_self). Doesn't sound too bad, so added include_self. I'm thinking about how to best use these functions to

Re: [COMMITTERS] pgsql: Give a better error message on invalid hostaddr option.

On Fri, Jun 9, 2017 at 6:06 AM, Heikki Linnakangas wrote: > Give a better error message on invalid hostaddr option. > > If you accidentally pass a host name in the hostaddr option, e.g. > hostaddr=localhost, you get an error like: > > psql: could not translate host name "localhost" to address:

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

On Thu, Feb 22, 2018 at 7:55 PM, Robert Haas wrote: > On Wed, Feb 21, 2018 at 10:03 PM, Mithun Cy > wrote: >> seeing futex in the call stack andres suggested that following commit could >> be the reason for regression >> >> commit ecb0d20a9d2e09b7112d3b192047f711f9ff7e59 >> Author: Tom Lane >>

Re: pgbench-ycsb

Hello Anthony, applications with pgbench under different real-life-like load. So that they will be able to see what's going to happen on production. YCSB (Yahoo! Cloud Serving Benchmark) was taken as a concept. YCSB tests were originally designed to facilitate performance comparisons of

Re: pgsql: Fix parallel index and index-only scans to fall back to serial.

On 14/07/18 00:56, Robert Haas wrote: On Fri, Jul 13, 2018 at 2:22 PM, Heikki Linnakangas wrote: I just bumped into this comment, from commit 09529a70bb5, and I can't make sense of it: + /* +* We reach here if the index only scan is not parallel, or if we're +

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

On 18 July 2018 at 06:01, Alvaro Herrera wrote: > On 2018-Jul-16, David Rowley wrote: > >> On 16 July 2018 at 12:55, David Rowley wrote: >> > Thinking about this some more, I don't quite see any reason that the >> > partitioned_rels for a single hierarchy couldn't just be a Bitmapset >> >

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

On 17 July 2018 at 12:21, David Rowley wrote: > On 16 July 2018 at 06:55, Tom Lane wrote: >> I started to look at this patch. I think this is basically the right >> direction to go in, but I'm not terribly happy with the details of the >> data structure design. > > I've made an attempt at

Re: Libpq support to connect to standby server as priority

On Wed, Jul 18, 2018 at 10:53 PM Robert Haas wrote: > On Wed, Jul 4, 2018 at 9:14 AM, Laurenz Albe > wrote: > > What about keeping the first successful connection open and storing it > in a > > variable if we are in "prefer-read" mode. > > If we get the read-only connection we desire,

Re: [bug fix] Produce a crash dump before main() on Windows

On Wed, Jul 18, 2018 at 6:39 PM Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Haribabu Kommi [mailto:kommi.harib...@gmail.com] > > May be I can give a try by modifying the source code to get the crash. > > > Thank you, that would be great if you could come up with a good

Re: [HACKERS] plpgsql - additional extra checks

2018-07-15 1:38 GMT+02:00 Tomas Vondra : > Hi, > > I've been looking at the version submitted on Thursday, planning to > commit it, but I think it needs a wee bit more work on the error messages. > > 1) The example in sgml docs does not work, because it's missing a > semicolon after the CREATE

Re: Bug in gin insert redo code path during re-compression of empty gin data leaf pages

On Thu, Jul 19, 2018 at 2:43 PM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Jul 18, 2018 at 11:59 AM Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> On Wed, Jul 18, 2018 at 1:40 AM R, Siva wrote: >> >>> We came across an issue during replay of a gin insert

pgbench-ycsb

Hello, hackers. It might be a good idea to give users an opportunity to test their applications with pgbench under different real-life-like load. So that they will be able to see what's going to happen on production. YCSB (Yahoo! Cloud Serving Benchmark) was taken as a concept. YCSB tests were

Re: Runtime partition pruning for MergeAppend

On 19/07/18 15:36, David Rowley wrote: I just noticed I managed to miss updating "Append" to "MergeAppend" when copying a comment out of nodeAppend.c into nodeMergeAppend.c. I see you noticed it but accidentally updated the comment in nodeAppend.c. D'oh! Fixed, thanks. - Heikki

Re: pgbench's expression parsing & negative numbers

I'll come up with a patch for that sometime soon. ISTM that you have not sent any patch on the subject, otherwise I would have reviewed it. Maybe I could do one some time later, unless you think that I should not. Here is a patch which detects pgbench overflows on int & double constants,

Re: Runtime partition pruning for MergeAppend

On 19 July 2018 at 22:50, Heikki Linnakangas wrote: > Looks solid. The only actual bug I see is that this doesn't honor the > enable_partition_pruning GUC, but that's trivial to fix. So fixed that, > reworded some of the comments a tiny bit, and committed. Thanks! I just noticed I managed to

Re: GiST VACUUM

On 19/07/18 14:42, Andrey Borodin wrote: 19.07.2018, 15:20, "Heikki Linnakangas" : On 19/07/18 13:52, Andrey Borodin wrote: Hi! 19 июля 2018 г., в 1:12, Heikki Linnakangas mailto:hlinn...@iki.fi>> написал(а): Yeah, please, I think this is the way to go.

Re: Runtime partition pruning for MergeAppend

On 19 July 2018 at 23:22, Pavel Stehule wrote: > for getting custom plan, you don't need execute 5x now. Just use > plan_cache_mode GUC. Yeah. It's good to see that patch in. I wonder if we should go and change those tests to get rid of the 5x EXECUTEs before the actual test. -- David Rowley

Re: Runtime partition pruning for MergeAppend

On 19 July 2018 at 22:50, Heikki Linnakangas wrote: > Looks solid. The only actual bug I see is that this doesn't honor the > enable_partition_pruning GUC, but that's trivial to fix. So fixed that, > reworded some of the comments a tiny bit, and committed. Thanks! Many thanks for fixing that and

Re: Segfault logical replication PG 10.4

Hello, In worker.c:     - in apply_handle_insert, slot_store_cstrings is called before PushActiveSnapshot     - in apply_handle_update & apply_handle_delete, slot_store_cstrings is called after PushActiveSnapshot     /* Process and store remote tuple in the slot */     oldctx =

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

On Thu, Jul 19, 2018 at 10:30 PM, Kyotaro HORIGUCHI wrote: >> Hmm. Why wait any longer? The cluster is broken. Is there some >> correctness reason to defer shutdown in any of these places? > > Well, please don't get me wrong. I don't object to backends' exit > on postmaster death, rather I'm

Re: Bug in gin insert redo code path during re-compression of empty gin data leaf pages

Hi! On Wed, Jul 18, 2018 at 11:59 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Jul 18, 2018 at 1:40 AM R, Siva wrote: > >> We came across an issue during replay of a gin insert record on a pre-9.4 >> uncompressed data leaf page that does not have any items in it. The

Re: GiST VACUUM

19.07.2018, 15:20, "Heikki Linnakangas" :On 19/07/18 13:52, Andrey Borodin wrote: Hi! 19 июля 2018 г., в 1:12, Heikki Linnakangas  написал(а): Yeah, please, I think this is the way to go. Here's v11 divided into proposed steps.Thanks, one quick question: /*

Re: de-deduplicate code in DML execution hooks in postgres_fdw

(2018/07/19 17:52), Ashutosh Bapat wrote: On Thu, Jul 19, 2018 at 2:05 PM, Etsuro Fujita wrote: +1 for the general idea. (Actually, I also thought the same thing before.) But since this is definitely a matter of PG12, ISTM that it's wise to work on this after addressing the issue in [1]. My

Re: Runtime partition pruning for MergeAppend

Hi 2018-07-19 12:50 GMT+02:00 Heikki Linnakangas : > On 18/06/18 13:29, David Rowley wrote: > >> Back in the v11 cycle, there was just not quite enough time to get the >> MergeAppend run-time partition pruning patch in. >> >> I've attached v24 of this patch. The only changes done from v23 [1]

Re: GiST VACUUM

On 19/07/18 13:52, Andrey Borodin wrote: Hi! 19 июля 2018 г., в 1:12, Heikki Linnakangas написал(а): Yeah, please, I think this is the way to go. Here's v11 divided into proposed steps. Thanks, one quick question: /* We should not unlock buffer if we are going

Re: GiST VACUUM

Hi! > 19 июля 2018 г., в 1:12, Heikki Linnakangas написал(а): > > Yeah, please, I think this is the way to go. Here's v11 divided into proposed steps. In second step I still use paloc's memory, but only to store two bitmaps: bitmap of internal pages and bitmap of empty leafs. Second physical

Re: Runtime partition pruning for MergeAppend

On 18/06/18 13:29, David Rowley wrote: Back in the v11 cycle, there was just not quite enough time to get the MergeAppend run-time partition pruning patch in. I've attached v24 of this patch. The only changes done from v23 [1] are to re-base the patch atop of current master. There's was a bit

Re: Make foo=null a warning by default.

Hello David, All is nearly well, although "make docs" found a typo. I should have tested doc building before, sorry for this new round which should have been avoided. "null_expression" s///; Also, while reading the full documentation about the setting: I find this sentence a bit

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

At Thu, 19 Jul 2018 16:58:30 +1200, Thomas Munro wrote in > On Wed, Jul 18, 2018 at 8:30 PM, Kyotaro HORIGUCHI > wrote: > > At Wed, 18 Jul 2018 14:02:47 +1200, Thomas Munro > > wrote in > > > >> Here are some of the places I had to add WL_EXIT_ON_PM_DEATH: > >> gather_readnext(),

Re: Segfault logical replication PG 10.4

Hello , Some new input: On slave, all domains ( with checks) have been replaced by a simple type. No crash on slave since this bypass. Is there something to fix in the ActiveSnapshot code ? BR > Le 18 juil. 2018 à 17:03, Tom Lane a écrit : > > Mai Peng writes: >> Here the backtrace > > Hmm

Re: [PATCH] Find additional connection service files in pg_service.conf.d directory

Handy feature! On 01/03/18 20:40, Curt Tilmes wrote: On Thu, Mar 1, 2018 at 1:13 PM, Andres Freund wrote: And within the directory which service file wins will be decided by filesystem internals. That makes me a bit uncomfortable, this very well might not be stable. I think it might not be

Re: print_path is missing GatherMerge and CustomScan support

On Thu, Jul 19, 2018 at 9:58 AM, Michael Paquier wrote: > On Wed, Jul 18, 2018 at 03:22:02PM +0900, Michael Paquier wrote: >> Good catch. Those should be backpatched. While I am looking at this >> stuff, I have noticed that pathnode.c/reparameterize_path_by_child uses >> T_MergeAppend and not

Re: documentation about explicit locking

Hello. At Thu, 19 Jul 2018 13:17:14 +0900, Amit Langote wrote in <85dc6464-eb59-ba59-75d3-09b292fa8...@lab.ntt.co.jp> > On 2018/07/18 18:30, Peter Eisentraut wrote: > > On 06.07.18 04:00, Amit Langote wrote: > >> On 2018/07/05 23:02, Robert Haas wrote: > >>> On Wed, Jul 4, 2018 at 3:09 AM,

Re: MAP syntax for arrays

On 08/05/18 18:11, Ildar Musin wrote: On 08.05.2018 17:15, Peter Eisentraut wrote: On 5/8/18 09:19, Chapman Flack wrote: On 05/08/2018 08:57 AM, Ildar Musin wrote: select map (pow(2, x) - 1 for x in array[1,2,3,4,5]); I wonder how efficient an implementation would be possible strictly as a

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 19/07/18 03:26, Asim R P wrote: On Thu, Jun 22, 2017 at 10:50 AM, Andres Freund wrote: Or, probably more robust: Simply _exit(2) without further ado, and rely on postmaster to output an appropriate error message. Arguably it's not actually useful to see hundreds of "WARNING: terminating

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

Hi Robert and Tomas, It seems clear to me that the decodeGroup list of decoding backends waiting on the backend doing the transaction of interest is not a favored approach here. Note that I came down to this approach after trying various other approaches/iterations. I was especially enthused to

Re: de-deduplicate code in DML execution hooks in postgres_fdw

On Thu, Jul 19, 2018 at 2:05 PM, Etsuro Fujita wrote: > (2018/04/18 19:34), Ashutosh Bapat wrote: >> >> Hi, >> While working on a fix related to non-direct DML [1], I noticed that >> postgresExecForeignInsert(), postgresExecForeignUpdate() and >> postgresExecForeignDelete() functions are almost

Re: partition tree inspection functions

Thanks for the review, Jesper. On 2018/07/18 23:35, Jesper Pedersen wrote: > On 06/28/2018 01:49 AM, Amit Langote wrote: >> OK, I've added an example below the table of functions added by the patch. >> >> Attached updated patch. >> > > You forgot to remove the test output in create_table.out, so

Re: partition tree inspection functions

Hi Dilip, Sorry it took me a while to reply. On 2018/06/29 14:30, Dilip Kumar wrote: > On Tue, Jun 26, 2018 at 10:38 AM, Amit Langote wrote: >> As discussed a little while back [1] and also recently mentioned [2], here >> is a patch that adds a set of functions to inspect the details of a >>

Re: de-deduplicate code in DML execution hooks in postgres_fdw

(2018/04/18 19:34), Ashutosh Bapat wrote: Hi, While working on a fix related to non-direct DML [1], I noticed that postgresExecForeignInsert(), postgresExecForeignUpdate() and postgresExecForeignDelete() functions are almost identical except that postgresExecForeignInsert() doesn't require ctid.

Re: psql's \d versus included-index-column feature

On Thu, Jul 19, 2018 at 1:11 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Jul 18, 2018 at 11:14 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane wrote: >> >>> >>> regression=# \d tbl_include_reg_idx >>> Index

  1   2   >