Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

> 31 янв. 2017 г., в 9:50, Michael Paquier > написал(а): > > On Mon, Jan 30, 2017 at 4:28 PM, Andrew Borodin wrote: >> I'll summarize here my state of studying concurrent methods of page >> unlinking. >> >> GIN B-tree does not have "high key". That means, that rightmost key on >> a page is m

Re: [HACKERS] Multi-tenancy with RLS

On Mon, Dec 5, 2016 at 4:31 PM, Haribabu Kommi wrote: > > > On Mon, Oct 3, 2016 at 3:11 PM, Michael Paquier > wrote: > >> On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi >> wrote: >> > The above changes are based on my understanding to the discussion >> occurred in >> > this mail. In case if I

Re: [HACKERS] Commit fest 2017-01 will begin soon!

On Mon, Jan 23, 2017 at 1:17 PM, Michael Paquier wrote: > As of the current score of the CF, for a total of 155 patches, 52 have > been committed, 3 rejected and 7 marked as returned with feedback. It > may look low, but actually it is not that bad by experience looking at > those numbers. The CF

Re: [HACKERS] multivariate statistics (v19)

On 2017/01/31 6:57, Tomas Vondra wrote: > On 01/30/2017 09:37 PM, Alvaro Herrera wrote: >> Looks good to me. I don't think we need to keep the names very short -- >> I would propose "standistinct", "stahistogram", "stadependencies". >> > > Yeah, I got annoyed by the short names too. > > This how

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Jan 31, 2017 at 11:17 AM, Haribabu Kommi wrote: > On Fri, Jan 27, 2017 at 5:32 PM, Dilip Kumar wrote: >> On Tue, Jan 24, 2017 at 10:18 AM, Dilip Kumar >> wrote: >> > I have changed as per the comments. 0002 and 0003 are changed, 0001 is >> > still the same. >> >> There is just one line c

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

On Thu, Jan 19, 2017 at 9:35 AM, Stephen Frost wrote: > Awesome, glad to hear it. This is also on my list of patches that I'm > planning to look at, just so folks know. There is a patch, no new reviews, so moved to CF 2017-03. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

On Mon, Jan 30, 2017 at 4:28 PM, Andrew Borodin wrote: > I'll summarize here my state of studying concurrent methods of page unlinking. > > GIN B-tree does not have "high key". That means, that rightmost key on > a page is maximal for the non-leaf page. > But I do not see anything theoretical in a

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Tue, Jan 31, 2017 at 3:02 AM, Robert Haas wrote: > On Fri, Jan 27, 2017 at 5:34 PM, Jim Nasby wrote: >> On 1/26/17 10:11 PM, Beena Emerson wrote: >>> In that case, we could add the file location parameter. By default it >>> would store in the cluster directory else in the location provided. W

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Tue, Jan 31, 2017 at 2:13 PM, Vitaly Burovoy wrote: > I'm almost ready to mark it as Ready for committer. > The final round. Moved to next CF with same status, waiting on author as the last patch and the last review are very fresh. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Sat, Jan 28, 2017 at 10:03 AM, Thomas Munro wrote: > I have broken this up into a patch series, harmonised the private vs > shared hash table code paths better and fixed many things including > the problems with rescans and regression tests mentioned upthread. > You'll see that one of the patch

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Sun, Jan 29, 2017 at 3:33 AM, Fabrízio de Royes Mello wrote: > On Sat, Jan 28, 2017 at 4:26 PM, Fabrízio de Royes Mello > wrote: >> On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut >> wrote: >> > >> > On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: >> > > Ok, but doing in that way the syn

Re: [HACKERS] [PATCH] Generic type subscription

On Sat, Jan 28, 2017 at 2:31 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> On 24 January 2017 at 02:07, Tom Lane wrote: >> I took an extremely quick look over the patch > > Thank you for the feedback. It took some time for me to think about all > suggestions and notes. Okay, I am marking th

Re: [HACKERS] patch: function xmltable

On Tue, Jan 31, 2017 at 5:18 AM, Pavel Stehule wrote: > true, I am sorry Last status is a new patch and no reviews. On top of that this thread is quite active. So moved to next CF. Pavel, please be careful about the status of the patch on the CF app, it was set to "waiting on author"... -- Micha

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

On Fri, Jan 27, 2017 at 8:52 AM, Craig Ringer wrote: > Now, if it's simpler to just xlog the gid at COMMIT PREPARED time when > wal_level >= logical I don't think that's the end of the world. But > since we already have almost everything we need in memory, why not > just stash the gid on ReorderBu

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

On Tue, Jan 31, 2017 at 3:29 PM, Michael Paquier wrote: > On Fri, Jan 27, 2017 at 8:52 AM, Craig Ringer wrote: >> Now, if it's simpler to just xlog the gid at COMMIT PREPARED time when >> wal_level >= logical I don't think that's the end of the world. But >> since we already have almost everythin

Re: [HACKERS] pgbench - allow to store select results into variables

Bonjour Michaël, Attached are the patch, a test script for the feature, and various test scripts to trigger error cases. I have moved this patch to next CF Ok. as the last status is a new patch set with no further reviews. Indeed. I did not check if the comments have been applied thoug

Re: [HACKERS] identity columns

On Thu, Jan 5, 2017 at 9:34 AM, Vitaly Burovoy wrote: > I apologize for a silence since the last CF. > I've tested your last patch and have several nitpickings: Last update is a review from 3 weeks ago, this patch is marked as returned with feedback. -- Michael -- Sent via pgsql-hackers maili

Re: [HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

On Wed, Jan 11, 2017 at 12:32 AM, Pavel Stehule wrote: > Thank you for review Moved to next CF 2017-03. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pgbench - allow to store select results into variables

On Sat, Jan 7, 2017 at 6:25 PM, Fabien COELHO wrote: > I think that I have done what you required. > > I have documented the fact that now the feature does not work if compound > commands contain empty queries, which is a very minor drawback for a pgbench > script anyway. > > Attached are the patc

Re: [HACKERS] DROP FUNCTION of multiple functions

On Wed, Jan 18, 2017 at 2:00 PM, Michael Paquier wrote: > On Wed, Jan 18, 2017 at 5:26 AM, Peter Eisentraut > wrote: >> On 1/10/17 1:52 AM, Michael Paquier wrote: >>> I don't see any problems with 0001. >> >> I was wondering, should we rename funcname -> name, and funcargs -> >> args, or perhaps

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Jan 31, 2017 at 2:58 PM, Pavel Stehule wrote: > I found a error - I sent mail only to author 2016-12-31 :( - It is my > mistake. I am sorry Ah... Thanks for the update. No problem. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Speedup twophase transactions

On Tue, Jan 31, 2017 at 2:58 PM, Nikhil Sontakke wrote: >>> CheckPointTwoPhase() in (5) does not sync this prepared transaction >>> because the checkpointer's KnownPreparedList is empty. >> >> And that's why this needs to be stored in shared memory with a number >> of elements made of max_prepared

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

This is code lifted from variable.c's ParseVariableBool(). When the other patch for "psql hooks" is committed (the one that detects when the string wasn't a valid boolean), this code will go away and we'll just use ParseVariableBool() again. The ParseVariableBool function has been updated, an

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2017-01-31 6:56 GMT+01:00 Michael Paquier : > On Tue, Jan 31, 2017 at 2:53 PM, Pavel Stehule > wrote: > > I tested new set of these patches and I found some regressions there - > > mentioned in my last mail. > > > > Maybe I miss new update, bit I don't know about it. > > The last update I am awar

Re: [HACKERS] Speedup twophase transactions

>> CheckPointTwoPhase() in (5) does not sync this prepared transaction >> because the checkpointer's KnownPreparedList is empty. > > And that's why this needs to be stored in shared memory with a number > of elements made of max_prepared_xacts... Yeah. Was thinking about this yesterday. How about

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

> > > > 2017-01-31 6:51 GMT+01:00 Michael Paquier : > >> >> >> The current patch status was "waiting on author", but that's incorrect >> as a new series of this patch has been sent. Please be careful with >> the status of the CF app! I am moving it to next CF with "needs >> review". Gerdan Santos h

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Jan 31, 2017 at 2:53 PM, Pavel Stehule wrote: > I tested new set of these patches and I found some regressions there - > mentioned in my last mail. > > Maybe I miss new update, bit I don't know about it. The last update I am aware of is that saying: "lot of patches. I hope I look on these

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2017-01-31 6:51 GMT+01:00 Michael Paquier : > On Tue, Dec 27, 2016 at 12:23 PM, Kyotaro HORIGUCHI > wrote: > > Hello, > > > > At Mon, 26 Dec 2016 14:24:33 +0100, Pavel Stehule < > pavel.steh...@gmail.com> wrote in yNSvn8Vvf+m=DBy3ps=y0_3...@mail.gmail.com> > > pavel.stehule> 2016-12-26 9:40 GMT+

Re: [HACKERS] PoC: Partial sort

On Mon, Dec 5, 2016 at 2:04 PM, Haribabu Kommi wrote: > > > On Fri, Dec 2, 2016 at 4:05 AM, Robert Haas wrote: >> >> On Tue, Sep 13, 2016 at 4:32 AM, Alexander Korotkov >> wrote: >> > On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan wrote: >> >> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotk

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Dec 27, 2016 at 12:23 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 26 Dec 2016 14:24:33 +0100, Pavel Stehule > wrote in > pavel.stehule> 2016-12-26 9:40 GMT+01:00 Kyotaro HORIGUCHI > > >: >> >> > > Thanks for reviewing but I ran out of time for this CF.. >> > > >> > > I'm going to

Re: [HACKERS] emergency outage requiring database restart

On Wed, Jan 4, 2017 at 4:17 AM, Peter Eisentraut wrote: > It seems like everyone was generally in favor of this. I looked around > the internet for caveats but everyone was basically saying, you should > definitely do this. > > Why not for EXEC_BACKEND? > > O_CLOEXEC is a newer interface. There

Re: [HACKERS] wait events for disk I/O

On Tue, Jan 31, 2017 at 8:54 AM, Michael Paquier wrote: > On Mon, Jan 30, 2017 at 10:01 PM, Rushabh Lathia > wrote: > > Attached is the patch, which extend the existing wait event > infrastructure > > to implement the wait events for the disk I/O. Basically > pg_stat_activity's > > wait event in

Re: [HACKERS] Speedup twophase transactions

On Tue, Jan 31, 2017 at 2:34 PM, Nikhil Sontakke wrote: >>> I wonder what's the best location for this in the common case when we >>> do shutdown of standby. We could add code in XLOG_CHECKPOINT_SHUTDOWN >>> and XLOG_CHECKPOINT_ONLINE xlog_redo code path. >> >> ShutdownXLOG() calls CreateRestartP

Re: [HACKERS] WAL consistency check facility

On Thu, Jan 5, 2017 at 2:54 PM, Kuntal Ghosh wrote: > On Wed, Dec 21, 2016 at 10:53 PM, Robert Haas wrote: > >> On a first read-through of this patch -- I have not studied it in >> detail yet -- this looks pretty good to me. One concern is that this >> patch adds a bit of code to XLogInsert(), w

Re: [HACKERS] Speedup twophase transactions

>> Having CheckPointTwoPhase() do the flush would mean shifting the data >> from KnownPreparedList into TwoPhaseState shmem. > > Er, no. For CheckPointTwoPhase(), at recovery what needs to be done is > to have all the entries in KnownPreparedList() flushed to disk and > have those entries removed w

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

Hi Heikki, On 2016-11-22 10:56:07 -0800, Peter Geoghegan wrote: > I attach V4 of amcheck. Is there any chance you could look at the concurrency related parts of amcheck? I'd like to push this to be mergeable, but that area is a bit outside of my area of expertise... Andres -- Sent via pgsql-

[HACKERS] Refactoring of replication commands using printsimple

Hi all, This is a follow up of the refactoring that has been discussed in the thread to increase the default size of WAL segments: https://www.postgresql.org/message-id/cab7npqq4hynrlq+w1jrryvsysoxuqa40pyb2uw5uqkkag4h...@mail.gmail.com The discussion has resulted in the creation of a84069d9 that

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Jan 30, 2017 at 8:46 PM, Thomas Munro wrote: > On Wed, Jan 4, 2017 at 12:53 PM, Peter Geoghegan wrote: >> Attached is V7 of the patch. > > I am doing some testing. First, some superficial things from first pass: > > [Various minor cosmetic issues] Oops. > Just an observation: if you a

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On 1/27/17, Haribabu Kommi wrote: > Updated patches are attached. Hello, I'm almost ready to mark it as Ready for committer. The final round. 1. >+DATA(insert OID = 774 ( macaddr8 ... >+#define MACADDR8OID 972 What does this number (972) mean? I think it should be 774, the same number as was u

Re: [HACKERS] increasing the default WAL segment size

On Sat, Jan 28, 2017 at 8:04 AM, Michael Paquier wrote: > On Sat, Jan 28, 2017 at 7:29 AM, Robert Haas wrote: >> On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier >> wrote: I've not done like the most careful review ever, but I'm in favor of the general change (provided the byval thing

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, Jan 20, 2017 at 10:14 PM, Michael Paquier wrote: > On Fri, Jan 20, 2017 at 10:11 PM, Alvaro Herrera > wrote: >>> diff --git a/src/backend/replication/basebackup.c >>> b/src/backend/replication/basebackup.c >> >>> @@ -148,6 +149,9 @@ static const char *excludeFiles[] = >>> /* Skip a

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Mon, Dec 5, 2016 at 2:15 PM, Haribabu Kommi wrote: > Moved to next CF with " needs review" status. Same, to CF 2017-03 this time. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 12, 2017 at 10:21 AM, Michael Paquier wrote: > On Thu, Jan 12, 2017 at 4:09 AM, Robert Haas wrote: >> On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier >> wrote: >>> Do you think that expanding the wait query by default could be >>> intrusive for the other tests? I am wondering about

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Jan 4, 2017 at 12:53 PM, Peter Geoghegan wrote: > Attached is V7 of the patch. I am doing some testing. First, some superficial things from first pass: Still applies with some offsets and one easy-to-fix rejected hunk in nbtree.c (removing some #include directives and a struct definitio

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Tue, Jan 17, 2017 at 4:31 PM, Michael Paquier wrote: > On Tue, Nov 29, 2016 at 1:35 PM, Michael Paquier > wrote: >> On Tue, Nov 22, 2016 at 8:35 PM, Haribabu Kommi >> wrote: >>> Hi Craig, >>> >>> This is a gentle reminder. >>> >>> you assigned as reviewer to the current patch in the 11-2016 c

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Mon, Jan 30, 2017 at 8:01 PM, Vladimir Rusinov wrote: > > On Fri, Jan 27, 2017 at 11:03 PM, Peter Eisentraut > wrote: >> >> 1. Rename nothing >> 2. Rename directory only >> 3. Rename everything > > > 3 or 1 (with a slight preference for 3). > > Not sure if my vote counts, but for me as ex-DBA

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Thu, Jan 26, 2017 at 9:11 PM, Kyotaro HORIGUCHI wrote: >> Though, I know the community is against behaviour changing GUCs. I >> will not spend more time on this, before I get positive feedback from >> others. > > That's too bad. I'm sorry that I wasn't very helpful.. You make a constructive d

Re: [HACKERS] WAL logging problem in 9.4.3?

On Fri, Dec 2, 2016 at 1:39 PM, Haribabu Kommi wrote: > The latest proposed patch still having problems. > Closed in 2016-11 commitfest with "moved to next CF" status because of a bug > fix patch. > Please feel free to update the status once you submit the updated patch. And moved to CF 2017-03..

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Tue, Dec 20, 2016 at 4:54 PM, Michael Paquier wrote: > I am attaching that to next CF. Moved to CF 2017-03. Both patches still apply. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pg

Re: [HACKERS] multivariate statistics (v19)

On Tue, Jan 31, 2017 at 6:57 AM, Tomas Vondra wrote: > This however reminds me that perhaps pg_mv_statistic is not the best name. I > know others proposed pg_statistic_ext (and pg_stats_ext), and while I wasn't > a big fan initially, I think it's a better name. People generally don't know > what '

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 31, 2017 at 12:55 PM, Haribabu Kommi wrote: > > > On Tue, Jan 31, 2017 at 10:04 AM, Tom Lane wrote: >> >> Haribabu Kommi writes: >> > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier >> > >> > wrote: >> >> #define USER_AUTH_LAST uaPeer >> >> StaticAssertStmt(lengthof(UserAuthName) =

Re: [HACKERS] COPY as a set returning function

On Tue, Jan 31, 2017 at 3:05 AM, Corey Huinker wrote: > On Fri, Jan 27, 2017 at 9:42 PM, Peter Eisentraut > wrote: >> >> On 1/25/17 8:51 PM, Corey Huinker wrote: >> > # select * from copy_srf('echo "x\ty"',true) as t(x text, y text); >> >> I find these parameters weird. Just looking at this, one

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Jan 31, 2017 at 10:04 AM, Tom Lane wrote: > Haribabu Kommi writes: > > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> #define USER_AUTH_LAST uaPeer > >> StaticAssertStmt(lengthof(UserAuthName) == USER_AUTH_LAST + 1, > >> "UserAuthName must

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Jan 21, 2017 at 6:37 AM, Kevin Grittner wrote: > On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams wrote: >> On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: > >>> There is currently plenty of room for pseudo-MV implementations, >>> and may be for a while. It's a good indicat

Re: [HACKERS] Radix tree for character conversion

On Mon, Jan 30, 2017 at 3:37 PM, Kyotaro HORIGUCHI wrote: > Hello, this is the revised version of character conversion using radix tree. Thanks for the new version, I'll look at it once I am done with the cleanup of the current CF. For now I have moved it to the CF 2017-03. -- Michael -- Sent

Re: [HACKERS] wait events for disk I/O

On Mon, Jan 30, 2017 at 10:01 PM, Rushabh Lathia wrote: > Attached is the patch, which extend the existing wait event infrastructure > to implement the wait events for the disk I/O. Basically pg_stat_activity's > wait event information to show data about disk I/O as well as IPC primitives. > > Imp

Re: [HACKERS] Speedup twophase transactions

On Tue, Jan 31, 2017 at 3:45 AM, Nikhil Sontakke wrote: >> --- a/src/backend/access/transam/xlog.c >> +++ b/src/backend/access/transam/xlog.c >> @@ -9573,6 +9573,7 @@ xlog_redo(XLogReaderState *record) >> (errmsg("unexpected timeline ID %u (should be %u) >> in checkpoint recor

Re: [HACKERS] Parallel bitmap heap scan

On Fri, Jan 27, 2017 at 5:32 PM, Dilip Kumar wrote: > On Tue, Jan 24, 2017 at 10:18 AM, Dilip Kumar > wrote: > > I have changed as per the comments. 0002 and 0003 are changed, 0001 is > > still the same. > > 2 days back my colleague Rafia, reported one issue (offlist) that > parallel bitmap node

Re: [HACKERS] Potential data loss of 2PC files

On Fri, Jan 6, 2017 at 9:26 PM, Ashutosh Bapat wrote: > On Wed, Jan 4, 2017 at 12:16 PM, Michael Paquier > wrote: >> On Wed, Jan 4, 2017 at 1:23 PM, Ashutosh Bapat >> wrote: >>> I don't have anything more to review in this patch. I will leave that >>> commitfest entry in "needs review" status fo

Re: [HACKERS] Potential data loss of 2PC files

On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas wrote: > So, if I understood correctly, the problem scenario is: > > 1. Create and write to a file. > 2. fsync() the file. > 3. Crash. > 4. After restart, the file is gone. Yes, that's a problem with fsync's durability, and we need to achieve t

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Mon, Jan 30, 2017 at 5:51 AM, Masahiko Sawada wrote: > > * We are willing to use at most maintenance_work_mem (or perhaps > * autovacuum_work_mem) memory space to keep track of dead tuples. We > * initially allocate an array of TIDs of that size, with an upper limit that > * depends o

[HACKERS] Fix handling of ALTER DEFAULT PRIVILEGES

Greetings, While working through some pg_dump regression tests, I came across a bug in 9.6+ due to the changes I made to how GRANT/REVOKEs were handled. The attached describes and fixes the bug, which only impacts dumping from 9.6+ clusters, so hopefully not too many people have been impacted by

Re: [HACKERS] Allow interrupts on waiting standby

On Fri, Jan 27, 2017 at 10:17 PM, Michael Paquier wrote: > Two things I forgot in this patch: > - documentation for the new wait event > - the string for the wait event or this would show up as "???" in > pg_stat_activity. > There are no default clauses in the pgstat_get_wait_* routines so my > co

Re: [HACKERS] Improvements in psql hooks for variables

"Daniel Verite" writes: > Tom Lane wrote: >> Evidently, this test script is relying on the preceding behavior that >> setting a bool variable to an empty string was equivalent to setting >> it to "true". If it's just that script I would be okay with saying >> "well, it's a bug in that scrip

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Evidently, this test script is relying on the preceding behavior that > setting a bool variable to an empty string was equivalent to setting > it to "true". If it's just that script I would be okay with saying > "well, it's a bug in that script" ... but I'm a bit worried

Re: [HACKERS] Improvements in psql hooks for variables

Tom Lane wrote: > Also, if you want to argue that allowing it to change intra- > transaction is too confusing, why would we only forbid this direction > of change and not both directions? The thread "Surprising behaviour of \set AUTOCOMMIT ON" at: https://www.postgresql.org/message-id/CAH

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 31 January 2017 at 13:10, David Rowley wrote: > I've attached a patch which implements this. Please disregards previous patch. (I forgot git commit before git diff to make the patch) I've attached the correct patch. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Improvements in psql hooks for variables

So I pushed this, and the buildfarm members that are testing RedisFDW immediately fell over: *** /home/andrew/bf/root/HEAD/redis_fdw.build/test/expected/redis_fdw.out 2017-01-30 18:20:27.440677318 -0500 --- /home/andrew/bf/root/HEAD/redis_fdw.build/test/results/redis_fdw.out 2017-01

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 28 January 2017 at 05:44, Tom Lane wrote: > I wrote: >> David Rowley writes: >>> hmm. I'm having trouble understanding why this is a problem for Unique >>> joins, but not for join removal? > >> Ah, you know what, that's just mistaken. I was thinking that we >> short-circuited the join on the

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund writes: > Wonder if we there's an argument to be made for implementing this > roughly similarly to split_pathtarget_at_srf - instead of injecting a > ProjectSet node we'd add a FunctionScan node below a Result node. Yeah, possibly. That would have the advantage of avoiding an ExecP

Re: [HACKERS] Subtle bug in "Simplify tape block format" commit

On Mon, Jan 30, 2017 at 10:01 AM, Peter Geoghegan wrote: > Let me take another look at this later today before proceeding. I want > to run it against a custom test suite I've developed. I've done so. Some more thoughts: * I don't think that this is really any less efficient than my patch. It's j

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On 2017-01-30 17:24:31 -0500, Tom Lane wrote: > Make it work like Agg and WindowFunc. To wit, dump the actually special > function calls (the set-returning functions) into a list that's internal > to the FunctionScan node, and then anything above those goes into scalar > expressions in the node's

Re: [HACKERS] patch proposal

On Tue, Jan 31, 2017 at 4:49 AM, David Steele wrote: > On 1/27/17 3:19 AM, Venkata B Nagothi wrote: >> I have split the patch into two different >> pieces. One is to determine if the recovery can start at all and other >> patch deals with the incomplete recovery situation. > > I think the first pa

[HACKERS] [PATCH] kNN for SP-GiST

Hello hackers, I'd like to present a series of patches which is a continuation of Vlad Sterzhanov's work on kNN for SP-GiST that was done for GSOC'14. Original thread: "KNN searches support for SP-GiST [GSOC'14]" https://www.postgresql.org/message-id/cak2ajc0-jhrb3ujozl+arbchotvwbejvprn-jofenn0v

Re: [HACKERS] pg_hba_file_settings view patch

Haribabu Kommi writes: > On Mon, Jan 30, 2017 at 5:18 PM, Michael Paquier > wrote: >> #define USER_AUTH_LAST uaPeer >> StaticAssertStmt(lengthof(UserAuthName) == USER_AUTH_LAST + 1, >> "UserAuthName must include all user authentication names"); > Thanks for the review. Added the static assert st

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund writes: > On 2017-01-30 16:55:56 -0500, Tom Lane wrote: >> No, but it allows whatever looks syntactically like a function, including >> casts. IIRC, we made func_expr work that way ages ago to deflect >> complaints that it wasn't very clear why some things-that-look-like- >> functio

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Hi, On 2017-01-30 16:55:56 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: > >> SELECT * > >> FROM pg_constraint pc, > >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > >> array_upper(pc.conkey, 1)) ELSE NULL END AS int

Re: [HACKERS] multivariate statistics (v19)

On 01/30/2017 09:37 PM, Alvaro Herrera wrote: Tomas Vondra wrote: The 'built' flags may be easily replaced with a check if the bytea-like columns are NULL, and the 'enabled' columns may be replaced by the array of char, just like you proposed. That'd give us a single catalog looking like this:

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Andres Freund writes: > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: >> SELECT * >> FROM pg_constraint pc, >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, >> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position; >> >> Above query is failing with "set-valued f

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Hi, On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote: > Consider the below test; > > CREATE TABLE tab ( a int primary key); > > SELECT * > FROM pg_constraint pc, > CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley writes: > On 31 January 2017 at 04:56, Tom Lane wrote: >> I'm not following. If the join removal code had reached the stage of >> making a uniqueness check, and that check had succeeded, the join would be >> gone and there would be no repeat check later. If it didn't reach the >> s

Re: [HACKERS] Declarative partitioning - another take

On 1/25/17 12:54 AM, Ashutosh Bapat wrote: > The documentation available at > https://www.postgresql.org/docs/devel/static/sql-createtable.html, > does not make it clear that the lower bound of a range partition is > always inclusive and the higher one is exclusive. I think a note in > section " PA

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 31 January 2017 at 04:56, Tom Lane wrote: > David Rowley writes: >> I can make this change, but before I do I just want to point that I >> don't think what you've said here is entirely accurate. > >> Let's assume unique joins are very common place, and join removals are >> not so common. If a

Re: [HACKERS] Improvements in psql hooks for variables

I wrote: > Rahila Syed writes: >>> +* Switching AUTOCOMMIT from OFF to ON is not allowed when inside a >>> +* transaction, because it cannot be effective until the current >>> +* transaction is ended. >> The above change in autocommit behaviour needs to be documented. > Y

Re: [HACKERS] multivariate statistics (v19)

Tomas Vondra wrote: > The 'built' flags may be easily replaced with a check if the bytea-like > columns are NULL, and the 'enabled' columns may be replaced by the array of > char, just like you proposed. > > That'd give us a single catalog looking like this: > > pg_mv_statistics > starelid >

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

Stephen Frost wrote: > Uh, after finding our perltidyrc and running with that, I have to ask, > why are we setting vertical-tightness to 2 (never break before a closing > token)? The default of 0 (always break) end up being a lot nicer when > working on lists. Stacking isolated opening/closing t

Re: [HACKERS] patch: function xmltable

Hi 2017-01-30 20:38 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > I am sending new version - it is based on own executor scan node and > > tuplestore. > > > > Some now obsolete regress tests removed, some new added. > > > > The executor code (memory context usage) should be cleaned litt

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn't the result of a perltidy > > run as it was qui

Re: [HACKERS] multivariate statistics (v19)

On 01/30/2017 05:12 PM, Alvaro Herrera wrote: > Hmm. So we have a catalog pg_mv_statistics which stores two things: 1. the configuration regarding mvstats that have been requested by user via CREATE/ALTER STATISTICS 2. the actual values captured from the above, via ANALYZE I think this confl

Re: [HACKERS] patch proposal

On 1/27/17 3:19 AM, Venkata B Nagothi wrote: > I will be adding the tests in > src/test/recovery/t/003_recovery_targets.pl > . My tests would look more or less > similar to recovery_target_action. I do not see any of the tests added > for the parameter recovery_targ

Re: [HACKERS] multivariate statistics (v19)

On 01/30/2017 05:55 PM, Alvaro Herrera wrote: Minor nitpicks: Let me suggest to use get_attnum() in CreateStatistics instead of SearchSysCacheAttName for each column. Also, we use type AttrNumber for attribute numbers rather than int16. Finally in the same function you have an erroneous ERRCOD

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > I am sending new version - it is based on own executor scan node and > tuplestore. > > Some now obsolete regress tests removed, some new added. > > The executor code (memory context usage) should be cleaned little bit - but > other code should be good. I think you forgot

Re: [HACKERS] multivariate statistics (v19)

Hello, On 01/26/2017 10:03 AM, Ideriha, Takeshi wrote: Though I pointed out these typoes and so on, I believe these feedback are less priority compared to the source code itself. So please work on my feedback if you have time. I think getting the comments (and docs in general) right is just

Re: [HACKERS] multivariate statistics (v19)

On 01/26/2017 10:43 AM, Dilip Kumar wrote: histograms -- + if (matches[i] == MVSTATS_MATCH_FULL) + s += mvhist->buckets[i]->ntuples; + else if (matches[i] == MVSTATS_MATCH_PARTIAL) + s += 0.5 * mvhist->buckets[i]->ntuples; Isn't it will be better that take some percentage of the buc

Re: [HACKERS] [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > This will be undone by the next perltidy run. > > > > Ugh. > > > > I certainly hope what was there before wasn't the result of a perltidy > > run as it was qui

Re: [HACKERS] patch: function xmltable

Hi 2017-01-25 15:07 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > Andres Freund writes: > > > On 2017-01-24 21:32:56 -0300, Alvaro Herrera wrote: > > >> XMLTABLE is specified by the standard to return multiple rows ... but > > >> then as far as my reading goes, it is only supposed to be suppo

Re: [HACKERS] VACUUM's ancillary tasks

Thomas Munro wrote: > About BRIN indexes: I couldn't find an explanation of why BRIN > indexes don't automatically create new summary tuples when you insert > a new tuple in an unsummarised page range. Is it deferred until > VACUUM time in order to untangle some otherwise unresolvable > interloc

Re: [HACKERS] Speedup twophase transactions

> --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > @@ -9573,6 +9573,7 @@ xlog_redo(XLogReaderState *record) > (errmsg("unexpected timeline ID %u (should be %u) > in checkpoint record", > checkPoint.ThisTimeLineID,

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Pavan Deolasee wrote: > On Wed, Jan 25, 2017 at 10:06 PM, Alvaro Herrera > wrote: > > > +( \ > > > + ((tup)->t_infomask2 & HEAP_LATEST_TUPLE) != 0 \ > > > +) > > > > > > +#define HeapTupleHeaderGetRootOffset(tup) \ > > > +( \ > > > + AssertMacro(((tup)->t_infomask2 & HEAP_LATEST_TUPLE) !=

Re: [HACKERS] Improvements in psql hooks for variables

BTW, while testing this patch I noticed that the error reports are a tad redundant: regression=# \set AUTOCOMMIT foo unrecognized value "foo" for "AUTOCOMMIT": boolean expected \set: error while setting variable regression=# The "error while setting variable" message seems entirely content-free.

  1   2   >