Re: [HACKERS] pageinspect patch, for showing tuple data

On Wed, Sep 9, 2015 at 8:39 PM, Nikolay Shaplov wrote: > В письме от 8 сентября 2015 11:53:24 Вы написали: >> Hence, instead of all those complications, why not simply introducing two >> functions that take as input the tuple data and the OID of the relation, >>

Re: [HACKERS] [PATCH] SQL function to report log message

Hi All, Thanks for your inputs on this. Here, I see a conflict between the doable{RAISE}, and convenience{SQL function}, and will follow your inputs on this. Also, I was under impression that, all our TODO items are filtered for the real use cases. Is my

Re: [HACKERS] [PATCH v2] GSSAPI encryption support

On Thu, Sep 10, 2015 at 1:44 AM, Robbie Harwood wrote: > Michael Paquier writes: > >> On Wed, Sep 9, 2015 at 4:12 AM, Robbie Harwood wrote: >>> Michael Paquier writes: >>> As promised, here's a V2 to address your issues with comments. I >>>

Re: [HACKERS] Waits monitoring

Hi, > Great - let's try to deal with [1] first, then. > > Does anyone wish to object to me committing that part? I have no objection to commiting this, too. But some fix would be needed. === Generated lwlocknames.[ch] don't have header comment because generate-lwlocknames.pl writes them into

[HACKERS] Partitioned checkpointing

Hi All, Recently, I have found a paper titled "Segmented Fussy Checkpointing for Main Memory Databases" published in 1996 at ACM symposium on Applied Computing, which inspired me to implement a similar mechanism in PostgreSQL. Since the early evaluation results obtained from a 16 core server was

Re: [HACKERS] Partitioned checkpointing

I don't feel that another source of the performance dip has been heartily addressed; full-page-write rush, which I call here, would be a major issue. That is, the average size of transaction log (XLOG) records jumps up sharply immediately after the beginning of each checkpoint, resulting in

Re: [HACKERS] Partitioned checkpointing

Hello Takashi-san, I suggest that you have a look at the following patch submitted in June: https://commitfest.postgresql.org/6/260/ And these two threads: http://www.postgresql.org/message-id/flat/alpine.DEB.2.10.1408251900211.11151@sto/

[HACKERS] Another typo in comment in setrefs.c

Hi, I'm attaching a small patch to fix another comment typo in setrefs.c: s/TIDs/OIDs/ Best regards, Etsuro Fujita diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index ee8710d..093d925 100644 --- a/src/backend/optimizer/plan/setrefs.c +++

Re: [HACKERS] Small patch to fix an O(N^2) problem in foreign keys

On 09/08/2015 08:49 AM, Kevin Grittner wrote: Jan Wieck wrote: The problem is a cache introduced in commit 45ba4247 that improves That's a bit off; 45ba424f seems to be what you mean. Copy paste over paper. foreign key lookups during bulk updates when the FK value

Re: [HACKERS] pgsql: Improve logging of TAP tests.

* Stephen Frost (sfr...@snowman.net) wrote: > Patch attached for review. Barring objections, I'll commit this in a > few hours. Done. Thanks! Stephen signature.asc Description: Digital signature

Re: [HACKERS] Another typo in comment in setrefs.c

* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: > I'm attaching a small patch to fix another comment typo in setrefs.c: > s/TIDs/OIDs/ Fixed. Thanks! Stephen signature.asc Description: Digital signature

Re: [HACKERS] Another typo in comment in setrefs.c

Stephen Frost writes: > * Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: >> I'm attaching a small patch to fix another comment typo in setrefs.c: >> s/TIDs/OIDs/ > Fixed. I do not think "typo" is the right characterization. I'm too lazy to check for sure, but I think

Re: [HACKERS] pageinspect patch, for showing tuple data

On Thu, Sep 10, 2015 at 03:46:25PM +0900, Michael Paquier wrote: > Why is it not convenient at all? Yes, you have a point, we need those > fields to be able to parse the t_data properly. Still the possibility > to show individual fields of a tuple as a bytea array either with > toasted or

Re: [HACKERS] Another typo in comment in setrefs.c

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote: > >> I'm attaching a small patch to fix another comment typo in setrefs.c: > >> s/TIDs/OIDs/ > > > Fixed. > > I do not think "typo" is the right

Re: [HACKERS] Another typo in comment in setrefs.c

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Attached is a patch with the proposed change (against master, the back > > branches require slightly different patches due to nearby wording > > changes). > > Already done, after a bit of research into when

Re: [HACKERS] Another typo in comment in setrefs.c

Stephen Frost writes: > Attached is a patch with the proposed change (against master, the back > branches require slightly different patches due to nearby wording > changes). Already done, after a bit of research into when things actually changed.

Re: [HACKERS] checkpointer continuous flushing

Thanks for the hints! Two-part v12 attached fixes these. Here is a v13, which is just a rebase after 1aba62ec. -- Fabien.diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 9e7bcf5..2ef21fb 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2457,6

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Sep 10, 2015 at 8:44 PM, Alvaro Herrera wrote: > dinesh kumar wrote: > > > Also, I was under impression that, all our TODO > > items are filtered for the real > use > > cases. Is my impression wrong. If I wanted to work on

Re: [HACKERS] pageinspect patch, for showing tuple data

В письме от 10 сентября 2015 15:46:25 пользователь Michael Paquier написал: > > So if move tuple data parsing into separate function, then we have to pass > > these values alongside the tuple data. This is not convenient at all. > > So I did it in a way you see in the patch. > > Why is it not

Re: [HACKERS] [PATCH] SQL function to report log message

dinesh kumar wrote: > Also, I was under impression that, all our TODO > items are filtered for the real use > cases. Is my impression wrong. If I wanted to work on another TODO item, > where i need to take a look. Your impression is completely, absolutely,

Re: [HACKERS] [PATCH] SQL function to report log message

On 2015-09-09 23:45:08 -0400, Tom Lane wrote: > Were all twenty of them exactly alike? Were they identical to Andres' > several dozen attempts? Mine were pretty much alike and trivial - which is why I never even bothered to standardize on a variant and store it somewhere. > The problem I've got

Re: [HACKERS] Use pg_rewind when target timeline was switched

Michael Paquier wrote: > On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote: > > I was running manual tests like a noob :) When you attached you bash script, > > I've switched to it. > > [product_placement]The patch to improve the recovery test suite > submitted in this CF would have eased

Re: [HACKERS] [PATCH] SQL function to report log message

On Thu, Sep 10, 2015 at 8:14 AM, Alvaro Herrera wrote: > dinesh kumar wrote: > > > Also, I was under impression that, all our TODO > > items are filtered for the real > use > > cases. Is my impression wrong. If I wanted to work on

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Wed, Sep 9, 2015 at 11:49 PM, Amit Kapila wrote: > - errdetail("Could not rename \"%s\" to \"%s\": %m.", > + errdetail("\"%s\" could not be renamed to \"%s\": %m.", > > Is there any reason to change this message? > I think you have changed this message to make it

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On Wed, Sep 9, 2015 at 2:30 AM, Etsuro Fujita wrote: >> But that path might have already been discarded on the basis of cost. >> I think Tom's idea is better: let the FDW consult some state cached >> for this purpose in the RelOptInfo. > > Do you have an idea of what

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Sep 11, 2015 at 3:41 AM, Beena Emerson wrote: > Please find attached the WIP patch for the proposed feature. It is built > based on the already discussed design. > > Changes made: > - add new parameter "sync_file" to provide the location of the pg_syncinfo > file.

[HACKERS] Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested This looks good to me. I've done some tests(pg_dumpall & restore

Re: [HACKERS] Autonomous Transaction is back

On Wed, Sep 09, 2015 at 10:04:01AM -0400, Robert Haas wrote: > On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: > > What design principle(s) have you been using to decide how autonomous > > transactions should behave? > > I have to admit to a complete lack of principle. I'm

Re: [HACKERS] Partitioned checkpointing

> Feel free to do that. 200kB is well below this list's limits. (I'm not > sure how easy it is to open .epsf files in today's systems, but .jpg or > other raster image formats are pretty common.) Thanks for your comment. Please find two result graphs (for sync and async commit cases) in .jpg

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Bernd Helmle wrote: > A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11 > instance. > > The database crashed with the following log messages: > > 2015-09-08 00:49:16 CEST [2912] PANIC: could not access status of > transaction 1068235595 > 2015-09-08 00:49:16 CEST [2912]

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On Fri, Sep 11, 2015 at 10:45 AM, Alvaro Herrera wrote: > Bernd Helmle wrote: > > A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11 > > instance. > > > > The database crashed with the following log messages: > > > > 2015-09-08 00:49:16 CEST [2912]

Re: [HACKERS] Re: [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

On Fri, Sep 11, 2015 at 12:41:09AM +, Hyongtae Lim wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:not

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Bernd Helmle wrote: > 2015-09-08 11:40:59 CEST [27047] DETAIL: Could not seek in file > "pg_multixact/members/5FC4" to offset 4294950912: Invalid argument. > 2015-09-08 11:40:59 CEST [27047] CONTEXT: xlog redo create mxid 1068235595 > offset 2147483648 nmembers 2: 2896635220 (upd)

Re: [HACKERS] Multi-tenancy with RLS

On 09/01/2015 11:25 PM, Haribabu Kommi wrote: > If any user is granted any permissions on that object then that user > can view it's meta data of that object from the catalog tables. > To check the permissions of the user on the object, instead of > checking each and every available option, I just

Re: [HACKERS] Moving SS_finalize_plan processing to the end of planning

On Sun, Aug 9, 2015 at 3:50 PM, Tom Lane wrote: > I've started to work on path-ification of the upper planner (finally), > and since that's going to be a large patch in any case, I've been looking > for pieces that could be bitten off and done separately. One such piece > is

Re: [HACKERS] 9.3.9 and pg_multixact corruption

On Fri, Sep 11, 2015 at 11:51 AM, Thomas Munro < thomas.mu...@enterprisedb.com> wrote: > On Fri, Sep 11, 2015 at 10:45 AM, Alvaro Herrera > wrote: > >> Bernd Helmle wrote: >> > A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11 >> > instance. >> >

Re: [HACKERS] Partitioned checkpointing

Fabien, Thanks for your comment. I'll check them and try to examine what is the same and what is different. -- Takashi Horikawa NEC Corporation Knowledge Discovery Research Laboratories > -Original Message- > From: pgsql-hackers-ow...@postgresql.org >

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Bernd Helmle wrote: > A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11 > instance. > > 2015-09-08 11:40:59 CEST [27047] FATAL: could not access status of > transaction 1068235595 > 2015-09-08 11:40:59 CEST [27047] DETAIL: Could not seek in file >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Fri, Sep 11, 2015 at 5:43 AM, Robert Haas wrote: > On Thu, Sep 10, 2015 at 3:52 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Wed, Sep 9, 2015 at 11:49 PM, Amit Kapila >>> wrote: -

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, > -Original Message- > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > Sent: Friday, September 11, 2015 2:05 PM > To: robertmh...@gmail.com > Cc: fujita.ets...@lab.ntt.co.jp; Kaigai Kouhei(海外 浩平); > pgsql-hackers@postgresql.org; shigeru.han...@gmail.com >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Fri, Sep 11, 2015 at 10:10 AM, Fujii Masao wrote: > > So I added the object type, i.e., file in this case, to the errdetail > messages. Attached is the updated version of the patch. > > I also changed other log messages related to tablespace_map > so that they follow the

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hello, At Thu, 10 Sep 2015 17:24:00 -0400, Robert Haas wrote in > On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita > wrote: > >> I'm wondering if there's another approach. If

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Sorry, that's quite wrong.. Please let me fix it. - Is this pointless? + Does it make sense? = Hello, At Thu, 10 Sep 2015 17:24:00 -0400, Robert Haas wrote in > On Thu, Sep 3, 2015 at 1:22 AM,

[HACKERS] Parser emits mysterious error message for very long tokens

Hello, this is a problem on an extreme situation. When parser encounters very long tokens, it returns an error message which should be mysterious for users. > $ perl -e "print \"select '\" . \"x\"x(512*1024*1024) . \"'\"" | psql postgres > ERROR: invalid memory alloc request size 1073741824

Re: [HACKERS] Another typo in comment in setrefs.c

On 2015/09/10 23:31, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost writes: Attached is a patch with the proposed change (against master, the back branches require slightly different patches due to nearby wording changes). Already done, after a

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/09/11 6:24, Robert Haas wrote: On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita wrote: I'm wondering if there's another approach. If I understand correctly, there are two reasons why the current situation is untenable. The first is that ForeignRecheck always

Re: [HACKERS] more RLS oversights

Noah, First off, thanks again for your review and comments on RLS. Hopefully this addresses the last remaining open item from that review. * Noah Misch (n...@leadboat.com) wrote: > On Wed, Feb 25, 2015 at 11:37:24PM -0500, Stephen Frost wrote: > > + > > + Referential integrity checks, such

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

Robert Haas writes: > On Wed, Sep 9, 2015 at 11:49 PM, Amit Kapila wrote: >> - errdetail("Could not rename \"%s\" to \"%s\": %m.", >> + errdetail("\"%s\" could not be renamed to \"%s\": %m.", >> >> Is there any reason to change this message? >> I

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Thu, Sep 10, 2015 at 3:52 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 9, 2015 at 11:49 PM, Amit Kapila wrote: >>> - errdetail("Could not rename \"%s\" to \"%s\": %m.", >>> + errdetail("\"%s\" could not be

[HACKERS] RLS open items are vague and unactionable

The open items list here: https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items ...currently has the following items related to RLS: CREATE POLICY and RETURNING Arguable RLS security bug, EvalPlanQual() paranoia Dean's latest round of RLS refactoring. more RLS oversights Those items don't

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Thu, Sep 3, 2015 at 6:25 AM, Etsuro Fujita wrote: > I gave it another thought; the following changes to ExecInitNode would make > the patch much simpler, ie, we would no longer need to call the new code in > ExecInitForeignScan, ExecForeignScan, ExecEndForeignScan,

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita wrote: >> I'm wondering if there's another approach. If I understand correctly, >> there are two reasons why the current situation is untenable. The >> first is that ForeignRecheck always returns true, but we could

[HACKERS] 9.3.9 and pg_multixact corruption

A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11 instance. The database crashed with the following log messages: 2015-09-08 00:49:16 CEST [2912] PANIC: could not access status of transaction 1068235595 2015-09-08 00:49:16 CEST [2912] DETAIL: Could not open file

Re: [HACKERS] statistics for array types

Jeff Janes wrote: > The attached patch forces there to be at least one element in MCE, keeping > the one element with the highest predicted frequency if the MCE would > otherwise be empty. Then any other element queried for is assumed to be no > more common than this most common element. Hmm,

Re: [HACKERS] checkpointer continuous flushing

Hello Amit, - T1 flush=off 27480 -> 27482 :+0.0% - T1 flush=on 25214 -> 26819 :+6.3% - T2 flush=off 5050 -> 6194 : +22.6% - T2 flush=on2771 -> 6110 : +120.4% There is a clear win only in cases when sort is used with flush, apart from that using sort alone doesn't

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, Please find attached the WIP patch for the proposed feature. It is built based on the already discussed design. Changes made: - add new parameter "sync_file" to provide the location of the pg_syncinfo file. The default is 'ConfigDir/pg_syncinfo.conf', same as for pg_hba and pg_ident file.