Re: Allowing printf("%m") only where it actually works

Nico Williams writes: > On Sat, Aug 18, 2018 at 04:34:50PM -0400, Tom Lane wrote: >> So now I'm about ready to propose that we just *always* use >> snprintf.c, and forget all of the related configure probing. > You'd also get to ensure that all uses from *die() are > async-signal-safe. [ raised

Re: Allowing printf("%m") only where it actually works

On Sat, Aug 18, 2018 at 04:34:50PM -0400, Tom Lane wrote: > So now I'm about ready to propose that we just *always* use > snprintf.c, and forget all of the related configure probing. Yes. > This'd have some advantages, notably that we'd get the > useful_strerror() behavior in frontend as well as

Re: How to estimate the shared memory size required for parallel scan?

(Sorry, once I sent to Thomas only. This is re-post.) Hi Thomas, Thanks you for excellent explaining about shared memory in parallel scan and 'foreign path'. Those are points that I want to know. thanks. > If you just supply an IsForeignScanParallelSafe function that returns > true, that would a

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On 2018-Aug-18, Jonathan S. Katz wrote: > > > On Aug 18, 2018, at 8:52 PM, Jonathan S. Katz wrote: > > > >> > >> On Aug 18, 2018, at 8:45 PM, Michael Paquier wrote: > >> > >> I am not so sure about v11 as it is very close to release, surely we can > >> do something for HEAD as that's cosmeti

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Aug 18, 2018, at 8:52 PM, Jonathan S. Katz wrote:On Aug 18, 2018, at 8:45 PM, Michael Paquier wrote:I am not so sure about v11 as it is very close to release, surely we cando something for HEAD as that's cosmetic.  Anyway, if something isproposed, cou

Re: "could not reattach to shared memory" on buildfarm member dory

On Tue, May 01, 2018 at 11:31:50AM -0400, Tom Lane wrote: > Well, at this point the only thing that's entirely clear is that none > of the ideas I had work. I think we are going to be forced to pursue > Noah's idea of doing an end-to-end retry. Somebody else will need to > take point on that; I l

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

> On Aug 18, 2018, at 8:45 PM, Michael Paquier wrote: > >> On Sat, Aug 18, 2018 at 03:38:47PM -0700, David G. Johnston wrote: >>> On Saturday, August 18, 2018, Dave Cramer wrote: >>> I was referring to: >>> >>> "Materialized views are a type of relation so it is not wrong, just one >>> of man

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Sat, Aug 18, 2018 at 03:38:47PM -0700, David G. Johnston wrote: > On Saturday, August 18, 2018, Dave Cramer wrote: >> I was referring to: >> >> "Materialized views are a type of relation so it is not wrong, just one >> of many instances where we generalize to "relation" based in implementation

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Saturday, August 18, 2018, Dave Cramer wrote: > > I was referring to: > > "Materialized views are a type of relation so it is not wrong, just one > of many instances where we generalize to "relation" based in implementation > details ins team of being explicit about which type of relation is

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

> On Aug 17, 2018, at 6:30 PM, Alvaro Herrera wrote: > > On 2018-Aug-17, Jonathan S. Katz wrote: > >> Hi, >> >> I Initially pointed out here[1] that running REFRESH MATERIALIZED VIEW as a >> non-superuser or table owner yields the following message: >> >>test=> REFRESH MATERIALIZED VIEW b

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Sat, 18 Aug 2018 at 17:48, Tom Lane wrote: > Dave Cramer writes: > > This is a simple fix why push back ? > > What was being pushed back on, I think, was the claim that this needed to > be back-patched. I'd be inclined not to, since (a) the message is not > wrong, only less specific than it

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

> On Aug 18, 2018, at 5:48 PM, Tom Lane wrote: > > Dave Cramer writes: >> This is a simple fix why push back ? > > What was being pushed back on, I think, was the claim that this needed to > be back-patched. I'd be inclined not to, since (a) the message is not > wrong, only less specific than

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Dave Cramer writes: > > This is a simple fix why push back ? > > What was being pushed back on, I think, was the claim that this needed to > be back-patched. I'd be inclined not to, since (a) the message is not > wrong, only less specific than

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

Dave Cramer writes: > This is a simple fix why push back ? What was being pushed back on, I think, was the claim that this needed to be back-patched. I'd be inclined not to, since (a) the message is not wrong, only less specific than it could be, and (b) people tend to get annoyed by unnecessary

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Sat, 18 Aug 2018 at 17:30, Jonathan S. Katz wrote: > > On Aug 18, 2018, at 5:26 PM, David G. Johnston > wrote: > > On Saturday, August 18, 2018, Jonathan S. Katz > wrote: >> >> It’s cosmetic, but it’s a cosmetic bug: it incorrectly tells the user >> that they >> must be the owner of the “rel

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

> On Aug 18, 2018, at 5:26 PM, David G. Johnston > wrote: > > On Saturday, August 18, 2018, Jonathan S. Katz > wrote: > It’s cosmetic, but it’s a cosmetic bug: it incorrectly tells the user that > they > must be the owner of the “relational” when in reality it’s t

Re: Fix for REFRESH MATERIALIZED VIEW ownership error message

On Saturday, August 18, 2018, Jonathan S. Katz wrote: > > It’s cosmetic, but it’s a cosmetic bug: it incorrectly tells the user that > they > must be the owner of the “relational” when in reality it’s the > materialized view. > Materialized views are a type of relation so it is not wrong, just on

Re: remove ATTRIBUTE_FIXED_PART_SIZE

Andres Freund writes: > On August 18, 2018 8:37:00 PM GMT+02:00, Tom Lane wrote: >> Meh, I'm not sure about this. What about the possibility of trailing >> padding after the last fixed column, as the comment you propose to >> remove is talking about? Sure, we don't have that today, but we >> mi

Re: remove ATTRIBUTE_FIXED_PART_SIZE

On August 18, 2018 8:37:00 PM GMT+02:00, Tom Lane wrote: >Peter Eisentraut writes: >> Since the introduction of the CATALOG_VARLEN stuff, the fixed size of >> pg_attribute is exactly sizeof(FormData_pg_attribute), so the ancient >> mechanism to track the fixed size manually using >> ATTRIBUTE_

Re: Allowing printf("%m") only where it actually works

I wrote: > Consider the following approach: > 1. Teach src/port/snprintf.c about %m. While I've not written a patch > for this, it looks pretty trivial. > 2. Teach configure to test for %m and if it's not there, use the > replacement snprintf. (Note: we're already forcing snprintf replacement > i

Re: Fix hints on CREATE PROCEDURE errors

> On Aug 18, 2018, at 4:22 PM, Peter Eisentraut > wrote: > > This has been committed. Thanks - I’ve moved it off of the open items list. Jonathan signature.asc Description: Message signed with OpenPGP

Re: Fix hints on CREATE PROCEDURE errors

This has been committed. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: remove ATTRIBUTE_FIXED_PART_SIZE

Peter Eisentraut writes: > Since the introduction of the CATALOG_VARLEN stuff, the fixed size of > pg_attribute is exactly sizeof(FormData_pg_attribute), so the ancient > mechanism to track the fixed size manually using > ATTRIBUTE_FIXED_PART_SIZE can be removed. Meh, I'm not sure about this. Wh

remove ATTRIBUTE_FIXED_PART_SIZE

Since the introduction of the CATALOG_VARLEN stuff, the fixed size of pg_attribute is exactly sizeof(FormData_pg_attribute), so the ancient mechanism to track the fixed size manually using ATTRIBUTE_FIXED_PART_SIZE can be removed. -- Peter Eisentraut http://www.2ndQuadrant.com/ Postg

[GSoC] Summery of pg performance farm

Hello hackers, This is a late summary of pg performance farm in gsoc. Although it is not yet perfect, but it has began to take shape. 1. The implementation of the basic test results upload interface to ensure that the upload operation for the atomic level (including different client numbers in di

Re: Fix hints on CREATE PROCEDURE errors

> On Aug 8, 2018, at 3:18 PM, Tom Lane wrote: > > Peter Eisentraut writes: >> Yes, the hint should be changed. But I also think the error message >> should be changed to be more appropriate to the procedure situation >> (where is the return type?). Attached patch does both. Unlike your >> pa

Re: Pre-v11 appearances of the word "procedure" in v11 docs

> On Aug 17, 2018, at 10:15 AM, Peter Eisentraut > wrote: > > Attached are my proposed patches. The first is the documentation > change, which basically just substitutes the words, with some occasional > rephrasing. And then patches to extend the syntaxes of CREATE OPERATOR, > CREATE TRIGGER,

Re: TupleTableSlot abstraction

On 2018-08-17 01:07:06 -0700, Andres Freund wrote: > Hi, > > On 2018-08-17 12:10:20 +0530, Ashutosh Bapat wrote: > > We need to add LLVM code to fetch tts_flags and > > perform bit operation on it to get or set slow property. I haven't > > found any precedence for LLVM bit operations in postgresql

Re: How to estimate the shared memory size required for parallel scan?

On Sun, Aug 19, 2018 at 1:40 AM, Thomas Munro wrote: > A true parallel scan of an FDW would be one where each process emits > an arbitrary fraction of the tuples, but together they emit all of the > tuples. You'd almost certainly need to use some shared memory to > coordinate that. To say that y

Re: How to estimate the shared memory size required for parallel scan?

On Sun, Aug 19, 2018 at 12:01 AM, Masayuki Takahashi wrote: >> It's up to you to design a struct to hold whatever data, > spinlocks, LWLocks, atomics etc you might need to orchestrate your > parallel scan. > > If FDW(ex. cstore_fdw) does not need to share some information among > workers more than

Re: How to estimate the shared memory size required for parallel scan?

Hi Thomas, Thank you for explaining DSM and ToC. > It's up to you to design a struct to hold whatever data, spinlocks, LWLocks, atomics etc you might need to orchestrate your parallel scan. If FDW(ex. cstore_fdw) does not need to share some information among workers more than PostgreSQL core in

Re: docs: note ownership requirement for refreshing materialized views

On Fri, Aug 17, 2018 at 05:12:42PM -0400, Jonathan S. Katz wrote: >> On Aug 17, 2018, at 9:21 AM, Tom Lane wrote: >> Dave Cramer writes: >>> So it seems this patch is being ignored in this thread. >> >> Well, Jonathan did kind of hijack what appears to be a thread about >> documentation (with an