On Wed, Apr 6, 2016 at 3:09 PM, Michael Paquier
wrote:
> On Sat, Apr 2, 2016 at 12:30 AM, Tom Lane wrote:
>> I wrote:
>>> So the core of my complaint is that we need to fix things so that, whether
>>> or not we are able to create the PGRES_FATAL_ERROR PGresult (and we'd
>>> better consider the be
On 2016/04/18 15:38, Ashutosh Bapat wrote:
>> There was no KeyTypeCollInfo in early days of the patch and then I found
>> myself doing a lot of:
>>
>> partexprs_item = list_head(key->partexprs);
>> for (attr in key->partattrs)
>> {
>> if (attr->attnum != 0)
>> {
>> // simple column
Hi,
I checked in PG 9.6 , if we create an aggregate function with saying -
parallel=safe/restricted/unsafe and then take
a pg_dumpall of the entire cluster , "parallel= " is missing from create
aggregate syntax
Steps to reproduce -
.)connect to psql terminal and create an aggregate function
Is the following description now outdated:
"ForeignPath represents a potential scan of a foreign table"
Considering that there now exists FdwRoutine.GetForeignJoinPaths() whose
product is nothing else but a ForeignPath, should it now say (patch attached):
"ForeignPath represents a potential scan
On Mon, Apr 18, 2016 at 1:23 PM, Amit Langote wrote:
> On 2016/04/18 15:38, Ashutosh Bapat wrote:
> >> There was no KeyTypeCollInfo in early days of the patch and then I found
> >> myself doing a lot of:
> >>
> >> partexprs_item = list_head(key->partexprs);
> >> for (attr in key->partattrs)
> >>
Got it. Thanks for explaining that. Was looking at -S earlier and didn't
notice the new -b and @ weight options in 9.6devel.
On Mon, 18 Apr 2016 at 10:54 Fabien COELHO wrote:
>
> >> For the future 9.6, scripts options are cumulatives, so -f & -S can be
> >> combined.
> >>
> >> Indeed, for the <=
On 2016/04/18 15:33, Ashutosh Bapat wrote:
>> For time being, I will leave this as yet unaddressed (I am thinking about
>> what is reasonable to do for this also considering Robert's comment). Is
>> that OK?
>>
>
> Right now EXPLAIN of select * from t1, where t1 is partitioned table shows
> Appen
On Sat, Apr 16, 2016 at 5:37 AM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>> On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
>> > I think the bottom line is that we misdesigned the WAL representation
>> > by assuming that this sort of info could always be piggybacked on a
>> > transaction commit
On 18 April 2016 at 12:43, Michael Paquier
wrote:
> On Sat, Apr 16, 2016 at 5:37 AM, Alvaro Herrera
> wrote:
> > Andres Freund wrote:
> >> On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
> >> > I think the bottom line is that we misdesigned the WAL representation
> >> > by assuming that this sort
On Sun, Apr 17, 2016 at 10:38 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>
>> After struggling with back-patching a GIN bug fix, I wish to offer up the
>> considered opinion that this was an impressively bad idea. It's inserted
>> 450 or so pain points for back-patching, which we will have to de
Michael Paquier writes:
> On Mon, Apr 18, 2016 at 12:31 PM, Peter Eisentraut wrote:
>> I don't know if it's worth tracking this as an open item and thus
>> kind-of release blocker if no one else has the problem. But I
>> definitely still have it. My initial suspicion was that this had
>> someth
On 2016-04-15 17:37:03 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
> > > I think the bottom line is that we misdesigned the WAL representation
> > > by assuming that this sort of info could always be piggybacked on a
> > > transaction commit
On 2016-04-18 20:43:30 +0900, Michael Paquier wrote:
> Yeah, introducing a new WAL record to address this issue in
> back-branches would not be an issue, and that's what we should do. For
> HEAD, let's add that in the commit record.
I'm not sure why/how you'd do it that way in HEAD? I mean the onl
Kevin Grittner writes:
> On Sun, Apr 17, 2016 at 10:38 PM, Alvaro Herrera
> wrote:
>> I understand the backpatching pain argument, but my opinion was the
>> contrary of yours even so.
> The other possibility would be to backpatch the no-op patch which
> just uses the new syntax without any chang
On 2016-04-18 13:15:19 +0100, Simon Riggs wrote:
> OK, I'll write up a patch today to fix, with a view to backpatching.
Cool. I've spent a couple minutes on this yesterday, and have the start
of a patch - do you want that?
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Alvaro Herrera writes:
> I disagree. A developer that sees an unadorned BufferGetPage() call
> doesn't stop to think twice about whether they need to add a snapshot
> test. Many reviewers will miss the necessary addition also. A
> developer that sees BufferGetPage(NO_SNAPSHOT_TEST) will at leas
On Fri, Apr 15, 2016 at 12:45 AM, Jeff Janes wrote:
> Should every relevant contrib extension get a version bump with a
> transition file which is nothing but a list of "alter function blah
> blah blah parallel safe" ?
Yes, I think that's what we would need to do. It's a lot of work,
albeit most
On Sun, Apr 17, 2016 at 6:15 PM, Tom Lane wrote:
> After struggling with back-patching a GIN bug fix, I wish to offer up the
> considered opinion that this was an impressively bad idea. It's inserted
> 450 or so pain points for back-patching, which we will have to deal with
> for the next five ye
* Noah Misch (n...@leadboat.com) wrote:
> On Thu, Apr 07, 2016 at 03:50:47PM -0400, Stephen Frost wrote:
> > I'm planning to continue going over the patch tomorrow morning with
> > plans to push this before the feature freeze deadline.
>
> > --- a/src/test/regress/expected/rolenames.out
> > +++ b/
On Mon, Apr 18, 2016 at 8:41 AM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Sun, Apr 17, 2016 at 10:38 PM, Alvaro Herrera
>> wrote:
>>> I understand the backpatching pain argument, but my opinion was the
>>> contrary of yours even so.
>
>> The other possibility would be to backpatch the no-o
On Fri, Apr 15, 2016 at 11:56 AM, Stephen Frost wrote:
> Perhaps it would be helpful to return to the initial goal of these
> default roles.
>
> We've identified certain privileges which are currently superuser-only
> and we would like to be able to be GRANT those to non-superuser roles.
> Where o
Julien Rouhaud writes:
> On 16/04/2016 20:45, Tom Lane wrote:
>> I think this needs to be redesigned so that the critical section and WAL
>> insertion calls all happen within a single straight-line piece of code.
>>
>> We could try making that place be ginPlaceToPage(). So far as
>> registerLeaf
On Mon, Apr 18, 2016 at 5:30 AM, tushar
wrote:
>
>
> Hi,
>
> I checked in PG 9.6 , if we create an aggregate function with saying -
parallel=safe/restricted/unsafe and then take
> a pg_dumpall of the entire cluster , "parallel= " is missing from create
aggregate syntax
>
> Steps to reproduce -
>
>
Added, see attached patch (based on v3.1)
With this applied, I am getting a couple errors I have not seen before
after extensive crash recovery testing:
ERROR: attempted to delete invisible tuple
ERROR: unexpected chunk number 1 (expected 2) for toast value
100338365 in pg_toast_16425
Huh, see
Tom Lane wrote:
> Alvaro Herrera writes:
> > I disagree. A developer that sees an unadorned BufferGetPage() call
> > doesn't stop to think twice about whether they need to add a snapshot
> > test. Many reviewers will miss the necessary addition also. A
> > developer that sees BufferGetPage(NO_S
On Fri, Apr 15, 2016 at 2:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 14, 2016 at 1:01 PM, Andres Freund wrote:
>>> I'm not sure I find that convincing: The state portrayed by the syscache
>>> is th state COPY/SELECT et al will be using. I think the angle to
>>> attack this is r
Craig Ringer wrote:
> On 18 April 2016 at 12:11, David Rowley
> wrote:
>
> > this is not helping me much as I don't really understand why
> > pg_statistic need to be frozen?
>
> Yeah, in particular it's not clear to me why pg_upgrade goes to such
> efforts to freeze everything when it copies pg_
Robert Haas writes:
> On Fri, Apr 15, 2016 at 2:51 PM, Tom Lane wrote:
>> The problem here is the connection to syscache; changing the behavior
>> of that, in a general context, is very scary. What we might be able to
>> do that would satisfy pg_dump's needs is to invent a mode in which you
>> c
Andres Freund writes:
> On April 16, 2016 6:02:39 PM PDT, Tom Lane wrote:
>> I went ahead and prepared and tested such a patch; the version for 9.3
>> is attached. (9.2 is identical modulo some pgindent-induced whitespace
>> difference.) This doesn't look too hazardous to me, so I'm thinking
>>
Hello
Today I've read this post:
http://blog.2ndquadrant.com/code-coverage/
I think its great and that everyone in this mailing list should
familiarize themselves with it.
Reading the coverage report, I discovered that some code is never
executed. Sometimes its OK (error reporting in out-of-mem
On 2016-04-18 11:07:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On April 16, 2016 6:02:39 PM PDT, Tom Lane wrote:
> >> I went ahead and prepared and tested such a patch; the version for 9.3
> >> is attached. (9.2 is identical modulo some pgindent-induced whitespace
> >> difference.) T
Aleksander Alekseev writes:
> For instance there are two flags - HASH_SEGMENT and HASH_FFACTOR that
> are in fact never used (see attachment). I wonder whether we should
> keep code like this or not.
> What do you think?
The fact that make check-world doesn't run any code that uses some
feature
Hi
2016-04-12 7:10 GMT+02:00 Tom Lane :
> Arcadiy Ivanov writes:
> > Is there any interest and/or tips to allow a pluggable parser or at
> > least allow some syntactical pluggability by extensions?
>
> There is a fair amount of discussion of this in the archives. The short
> answer is that biso
Andres Freund writes:
> On 2016-04-18 11:07:08 -0400, Tom Lane wrote:
>> Did you want to actually review this patch, or should I just push it?
> No, I'm good, you should push it. I did a quick scan of the patch, and
> it looks sane. For a second I was concerned that there might be a
> situation i
> I cannot to imagine extensible parser based on bison. But the parser
> can be replaced by custom parser.
>
> Some like pgpool or pgbouncer does. The extension can assign own
> parser. Custom parser will be called first, and the integrated parser
> will be used from extension or as fallback. This
On 2016-04-18 11:24:07 -0400, Tom Lane wrote:
> (The thing that gave me pause about this was noticing that I could not
> start two such postmasters concurrently on my RHEL6 box, without changing
> the default system limits on number of SysV semaphores.)
Hm, is that different before/after the patch
2016-04-18 17:25 GMT+02:00 Aleksander Alekseev :
> > I cannot to imagine extensible parser based on bison. But the parser
> > can be replaced by custom parser.
> >
> > Some like pgpool or pgbouncer does. The extension can assign own
> > parser. Custom parser will be called first, and the integrate
On Mon, Apr 18, 2016 at 11:24 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-04-18 11:07:08 -0400, Tom Lane wrote:
>>> Did you want to actually review this patch, or should I just push it?
>
>> No, I'm good, you should push it. I did a quick scan of the patch, and
>> it looks sane. For a
Andres Freund writes:
> On 2016-04-18 11:24:07 -0400, Tom Lane wrote:
>> (The thing that gave me pause about this was noticing that I could not
>> start two such postmasters concurrently on my RHEL6 box, without changing
>> the default system limits on number of SysV semaphores.)
> Hm, is that di
Hello, Tom.
Thanks for your reply.
> The fact that make check-world doesn't run any code that uses some
> feature isn't a great argument for removing it. Consider third-party
> extensions, for starters.
What is current policy regarding such sort of things? Is everything
that is in .h files cons
> It depends - can be allowed only one - like plpgsql extensions, or
> can be serialized like pg log extensions
OK, I understand "can be allowed only one". I doubt it would be a very
useful feature though.
I'm not sure what do you mean by "serialized like pg log extensions".
Lets say extension A
On Mon, Apr 18, 2016 at 11:34 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-04-18 11:24:07 -0400, Tom Lane wrote:
>>> (The thing that gave me pause about this was noticing that I could not
>>> start two such postmasters concurrently on my RHEL6 box, without changing
>>> the default syste
On 18/04/2016 16:33, Tom Lane wrote:
>
> I poked at this over the weekend, and got more unhappy the more I poked.
> Aside from the memory leakage issue, there are multiple coding-rule
> violations besides the one you noted about scope of the critical sections.
> One example is that in the page-spl
On Mon, Apr 18, 2016 at 11:53 AM, Robert Haas wrote:
> On Mon, Apr 18, 2016 at 11:34 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2016-04-18 11:24:07 -0400, Tom Lane wrote:
(The thing that gave me pause about this was noticing that I could not
start two such postmasters concurre
2016-04-18 17:44 GMT+02:00 Aleksander Alekseev :
> > It depends - can be allowed only one - like plpgsql extensions, or
> > can be serialized like pg log extensions
>
> OK, I understand "can be allowed only one". I doubt it would be a very
> useful feature though.
>
> I'm not sure what do you mean
On Mon, Apr 18, 2016 at 8:50 AM, Tom Lane wrote:
> Surely there was another way to get a similar end result without
> mucking with things at the level of BufferGetPage.
To get the feature that some customers have been demanding, a check
has to be made somewhere near where any page is read in a s
2016-04-11 15:37 GMT+02:00 Merlin Moncure :
> On Sun, Apr 10, 2016 at 3:13 AM, Pavel Stehule
> wrote:
> >
> > Hi
> >
> > 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
> >>
> >> Hi
> >>
> >> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
> >>>
> >>> Patch is trivial (see below), discussion is not :-).
>
Kevin Grittner writes:
> On Mon, Apr 18, 2016 at 8:50 AM, Tom Lane wrote:
>> Surely there was another way to get a similar end result without
>> mucking with things at the level of BufferGetPage.
> To get the feature that some customers have been demanding, a check
> has to be made somewhere nea
Hackers, lurkers,
The PostgreSQL Project needs you!
The Release Management Team would like your input regarding the patch or
patches which, in your opinion, are the most likely sources of major
bugs or instabilities in PostgreSQL 9.6.
Please submit your answers before May 1st using this form:
ht
On Wed, Apr 13, 2016 at 6:50 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > Interesting to me would be a way, perhaps with an option in initdb, to
> > just say, initialize this cluster compatibly with that other cluster, so
> > you don't have to worry about these details.
>
> Good idea, thou
Tom Lane wrote:
> Peter Eisentraut writes:
> > Interesting to me would be a way, perhaps with an option in initdb, to
> > just say, initialize this cluster compatibly with that other cluster, so
> > you don't have to worry about these details.
>
> Good idea, though I'd think of it as a pg_upgrade
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 15, 2016 at 11:56 AM, Stephen Frost wrote:
> > Perhaps it would be helpful to return to the initial goal of these
> > default roles.
> >
> > We've identified certain privileges which are currently superuser-only
> > and we would l
On Mon, 18 Apr 2016 15:37:21 -0300
Alvaro Herrera wrote:
> Hackers, lurkers,
>
> The PostgreSQL Project needs you!
>
> The Release Management Team would like your input regarding the patch or
> patches which, in your opinion, are the most likely sources of major
> bugs or instabilities in Postg
On 04/18/2016 11:37 AM, Alvaro Herrera wrote:
> Hackers, lurkers,
>
> The PostgreSQL Project needs you!
>
> The Release Management Team would like your input regarding the patch or
> patches which, in your opinion, are the most likely sources of major
> bugs or instabilities in PostgreSQL 9.6.
>
Hi,
Pursuant to promises made in Brussels a couple of months ago, I set up a
machine to run and expose the "make coverage" report under "make
check-world". Some people have already heard about this.
I would like to collect ideas on how to improve this. For example
* Should we run something oth
On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, Apr 18, 2016 at 12:31 PM, Peter Eisentraut wrote:
> >> I don't know if it's worth tracking this as an open item and thus
> >> kind-of release blocker if no one else has the problem. But I
> >> definit
Noah Misch writes:
> On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote:
>> Given that it's apparently showing the results of asind as NULL ...
> I doubt asind is returning NULL. Here's the query, which uses a CASE to
> report NULL if asind returns any value not on a whitelist:
> SELECT x
On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote:
> >> Given that it's apparently showing the results of asind as NULL ...
>
> > I doubt asind is returning NULL. Here's the query, which uses a CASE to
> >
On Mon, Apr 18, 2016 at 09:56:28AM -0400, Robert Haas wrote:
> On Fri, Apr 15, 2016 at 12:45 AM, Jeff Janes wrote:
> > Should every relevant contrib extension get a version bump with a
> > transition file which is nothing but a list of "alter function blah
> > blah blah parallel safe" ?
>
> Yes,
On Sat, Apr 16, 2016 at 08:59:40AM +0900, Michael Paquier wrote:
> On Fri, Apr 15, 2016 at 9:46 PM, Michael Paquier
> wrote:
> > On Fri, Apr 15, 2016 at 8:25 PM, Etsuro Fujita
> > wrote:
> >> How about doing something similar for PQprepare/PQexecPrepared in
> >> postgresExecForeignInsert, postgre
On Tue, Apr 19, 2016 at 12:16 PM, Noah Misch wrote:
> On Sat, Apr 16, 2016 at 08:59:40AM +0900, Michael Paquier wrote:
>> On Fri, Apr 15, 2016 at 9:46 PM, Michael Paquier
>> wrote:
>> > On Fri, Apr 15, 2016 at 8:25 PM, Etsuro Fujita
>> > wrote:
>> >> How about doing something similar for PQprepa
On 2016/04/19 12:26, Michael Paquier wrote:
On Tue, Apr 19, 2016 at 12:16 PM, Noah Misch wrote:
On Sat, Apr 16, 2016 at 08:59:40AM +0900, Michael Paquier wrote:
Here is a new version. I just recalled that I forgot a PQclear() call
to clean up results.
Thanks for updating the patch!
Rober
Noah Misch writes:
> On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
>> We could alternatively set extra_float_digits to its max value and hope
>> that off-by-one-in-the-last-place values would get printed as something
>> visibly different from the exact result. I'm not sure I want to t
On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
> >> We could alternatively set extra_float_digits to its max value and hope
> >> that off-by-one-in-the-last-place values would get printed as something
> >
On 2016/04/19 12:45, Etsuro Fujita wrote:
On 2016/04/19 12:26, Michael Paquier wrote:
Note for Robert: pgfdw_get_result copycats PQexec by discarding all
PQresult received except the last one. I think that's fine for the
purposes of postgres_fdw, but perhaps you have a different opinion on
the m
On Tue, Apr 19, 2016 at 1:14 PM, Etsuro Fujita
wrote:
> The comment "We don't use a PG_TRY block here ..." seems to be wrongly
> placed, so I moved that comment. Also, I think it'd be better to call
> pgfdw_report_error() with the clear argument set to false, not true, since
> we don't need to cl
On Tue, Apr 19, 2016 at 3:14 AM, Tom Lane wrote:
> Or in short: this is a whole lot further than I'm prepared to go to
> satisfy one customer with a badly-designed application. And from what
> I can tell from the Feb 2015 discussion, that's what this has been
> written for.
This holds true. I im
On 2016/04/19 13:59, Michael Paquier wrote:
On Tue, Apr 19, 2016 at 1:14 PM, Etsuro Fujita
wrote:
What do you think about that?
+ /* Wait for the result */
+ res = pgfdw_get_result(conn, query);
+ if (res == NULL)
+ pgfdw_report_error(ERROR, NULL, conn, false, query);
+ last_re
Michael Paquier wrote:
> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> wrote:
> > Now, I have produced two patches:
> > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
> > __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
> > hack, though I am coming to t
On Tue, Apr 19, 2016 at 2:42 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> wrote:
>> > Now, I have produced two patches:
>> > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>> > __crt_locale_data_public in ucrt/corecrt.
70 matches
Mail list logo
