Re: [HACKERS] Bug in StartupSUBTRANS

Simon Riggs writes: > Your patch looks right to me, so I will commit, barring objections... with > backpatch. Likely to 9.0, AFAICS. 9.0 is out of support and should not be patched anymore. I agree that the patch is basically correct, though I'd personally write it

Re: [HACKERS] Multi-tenancy with RLS

JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > pg_dump -U $non-super_user > > Should just work, period. That ship has sailed already, where you're running a pg_dump against objects you don't own and which have RLS enabled on them. Thanks! Stephen signature.asc Description: Digital

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

Ah, so it turns out I should have used the commitfest tool. My apologies; I will send the whole thing through that again. Please disregard the earlier message. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Multi-tenancy with RLS

On 02/09/2016 12:05 PM, Robert Haas wrote: That's true. But I should also have an expectation that running pg_dump won't trigger arbitrary code execution, which is why by default, pg_dump sets row_security to OFF. That way, if a row security policy applies, I get an error rather than an

Re: [HACKERS] Multi-tenancy with RLS

On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote: >> Whereupon you'd have no certainty that what you got represented a >> complete dump of your own data. > > It would be a dump of what you're allowed to see, rather than an error > saying you couldn't dump something you

Re: [HACKERS] Multi-tenancy with RLS

On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote: > On 02/09/2016 11:47 AM, Robert Haas wrote: >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote: Whereupon you'd have no certainty that what you got represented a complete dump of your own

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski wrote: > But then it becomes disputable if SQL syntax change makes sense. > > ---we had this, > NOTIFY channel [ , payload ] > ---and in this patch we have this > NOTIFY [ ALL | DISTINCT ] channel [ , payload ] >

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Josh Kupershmidt writes: > On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski > wrote: >> But then it becomes disputable if SQL syntax change makes sense. >> >> ---we had this, >> NOTIFY channel [ , payload ] >> ---and in this patch we have

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Tue, Feb 9, 2016 at 8:39 AM, Ashutosh Bapat wrote: > Thanks Jeevan for your review and comments. PFA the patch which fixes those. Committed with a couple more small adjustments. Woohoo, finally! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

I wrote: > In any case, we should proceed with fixing things so that buildfarm owners > can specify a higher shutdown timeout for especially slow critters. I looked into doing this as I suggested yesterday, namely modifying the buildfarm scripts, and soon decided that it would be a mess; there

Re: [HACKERS] Multi-tenancy with RLS

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote: > > On 02/09/2016 11:47 AM, Robert Haas wrote: > >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote: > Whereupon you'd have no certainty

Re: [HACKERS] [COMMITTERS] pgsql: postgres_fdw: Push down joins to remote servers.

On Tue, Feb 9, 2016 at 3:10 PM, Tom Lane wrote: > Robert Haas writes: >> postgres_fdw: Push down joins to remote servers. > > The buildfarm is not very impressed with this patch. Well, I guess that's why we have regression tests. It looks like that

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

I wrote: > Noah Misch writes: >> On Mon, Feb 08, 2016 at 02:15:48PM -0500, Tom Lane wrote: >>> We've seen variants >>> on this theme on half a dozen machines just in the past week --- and it >>> seems to mostly happen in 9.5 and HEAD, which is fishy. >> It has been affecting

[HACKERS] ALTER EXTENSION DROP FUNCTION not working ?

I'm seeing an issue with ALTER EXTENSION DROP FUNCTION not fully unregistering the dependency of the function on the extension. Commands to reproduce described here: https://trac.osgeo.org/postgis/ticket/3450#comment:23 Basically I'm getting: ERROR: cannot drop function

Re: [HACKERS] checkpointer continuous flushing - V16

I think I would appreciate comments to understand why/how the ringbuffer is used, and more comments in general, so it is fine if you improve this part. I'd suggest to leave out the ringbuffer/new bgwriter parts. Ok, so the patch would only onclude the checkpointer stuff. I'll look at this

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi Looking at this patch, I have mixed feelings about it. On the one hand > I really like the look of the output, and I can see that the non-fixed > nature of the output columns makes this hard to achieve server-side. > > But on the other hand, this seems to be going way beyond the normal > level

Re: [HACKERS] checkpointer continuous flushing - V16

On February 9, 2016 10:46:34 AM GMT+01:00, Fabien COELHO wrote: > >>> I think I would appreciate comments to understand why/how the >>> ringbuffer is used, and more comments in general, so it is fine if >you >>> improve this part. >> >> I'd suggest to leave out the

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 9 February 2016 at 05:24, Pavel Stehule wrote: > I have not a feeling so we did some with Daniel privately. All work was > public (I checked my mailbox) - but what is unhappy - in more mailing list > threads (not sure how it is possible, because subjects looks same).

Re: [HACKERS] ALTER EXTENSION DROP FUNCTION not working ?

On Tue, Feb 09, 2016 at 10:33:42AM +0100, Sandro Santilli wrote: > https://trac.osgeo.org/postgis/ticket/3450#comment:23 > > Basically I'm getting: > > ERROR: cannot drop function pgis_twkb_accum_finalfn(internal) because other > objects depend on it > DETAIL: extension postgis depends on

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 9 February 2016 at 10:09, Pavel Stehule wrote: > The sorting on client side is necessary - minimally in one direction, > because you cannot to create perfect sorting for both dimensions. > Possibility to order in second dimension is just pretty comfortable - > because

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

> > > > SELECT name, to_char(date, 'mon') AS month, extract(month from date) AS > > month_order, sum(amount) AS amount FROM invoices GROUP BY 1,2,3; > > > > and crosstabview command (per Daniel proposal) > > > > \crosstabview +name +month:month_order amount > > > > But if I don't need column

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

Hi, I have reviewed the patch and it looks good to me. make/make install/make check is fine (when done without -Wall -Werror). Here are few comments: 1. With -Wall -Werror, I see couple of warnings: postgres_fdw.c: In function ‘estimate_path_cost_size’: postgres_fdw.c:2248:13: error: ‘run_cost’

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > So please can we have that wiki page so that the syntax can be hammered > out a bit more. Sure, I'm on it. > I'm closing this as returned-with-feedback for now. Well, the feedback it got during months was incorporated into the patch in the form of significant

Re: [HACKERS] proposal: schema PL session variables

On 08/02/16 14:16, Pavel Stehule wrote: 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja : Yeah, and that's exactly what I don't want, because that means that CREATE SCHEMA VARIABLE suddenly breaks existing code. theoretically yes, but this conflict can be 100% detected - so no quiet

Re: [HACKERS] proposal: schema PL session variables

2016-02-09 15:32 GMT+01:00 Marko Tiikkaja : > On 08/02/16 14:16, Pavel Stehule wrote: > >> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja : >> >>> >>> Yeah, and that's exactly what I don't want, because that means that >>> CREATE >>> SCHEMA VARIABLE suddenly breaks existing

Re: [HACKERS] ALTER EXTENSION DROP FUNCTION not working ?

Sandro Santilli writes: > On Tue, Feb 09, 2016 at 10:33:42AM +0100, Sandro Santilli wrote: >> https://trac.osgeo.org/postgis/ticket/3450#comment:23 >> >> Basically I'm getting: >> ERROR: cannot drop function pgis_twkb_accum_finalfn(internal) because other >> objects depend on

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > Also, what about the business of putting "x" if there's no third column? > Three months from now some Czech psql hacker will say "we should use > Unicode chars for this" and we will be forever stuck with \pset > unicode_crosstab_marker to change the character to a

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > While I understand that you may think that "silence is consent", > what I am afraid of is that some committer will look at this two > months from now and say "I hate this Hcol+ stuff, -1 from me" and > send the patch back for syntax rework. IMO it's better to have

[HACKERS] Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On Wed, Dec 30, 2015 at 08:16:28PM +1300, David Rowley wrote: > On [1] I suggested an idea to make improvements to the planner around the > Equivalence Class code. Later in [2] Tom raised concerns with this adding > too many planning cycles for a perhaps not common enough situation. I > don't

Re: [HACKERS] Existence check for suitable index in advance when concurrently refreshing.

On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote: > Thanks for updating the patch! > Attached is the updated version of the patch. > I removed unnecessary assertion check and change of source code > that you added, and improved the source comment. > Barring objection, I'll

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote: > > > I think we ought to move the buffer mapping, lock manager, and > predicate lock manager locks into their own tranches also, perhaps > using this new named-tranche facility. > Makes sense and attached patch implements

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

On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote: > Also, to be frank, I think we ought to be putting more effort into > another patch in this same area, specifically Thomas Munro's causal > reads patch. I think a lot of people today are trying to use > synchronous replication to build

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 7 January 2016 at 05:24, Amit Kapila wrote: > On Fri, Dec 25, 2015 at 6:36 AM, Robert Haas wrote: >> >> On Wed, Dec 23, 2015 at 1:16 AM, Amit Kapila >> wrote: >> >> > >> >> > Here procArrayGroupXid sounds like Xid at

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote: > > On Tue, Feb 9, 2016 at 2:24 PM, Amit Kapila wrote: > > Do you see any benefit in allowing checkpoints for such cases considering > > bgwriter will anyway take care of logging standby

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 9 February 2016 at 11:06, Pavel Stehule wrote: > + respect SQL clauses ordering, allows pretty complex ORDER BY clause That, to me is the key point. SQL already allows very powerful sorting, so psql should not just throw away the query's sort order and replace it

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Mon, Feb 8, 2016 at 5:24 PM, Daniel Verite wrote: > Shulgin, Oleksandr wrote: > > > Added to the Open commitfest: https://commitfest.postgresql.org/9/475/ > > Here's a review. Note that the patch tested and submitted > is not the initial one in the thread, so

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/08/2016 10:55 PM, Tom Lane wrote: Noah Misch writes: On Mon, Feb 08, 2016 at 02:15:48PM -0500, Tom Lane wrote: We've seen variants on this theme on half a dozen machines just in the past week --- and it seems to mostly happen in 9.5 and HEAD, which is fishy. It has

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Dean Rasheed wrote: > I don't think we should allow sorting colV values client-side, > overriding a server-side ORDER BY clause in the query. I shared that opinion until (IIRC) the v8 or v9 of the patch. Most of the evolution of this patch has been to go from no client-side sorting

Re: [HACKERS] GinPageIs* don't actually return a boolean

On вторник, 29 сентября 2015 г. 19:02:59 MSK, Alvaro Herrera wrote: Andres Freund wrote: I went through all headers in src/include and checked for macros containing [^&]&[^&] and checked whether they have this hazard. Found a fair number. That patch also changes !! tests into != 0 style. I

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Dean Rasheed wrote: > Note that I might also want to pass additional sort options, such as > "ORDER BY name NULLS LAST", which the existing syntax doesn't allow. > In the new syntax, such sort options could be trivially supported in > both the server- and client-side sorts: Note that

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

"Daniel Verite" writes: > Dean Rasheed wrote: >> I don't think we should allow sorting colV values client-side, >> overriding a server-side ORDER BY clause in the query. > I shared that opinion until (IIRC) the v8 or v9 of the patch. > Most of the evolution of this

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

On Tue, Feb 9, 2016 at 10:32 PM, Michael Paquier wrote: > On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote: >> Also, to be frank, I think we ought to be putting more effort into >> another patch in this same area, specifically Thomas Munro's causal >> reads patch. I

Re: [HACKERS] Existence check for suitable index in advance when concurrently refreshing.

On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier wrote: > On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote: >> Thanks for updating the patch! >> Attached is the updated version of the patch. >> I removed unnecessary assertion check and change of

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

Artur Zakirov writes: >> I think the NIImportOOAffixes() in spell.c should be corrected to avoid >> this bug. > I have attached a patch. It adds new functions parse_ooaffentry() and > get_nextentry() and fixes a couple comments. I do not like this patch much. It is

Re: [HACKERS] Existence check for suitable index in advance when concurrently refreshing.

On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote: > On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier > wrote: >> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote: >>> Thanks for updating the patch! >>> Attached is the

Re: [HACKERS] proposal: function parse_ident

Hi 2016-02-08 16:55 GMT+01:00 Teodor Sigaev : > rebased, messages changes per Tom's proposal >> > Cool feature and sometimes I needed it a lot. > > But, seems, there are some bugs in error processing. > > 1 > Following query is okay: > # select * from parse_ident(E'"Some \r

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

I haven't been paying attention to this thread ... but it is sure > sounding like this feature has gotten totally out of hand. Suggest > reconsidering your design goals. > > > Or said otherwise, having the [+/-] colV sorting is a way to > > avoid the question: > > "we can sort the horizontal

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

On Sun, Feb 7, 2016 at 9:49 PM, Kouhei Kaigai wrote: > On the other hands, it also became clear we have to guarantee OS buffer > or storage block must not be updated partially during the P2P DMA. > My motivation is a potential utilization of P2P DMA of SSD-to-GPU to > filter

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 03:05 PM, Tom Lane wrote: I wrote: In any case, we should proceed with fixing things so that buildfarm owners can specify a higher shutdown timeout for especially slow critters. I looked into doing this as I suggested yesterday, namely modifying the buildfarm scripts, and soon

Re: [HACKERS] Multi-tenancy with RLS

On 9 February 2016 at 19:47, Robert Haas wrote: > I think you're dismissing Tom's concerns far too lightly. The > row_security=off mode, which is the default, becomes unusable for > non-superusers under this proposal. That's bad. And if you switch to > the other mode,

Re: [HACKERS] Multi-tenancy with RLS

On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote: > Arbitrary code execution is quite a different concern from the prior > concern regarding incomplete dumps. I've had both concerns all along, and I think I've mentioned them before. > To the extent that untrusted code

Re: [HACKERS] Multi-tenancy with RLS

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote: > > To the extent that untrusted code execution is an issue (and my > > experience with environments which would deploy RLS tells me that it > > isn't a practical concern), an

Re: [HACKERS] Multi-tenancy with RLS

On 02/09/2016 12:28 PM, Stephen Frost wrote: JD, * Joshua D. Drake (j...@commandprompt.com) wrote: pg_dump -U $non-super_user Should just work, period. That ship has sailed already, where you're running a pg_dump against objects you don't own and which have RLS enabled on them. Just to be

Re: [HACKERS] Multi-tenancy with RLS

On 02/09/2016 01:22 PM, Tom Lane wrote: > Maybe we need to restrict that somehow, or maybe some better solution > exists that we've not thought of yet. But in its current state, RLS > is at least as much a security hazard as it is a security aid. > I do not want to see it extended in ways that

[HACKERS] Convert pltcl from strings to objects

Currently, pl/tcl is implemented through nothing but string manipulation. In other words, the C code is effectively creating a giant string that the tcl interpreter must re-parse every time the function is executed. Additionally, all arguments are treated as raw strings, instead of the far

Re: [HACKERS] Multi-tenancy with RLS

* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 9 February 2016 at 19:47, Robert Haas wrote: > > I think you're dismissing Tom's concerns far too lightly. The > > row_security=off mode, which is the default, becomes unusable for > > non-superusers under this

Re: [HACKERS] Multi-tenancy with RLS

On 02/09/2016 12:47 PM, Robert Haas wrote: > On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost wrote: >> JD, >> >> * Joshua D. Drake (j...@commandprompt.com) wrote: >>> pg_dump -U $non-super_user >>> >>> Should just work, period. >> >> That ship has sailed already, where you're

Re: [HACKERS] Multi-tenancy with RLS

On Tue, Feb 9, 2016 at 4:22 PM, Tom Lane wrote: > Part of the problem here is that we have *not* created any hard and fast > distinction between "privileged" and "unprivileged" users; I think that > even speaking in those terms about RLS risks errors in your thinking. +1. >

Re: [HACKERS] proposal: schema PL session variables

On 2/9/16 4:13 PM, Corey Huinker wrote: We're not going to get source compatibility without implementing packages, and there's no enthusiasm for that. It's been stated a few times before by some that the only value they see in packages is the package/session variables. Pavel's idea gives us

Re: [HACKERS] Multi-tenancy with RLS

On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost wrote: > JD, > > * Joshua D. Drake (j...@commandprompt.com) wrote: >> pg_dump -U $non-super_user >> >> Should just work, period. > > That ship has sailed already, where you're running a pg_dump against > objects you don't own and

Re: [HACKERS] Multi-tenancy with RLS

JD, * Joshua D. Drake (j...@commandprompt.com) wrote: > On 02/09/2016 12:28 PM, Stephen Frost wrote: > >* Joshua D. Drake (j...@commandprompt.com) wrote: > >>pg_dump -U $non-super_user > >> > >>Should just work, period. > > > >That ship has sailed already, where you're running a pg_dump against >

Re: [HACKERS] Multi-tenancy with RLS

Joe Conway writes: > Personally I don't buy that the current situation is a good thing. I > know that the "ship has sailed" and regret not having participated in > the earlier discussions, but I agree with JD here -- the unprivileged > user should not have to even think about

Re: [HACKERS] Multi-tenancy with RLS

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Joe Conway writes: > > Personally I don't buy that the current situation is a good thing. I > > know that the "ship has sailed" and regret not having participated in > > the earlier discussions, but I agree with JD here -- the

Re: [HACKERS] Multi-tenancy with RLS

* Joe Conway (m...@joeconway.com) wrote: > On 02/09/2016 01:22 PM, Tom Lane wrote: > > Maybe we need to restrict that somehow, or maybe some better solution > > exists that we've not thought of yet. But in its current state, RLS > > is at least as much a security hazard as it is a security aid. >

Re: [HACKERS] proposal: schema PL session variables

On Tue, Feb 9, 2016 at 2:55 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker > wrote: > >> >> Oh, and I suggest we call them SESSION variables rather than SCHEMA >> variables, to reinforce the idea of how long

Re: [HACKERS] proposal: schema PL session variables

On 2/8/16 10:02 AM, Pavel Stehule wrote: I think it would make sense to implement the interface in at least one of our other supported PLs. I'm not entirely clear how well this will match up with, say, plperl, but I'd be interested to see. The minimalistic interface can be based

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Tue, Feb 9, 2016 at 12:15 AM, Merlin Moncure wrote: > I wonder if the third argument > should be a boolean however. If we make it 'text, 'send mode', > instead, we could leave some room for more specialization of the > queuing behavior. > > For example, we've had a couple

Re: [HACKERS] Multi-tenancy with RLS

On 02/09/2016 11:47 AM, Robert Haas wrote: > On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote: >>> Whereupon you'd have no certainty that what you got represented a >>> complete dump of your own data. >> >> It would be a dump of what you're allowed to see, rather than an

Re: [HACKERS] Bug in StartupSUBTRANS

On 9 February 2016 at 18:42, Jeff Janes wrote: > While testing the crash resilience of the recent 2-part-commit > improvements, I've run into a problem where sometimes after a crash > the recovery process creates zeroed files in pg_subtrans until it > exhausts all disk

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

* Andreas 'ads' Scherbaum wrote: one of our customers approached us and complained, that GET DIAGNOSTICS row_count returns invalid results if the number of rows is > 2^31. It's Attached patch expands the row_count to 64 bit. diagnostics=# select testfunc_pg((2^32 + 5)::bigint);

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, failed Spec compliant: not tested Documentation:not tested * Andreas 'ads' Scherbaum wrote: > one of our customers approached us

Re: [HACKERS] proposal: schema PL session variables

On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker wrote: > > Oh, and I suggest we call them SESSION variables rather than SCHEMA > variables, to reinforce the idea of how long the values in the variables > live. A session variable is in a sense a 1x1 temp table, whose

Re: [HACKERS] why can the isolation tester handle only one waiting process?

On February 9, 2016 7:12:23 PM GMT+01:00, Robert Haas wrote: >On Tue, Sep 8, 2015 at 5:11 PM, Robert Haas >wrote: >> Here's an updated patch series with some more improvements to the >> isolationtester code, and some better test cases. > >OK, here's

Re: [HACKERS] proposal: schema PL session variables

On Tue, Feb 9, 2016 at 9:58 AM, Pavel Stehule wrote: > > > 2016-02-09 15:32 GMT+01:00 Marko Tiikkaja : > >> On 08/02/16 14:16, Pavel Stehule wrote: >> >>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja : >>> Yeah, and that's exactly what

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

> -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Wednesday, February 10, 2016 1:58 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Jim Nasby; pgsql-hackers@postgresql.org; Amit Langote > Subject: ##freemail## Re: [HACKERS] Way to check whether a particular block is > on

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 06:46 PM, Andrew Dunstan wrote: On 02/09/2016 05:53 PM, Tom Lane wrote: Andrew, I wonder if I could prevail on you to make axolotl run "make check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can see if the logging I added tells anything useful about this.

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On 01/19/2016 07:04 PM, Michael Paquier wrote: > On Wed, Jan 20, 2016 at 11:41 AM, Alvaro Herrera > wrote: >> Joe Conway wrote: >> >>> The attached includes Bruce's change, plus I found two additional sites >>> that appear to need the same change. The xlog.c change is

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 07:49 PM, Tom Lane wrote: Andrew Dunstan writes: So running it's not running with fsync off or using the ramdisk for stats_temp_directory. Of course, that doesn't explain why we're not seeing it on branches earlier than 9.5, but it could explain why we're

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

I wrote: > ... However, there is something else happening > on axolotl. Looking at the HEAD and 9.5 branches, there are three very > similar failures in the ECPG step within the past 60 days: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl=2016-02-08%2014%3A49%3A23 >

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

Shulgin, Oleksandr wrote: > Most importantly, I'd like to learn of better options than storing the > whole last_result in psql's pset structure. I guess that you could, each time a query fails, gather silently the result of \errverbose, store it in a buffer, discard the PGresult, and in

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 05:53 PM, Tom Lane wrote: Andrew, I wonder if I could prevail on you to make axolotl run "make check" on HEAD in src/interfaces/ecpg/ until it fails, so that we can see if the logging I added tells anything useful about this. Will do. cheers

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

I wrote: > I'm not sure whether there's anything to be gained by leaving the tracing > code in there till we see actual buildfarm fails. There might be another > slowdown mechanism somewhere, but I rather doubt it. Thoughts? Hmmm ... I take that back. AFAICT, the failures on Noah's AIX zoo are

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

On Wed, Feb 10, 2016 at 2:57 AM, Fujii Masao wrote: > On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada > wrote: >> Attached first version dedicated language patch (document patch is not yet.) > > Thanks for the patch! Will review it. > > I think

Re: [HACKERS] Existence check for suitable index in advance when concurrently refreshing.

On Wed, Feb 10, 2016 at 2:23 AM, Fujii Masao wrote: > On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote: >> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier >> wrote: >>> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao

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

Hello, At Tue, 9 Feb 2016 13:31:46 +0900, Michael Paquier wrote in

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote: > I'll commit the attached tomorrow if there are no other concerns voiced. Just a nitpick regarding this block: + if (strchr(p, '/') != NULL) + p = strchr(p, '/'); + /* delimiter changed from

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

Andrew Dunstan writes: > Incidentally, as I noted earlier, the ecpg tests don't honour > TEMP_CONFIG, and in axolotl's case this could well make a difference, as > it it set up like this: > ... > So running it's not running with fsync off or using the ramdisk for >

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

I wrote: > Anyway, I think I should push this additional instrumentation so you > can use it on axolotl. Done. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

Andrew Dunstan writes: > So running it's not running with fsync off or using the ramdisk for > stats_temp_directory. Of course, that doesn't explain why we're not > seeing it on branches earlier than 9.5, but it could explain why we're > only seeing it on the ecpg tests.

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 08:49 PM, Tom Lane wrote: Andrew Dunstan writes: On 02/09/2016 07:49 PM, Tom Lane wrote: However, I'd already noted from some other digging in the buildfarm logs that axolotl's speed seems to vary tremendously. I do not know what else you typically run on

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 2/8/16 2:45 PM, Tom Lane wrote: Alvaro Herrera writes: Tom Lane wrote: What I'd like to do to investigate this is put in a temporary HEAD-only patch that makes ShutdownXLOG() and its subroutines much chattier about how far they've gotten and what time it is, and

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Feb 9, 2016 at 7:26 PM, Thom Brown wrote: > > On 7 January 2016 at 05:24, Amit Kapila wrote: > > On Fri, Dec 25, 2015 at 6:36 AM, Robert Haas wrote: > >> > >> On Wed, Dec 23, 2015 at 1:16 AM, Amit Kapila

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote: > Still, it seems clear that the bulk of the shutdown time is indeed the > stats collector taking its time about shutting down, which is doubly > weird because the ecpg tests shouldn't have created very many tables, > so why would there be

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

Jim Nasby writes: > On 2/8/16 2:45 PM, Tom Lane wrote: >> I had in mind to just "git revert" the patch when we're done with it. > It's already difficult enough for DBAs to debug some performance issues, > so getting rid of logging is a step backwards. I realize it's

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

Noah Misch writes: > On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote: >> I wonder if it's worth sticking some instrumentation into stats >> collector shutdown? > I wouldn't be surprised if the collector got backlogged during the main phase > of testing and took awhile

Re: [HACKERS] Tracing down buildfarm "postmaster does not shut down" failures

On 02/09/2016 10:27 PM, Tom Lane wrote: Noah Misch writes: On Tue, Feb 09, 2016 at 10:02:17PM -0500, Tom Lane wrote: I wonder if it's worth sticking some instrumentation into stats collector shutdown? I wouldn't be surprised if the collector got backlogged during the

Re: [HACKERS] Relation extension scalability

On Fri, Feb 5, 2016 at 4:50 PM, Amit Kapila wrote: > > Could you also measure how this behaves for an INSERT instead of a COPY > > workload? > > I think such a test will be useful. > I have measured the performance with insert to see the behavior when it don't use

Re: [HACKERS] Bug in StartupSUBTRANS

On Wed, Feb 10, 2016 at 3:45 AM, Tom Lane wrote: > Simon Riggs writes: >> Your patch looks right to me, so I will commit, barring objections... with >> backpatch. Likely to 9.0, AFAICS. > > 9.0 is out of support and should not be patched anymore. > > I

Re: [HACKERS] process type escape for log_line_prefix

On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund wrote: > Frequently when reading postgres logs to do some post mortem analysis > I'm left wondering what process emitted an error/log message. After the > fact it's often hard to know wether an error message was emitted by a >

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Tue, Feb 9, 2016 at 10:42 PM, Amit Kapila wrote: > On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote: >> Well, the idea is to improve the system responsiveness. Imagine that >> the call to GetProgressRecPtr() is done within the exclusive lock >> portion, but that while scanning the WAL

  1   2   >