On 4 January 2016 at 20:44, Alvaro Herrera wrote:
> Maybe
> there are more ALTER TABLE subcommands that should be setting something
> up? In cases where multiple subcommands are being run, it might be
> useful to see which one caused a certain error message.
>
I like the patch.
We should have
On 2016/01/05 14:30, Atri Sharma wrote:
> On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote
>> On 2016/01/05 3:53, Atri Sharma wrote:
>>> I was wary to use SPI inside the executor for node evaluation functions.
>>> Does it seem safe?
>>
>> What is "node evaluation functions"? Is it "Plan" nodes or "Exp
On Mon, Jan 4, 2016 at 9:37 PM, Chapman Flack wrote:
> On 01/05/16 00:18, Michael Paquier wrote:
>
>> with MSVC what is used instead of dynloader.h is
>> port/dynloader/win32.h.
>
> Seems like a good catch - AFAICS, what happens with port/dynloader
> is that for 12 different OSes, there's an .h fi
Michael Paquier writes:
> On Sat, Jan 2, 2016 at 4:06 AM, Tom Lane wrote:
>> The grammar fixes seem like a good thing to do in the long run, too,
>> but there's little need to risk back-patching it since accepting
>> col_name_keywords without quoting would be mostly a convenience issue.
> A diff
On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote:
> Michael Paquier writes:
>> The patch would put the buildfarm in red as it is incomplete anyway,
>> with MSVC what is used instead of dynloader.h is
>> port/dynloader/win32.h. Instead of this patch I would be incline to
>> remove the #define stuff
Atri Sharma writes:
> I fail to see the relevance of which node is getting evaluated (its a Plan
> node BTW) for this question. The concern I had was around using SPI inside
> executor and its fail safety.
The code path executor -> PL function -> SPI certainly works, so
presumably omitting the in
On 01/05/16 00:18, Michael Paquier wrote:
> with MSVC what is used instead of dynloader.h is
> port/dynloader/win32.h.
Seems like a good catch - AFAICS, what happens with port/dynloader
is that for 12 different OSes, there's an .h file there to
be copied _renamed to dynloader.h_ into the build tr
On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote
wrote:
> On 2016/01/05 3:53, Atri Sharma wrote:
> > I was wary to use SPI inside the executor for node evaluation functions.
> > Does it seem safe?
>
> What is "node evaluation functions"? Is it "Plan" nodes or "Expr" nodes
> that you are talking about
Michael Paquier writes:
> The patch would put the buildfarm in red as it is incomplete anyway,
> with MSVC what is used instead of dynloader.h is
> port/dynloader/win32.h. Instead of this patch I would be incline to
> remove the #define stuff with dynloader.h that use WIN32_ONLY_COMPILER
> (see fo
On Tue, Jan 5, 2016 at 10:13 AM, Tom Lane wrote:
> Michael Paquier writes:
>> So, here are the commands that still remain with TailMatches to cover
>> this case, per gram.y:
>> - CREATE TABLE
>> - CREATE INDEX
>> - CREATE VIEW
>> - GRANT
>> - CREATE TRIGGER
>> - CREATE SEQUENCE
>> New patches are
On Mon, Jan 4, 2016 at 10:06 AM, Bruce Momjian wrote:
> On Mon, Jan 4, 2016 at 12:59:26PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>> > On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
>> >> If we're willing to allow 9.4.6 to install different files than 9.4.5
>> >> does, I don't
On 2016/01/05 3:53, Atri Sharma wrote:
> I was wary to use SPI inside the executor for node evaluation functions.
> Does it seem safe?
What is "node evaluation functions"? Is it "Plan" nodes or "Expr" nodes
that you are talking about? I guess you'd know to use ExecProcNode() or
ExecEvalExpr() for
On Tue, Jan 5, 2016 at 1:52 AM, Robert Haas wrote:
> On Mon, Jan 4, 2016 at 4:50 AM, Dilip Kumar wrote:
> > I tried to create a inner table such that, inner table data don't fit in
> RAM
> > (I created VM with 1GB Ram).
> > Purpose of this is to make Disk scan dominant,
> > and since parallel jo
Michael Paquier writes:
> So, here are the commands that still remain with TailMatches to cover
> this case, per gram.y:
> - CREATE TABLE
> - CREATE INDEX
> - CREATE VIEW
> - GRANT
> - CREATE TRIGGER
> - CREATE SEQUENCE
> New patches are attached.
I've reviewed and committed the first of these pa
On Tue, Jan 5, 2016 at 1:04 AM, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> So we've had several rounds of discussions about simplifying replication
>> configuration in general and the wal_level setting in particular. [0][1]
>> Let's get something going.
>
> I looked at this patch, which I
> - Modify the functions in regproc.c. Take a look at how other text input
> functions work to see what needs to happen here (you'll want to use
> text_to_cstring() as part of that.)
>
> - Modify the appropriate entries in src/include/catalog/pg_proc.h
Let me try.
`make check` says "All 160 tests
On Mon, Jan 4, 2016 at 5:22 PM, Stephen Frost wrote:
>> So, is this another case where the support is all in off-list fora and
>> thus invisible, or can you point to specific on-list discussions where
>> it was supported, and to the opinions offered in support? I don't
>> really remember many opi
On Mon, Jan 4, 2016 at 4:56 PM, Stephen Frost wrote:
>> First, it's not really going to matter to users very much whether the
>> command to enable one of these features is a single GRANT command or a
>> short sequence of GRANT commands executed one after another. So even
>> if we don't have roles
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 3:07 PM, Stephen Frost wrote:
> > I'm not sure it's entirely relevant now- I've outlined the reasoning in
> > my email to Noah as a, hopefully, pretty comprehensive summary. If that
> > doesn't sway your minds then it seems unl
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 4, 2016 at 12:55 PM, Stephen Frost wrote:
> > I'd like to be able to include, in both of those, a simple set of
> > instructions for granting the necessary rights to the user who is
> > running those processes. A set of rights which an ad
On Mon, Jan 4, 2016 at 3:07 PM, Stephen Frost wrote:
> I'm not sure it's entirely relevant now- I've outlined the reasoning in
> my email to Noah as a, hopefully, pretty comprehensive summary. If that
> doesn't sway your minds then it seems unlikely that a reference to a
> thread from 6 months or
On Mon, Jan 4, 2016 at 12:55 PM, Stephen Frost wrote:
> I'd like to be able to include, in both of those, a simple set of
> instructions for granting the necessary rights to the user who is
> running those processes. A set of rights which an administrator can go
> look up and easily read and unde
On Mon, Jan 4, 2016 at 3:48 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>
>> But you could also write SELECT relname FROM pg_class WHERE
>> pg_relation_size(oid) > 100 * 1024^3, which is actually fewer
>> characters. Maybe pg_size_bytes('100 GB') is easier for some people
>> to remember than 1
2016-01-04 21:44 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > 2015-10-05 0:08 GMT+02:00 Marko Tiikkaja :
> >
> > > In the past I've found the error message in cases such as this somewhat
> > > less helpful than it could be:
> > >
> > > =# CREATE TABLE qqq (a int);
> > > =# CREATE UNIQUE I
Robert Haas wrote:
> But you could also write SELECT relname FROM pg_class WHERE
> pg_relation_size(oid) > 100 * 1024^3, which is actually fewer
> characters. Maybe pg_size_bytes('100 GB') is easier for some people
> to remember than 100 * 1024^3, but I'm probably not one of those
> people.
Nah,
All the to_reg* functions in src/backend/utils/adt/regproc.c currently
accept a cstring. Per [1], they should accept text. This should be a
fairly simple change to make:
- Modify the functions in regproc.c. Take a look at how other text input
functions work to see what needs to happen here (yo
Pavel Stehule wrote:
> 2015-10-05 0:08 GMT+02:00 Marko Tiikkaja :
>
> > In the past I've found the error message in cases such as this somewhat
> > less helpful than it could be:
> >
> > =# CREATE TABLE qqq (a int);
> > =# CREATE UNIQUE INDEX IF NOT EXISTS qqq_a_idx ON qqq(a);
> > =# ALTER TABLE q
* Peter Geoghegan (p...@heroku.com) wrote:
> On Mon, Jan 4, 2016 at 12:13 PM, Tom Lane wrote:
> > I've pushed an example based on your original test case. Feel free
> > to suggest improvements, although at this point they'll probably
> > land in 9.5.1.
>
> I think that that's a vast improvement.
2016-01-04 21:29 GMT+01:00 Robert Haas :
> On Mon, Jan 4, 2016 at 12:17 PM, Shulgin, Oleksandr
> wrote:
> >> I'm also kind of wondering what the intended use case for this
> >> function is. Why do we want it? Do we want it?
> >
> > As suggested above a usecase could be like the following:
> >
>
On Mon, Jan 4, 2016 at 12:13 PM, Tom Lane wrote:
> I've pushed an example based on your original test case. Feel free
> to suggest improvements, although at this point they'll probably
> land in 9.5.1.
I think that that's a vast improvement. I probably should have pushed
for a worked out example
On Mon, Jan 4, 2016 at 12:17 PM, Shulgin, Oleksandr
wrote:
>> I'm also kind of wondering what the intended use case for this
>> function is. Why do we want it? Do we want it?
>
> As suggested above a usecase could be like the following:
>
> SELECT relname FROM pg_class WHERE pg_relation_size(oid
On Mon, Jan 4, 2016 at 3:05 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
>> wrote:
>> > Peter Eisentraut wrote:
>> >> So we've had several rounds of discussions about simplifying replication
>> >> configuration in general and the wal_level sett
On Mon, Jan 4, 2016 at 4:50 AM, Dilip Kumar wrote:
> I tried to create a inner table such that, inner table data don't fit in RAM
> (I created VM with 1GB Ram).
> Purpose of this is to make Disk scan dominant,
> and since parallel join is repeating the Disk Scan and hash table building
> of inner
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch wrote:
> > The proposed pg_replication role introduces abstraction that could, as you
> > hope, spare a DBA from studying sets of functions to grant together. The
> > pg_rotate_logfile role, however
On 1/3/16 10:37 PM, Tom Lane wrote:
It's not a release stopper, but I plan to fix it in HEAD whenever I have
an idle hour.
Since I'm sure there's much better things you can be working on I was
going to just do this myself. Then it occurred to me that this should be
a great item for a new hack
On 1/4/16 12:53 PM, Atri Sharma wrote:
Please don't top-post.
On 5 Jan 2016 12:20 am, "Jim Nasby" mailto:jim.na...@bluetreble.com>> wrote:
On 1/4/16 12:07 PM, Atri Sharma wrote:
Hi All,
I wanted to check if it is possible to query a non catalog table
in backend.
I wrote:
> I'll go draft something up ...
I've pushed an example based on your original test case. Feel free
to suggest improvements, although at this point they'll probably
land in 9.5.1.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> > Updated patch attached. I'll give it another good look and then commit
> >> > it, barring objections.
> >>
> >> This thread and its satellite[1]
Robert Haas wrote:
> On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
> wrote:
> > Peter Eisentraut wrote:
> >> So we've had several rounds of discussions about simplifying replication
> >> configuration in general and the wal_level setting in particular. [0][1]
> >> Let's get something going.
> >
On Mon, Jan 4, 2016 at 11:04 AM, Alvaro Herrera
wrote:
> Peter Eisentraut wrote:
>> So we've had several rounds of discussions about simplifying replication
>> configuration in general and the wal_level setting in particular. [0][1]
>> Let's get something going.
>
> I looked at this patch, which
Adam Brightwell wrote:
> While working on an auth hook, I found that I was unable to access the
> pg_shseclabel system table while processing the hook.
[ ... ]
> Given that the shared relations currently exposed can also have
> security labels that can be used for auth purposes, I believe it makes
Vitaly Burovoy wrote:
> Majority of the votes for NULL for "other things" except epoch.
> Nobody answers about differences between monotonic and oscillating values.
>
> I suppose behavior of monotonic values (julian, century, decade,
> isoyear, millennium and year) should be the same as for epoch
CC'ing Teodor because he's author of one of the patches.
Alexander Lebedev wrote:
> Hello, Hacker.
So, can we have a more thorough explanation of what is the point of this
patch? If it is supposed to improve the performance of searching for
boxes, can we see measurements from some benchmark? Do
On Mon, Jan 4, 2016 at 6:18 PM, Tom Lane wrote:
>> VAX (simh):
>> https://docs.google.com/presentation/d/1PG-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/view
>
>> Fuzzer:
>> https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/view
>
> Very cool, thanks!
Incidentally,
Thanks!
I was wary to use SPI inside the executor for node evaluation functions.
Does it seem safe?
Regards,
Atri
On 5 Jan 2016 12:20 am, "Jim Nasby" wrote:
> On 1/4/16 12:07 PM, Atri Sharma wrote:
>
>> Hi All,
>>
>> I wanted to check if it is possible to query a non catalog table in
>> backen
On 1/4/16 12:07 PM, Atri Sharma wrote:
Hi All,
I wanted to check if it is possible to query a non catalog table in backend.
I understand that cql interface is only for catalog querying hence it is
not usable for this purpose per se.
AFAIK it's possible to do it with low level routines, but I
[ getting back to this now that there's a little time ]
Peter Geoghegan writes:
> On Sun, Jan 3, 2016 at 7:01 PM, Peter Geoghegan wrote:
>> I would also advise only referencing a single relation within the
>> SELECT FOR UPDATE.
> To state what may be obvious: We should recommend that SELECT FOR
Shulgin, Oleksandr wrote:
> A make from an external build dir fails on install, suggested fix:
>
> install: all
> $(MKDIR_P) '$(DESTDIR)$(includedir)'/pglogical_output
> - $(INSTALL_DATA) pglogical_output/hooks.h
> '$(DESTDIR)$(includedir)'/pglogical_output
> + $(INSTALL_DATA)
> $(top_srcdir)/con
Greg Stark writes:
> I used plenty of images I pulled off the net without regard for
> copyright so I hesitated to put it up. I suppose that's par for the
> course with these kinds of presentations. In any case it was just a
> quick lightning talk I threw together to describe a few days of mostly
Hi All,
I wanted to check if it is possible to query a non catalog table in backend.
I understand that cql interface is only for catalog querying hence it is
not usable for this purpose per se.
Please advice.
Regards,
Atri
On Mon, Jan 4, 2016 at 12:59:26PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
> >> If we're willing to allow 9.4.6 to install different files than 9.4.5
> >> does, I don't see why it's a problem for 9.5.1. But having said that,
> >
Bruce Momjian writes:
> On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
>> If we're willing to allow 9.4.6 to install different files than 9.4.5
>> does, I don't see why it's a problem for 9.5.1. But having said that,
>> I agree that this seems pretty low-risk, and so IMO we might as we
Christoph Berg wrote:
> Re: Andres Freund 2016-01-04 <20160104155125.gd28...@awork2.anarazel.de>
> > That's probably not the only non-deterministic rule in postgres, given
> > nobody paid attention tot that so far? At least transform modules added
> > in 9.5 (hstore_plpython et al) look like they m
On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Dec 31, 2015, at 1:04 PM, Bruce Momjian wrote:
> >> Let's hold this for 9.5.1 and all minor releases will get it at the same
> >> time.
>
> > I vote for going ahead with this at once. It seems low risk, and ha
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
>
> > The one argument which you've put forth for adding the complexity of
> > dumping catalog ACLs is that we might reduce the number of defa
Based on the feedback here, I have returned this patch to Needs Review
status. (Waiting on Author would be fairer actually, since we are
waiting for an updated version.)
As far as I can make it from Noah and Robert's comments, what we would
like to see here is a way for pg_dump to output nondefau
2016-01-04 18:13 GMT+01:00 Shulgin, Oleksandr
:
> On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule
> wrote:
> >
> > 2016-01-04 17:48 GMT+01:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
> >>
> >> On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas
> wrote:
> >>>
> >>> On Mon, Jan 4, 2016 at 10:
2016-01-04 18:14 GMT+01:00 Robert Haas :
> On Mon, Jan 4, 2016 at 11:48 AM, Shulgin, Oleksandr
> wrote:
> > On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas
> wrote:
> >>
> >> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule >
> >> wrote:
> >> > [ new patch ]
> >>
> >> + case '-':
> >> +
On Sun, Jan 3, 2016 at 7:21 PM, Tomasz Rybak wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:tested, failed
>
> Ap
Here are the current numbers, now that the commitfest has actually
closed for business:
Needs review: 79.
Waiting on Author: 5.
Ready for Committer: 6.
Committed: 8.
Total: 98.
Of those RfC patches, one ("Default Roles") doesn't actually seem ready
to commit, since there's been some significa
Peter Eisentraut wrote:
> So we've had several rounds of discussions about simplifying replication
> configuration in general and the wal_level setting in particular. [0][1]
> Let's get something going.
I looked at this patch, which I think has got enough consensus that you
should just push forwa
On Mon, Jan 4, 2016 at 6:14 PM, Robert Haas wrote:
> On Mon, Jan 4, 2016 at 11:48 AM, Shulgin, Oleksandr
> >
> > postgres=# select pg_size_bytes('');
> > ERROR: invalid input syntax for type numeric: ""
>
> I think that's a pretty bad error message. I mean, the user is
> calling a function that
On Mon, Jan 4, 2016 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK, well, if the consensus is in favor of a back-patch, so be it. It
>> seems a little strange to me to back-patch a commit that doesn't fix
>> anything, but I just work here.
>
> Well, it's true that we can't point to spe
On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule
wrote:
>
> 2016-01-04 17:48 GMT+01:00 Shulgin, Oleksandr <
oleksandr.shul...@zalando.de>:
>>
>> On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas
wrote:
>>>
>>> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule
wrote:
>>> > [ new patch ]
>>>
>>> + cas
On Mon, Jan 4, 2016 at 11:48 AM, Shulgin, Oleksandr
wrote:
> On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas wrote:
>>
>> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule
>> wrote:
>> > [ new patch ]
>>
>> + case '-':
>> + ereport(ERROR,
>> + (errcode(ERRCODE_IN
2016-01-04 17:48 GMT+01:00 Shulgin, Oleksandr
:
> On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas wrote:
>
>> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule
>> wrote:
>> > [ new patch ]
>>
>> + case '-':
>> + ereport(ERROR,
>> + (errcode(ERRCODE_INVALID_PARAM
On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas wrote:
> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule
> wrote:
> > [ new patch ]
>
> + case '-':
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("size cannot be
On Fri, Jan 1, 2016 at 12:34 AM, Petr Jelinek wrote:
> Hi,
>
> I'd like to submit the replication solution which is based on the
> pglogical_output [1] module (which is obviously needed for this to compile).
>
Hi,
Impressive stuff!
Apparently this depends on a newer, yet-to-be-published versio
Andreas Karlsson writes:
> I thought I saw some patch from you changing many of the rules from
> TailMatches() to Matches(). Perhaps I should just update my patch after
> your patch has been applied.
Yes, I think it's important to get that set of patches from Michael
into the tree ASAP so that
On 01/04/2016 07:26 AM, Michael Paquier wrote:
You may want to use Matches() instead of TailMatches() for performance reasons.
Probably, but if so should we not also change the surrounding rules to
also use Matches()? I imitated the surrounding code to keep code
consistency and avoid errors.
Re: Andres Freund 2016-01-04 <20160104155125.gd28...@awork2.anarazel.de>
> That's probably not the only non-deterministic rule in postgres, given
> nobody paid attention tot that so far? At least transform modules added
> in 9.5 (hstore_plpython et al) look like they might similar issues.
I was wo
On Mon, Jan 04, 2016 at 04:51:25PM +0100, Andres Freund wrote:
> Hi,
>
> On 2016-01-04 15:59:46 +0100, Christoph Berg wrote:
> > The list of objects used to link pg_xlogdump is coming from
> > $(wildcard *desc.c) which returns them in filesystem order. This makes
> > the build result depend on thi
On 4 January 2016 at 15:17, Pavel Stehule wrote:
> Hi
>
> 2016-01-04 12:46 GMT+01:00 Shulgin, Oleksandr
> :
>>
>> On Wed, Dec 30, 2015 at 8:28 PM, Pavel Stehule
>> wrote:
>>>
>>>
>>>
>>> 2015-12-30 17:33 GMT+01:00 Robert Haas :
On Mon, Dec 28, 2015 at 8:45 AM, Shulgin, Oleksandr
w
2016-01-04 16:51 GMT+01:00 Robert Haas :
> On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule
> wrote:
> > [ new patch ]
>
> + case '-':
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("size cannot be negative")
On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule wrote:
> [ new patch ]
+ case '-':
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("size cannot be negative")));
Why not? I bet if you copy any - sign to the buffer
Robert Haas writes:
> OK, well, if the consensus is in favor of a back-patch, so be it. It
> seems a little strange to me to back-patch a commit that doesn't fix
> anything, but I just work here.
Well, it's true that we can't point to specific field reports and say
that this will fix those. But
On Mon, Jan 4, 2016 at 10:49 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-01-04 10:35:12 -0500, Robert Haas wrote:
>>> If we don't know of a specific problem that would be fixed by
>>> back-patching this commit to pre-9.5 branches, and it seems like we
>>> don't, then I don't really see
Hi,
On 2016-01-04 15:59:46 +0100, Christoph Berg wrote:
> The list of objects used to link pg_xlogdump is coming from
> $(wildcard *desc.c) which returns them in filesystem order. This makes
> the build result depend on this ordering, yielding different
> compilation results.
> -RMGRDESCSOURCES =
Andres Freund writes:
> On 2016-01-04 10:35:12 -0500, Robert Haas wrote:
>> If we don't know of a specific problem that would be fixed by
>> back-patching this commit to pre-9.5 branches, and it seems like we
>> don't, then I don't really see much upside to back-patching it. I
>> mean, yeah, we t
On Mon, Jan 4, 2016 at 8:08 AM, Masahiko Sawada wrote:
> Attached patch fixes the comment typo in RewindTest.pm
> Please find it.
Committed and back-patched to 9.5.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing li
Magnus Hagander writes:
> On Mon, Jan 4, 2016 at 4:20 PM, Tom Lane wrote:
>> I'm slightly worried about breaking 3rd-party code that might be using
>> recv() and somehow expecting the current behavior. However, it's equally
>> arguable that such code would have Windows-specific problems that wou
On 2016-01-04 10:35:12 -0500, Robert Haas wrote:
> If we don't know of a specific problem that would be fixed by
> back-patching this commit to pre-9.5 branches, and it seems like we
> don't, then I don't really see much upside to back-patching it. I
> mean, yeah, we think that this is wrong becau
On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane wrote:
>> This seems like a might subtle thing to backpatch. If we really want to
>> go there, ISTM that the relevant code should stew in an unreleased
>> branch for a while, before being backpatched.
>
> I'm definitely -1 on back-patching such a thing. P
On Mon, Jan 4, 2016 at 10:22 AM, Magnus Hagander wrote:
> On Mon, Jan 4, 2016 at 4:20 PM, Tom Lane wrote:
>> Andres Freund writes:
>> > I wonder if we ought to backport this further: e.g. walsender
>> > continously uses nonblocking sockets via pq_getbyte_if_available(). On
>> > the other hand I
Andres Freund writes:
> On 2016-01-03 15:40:01 +, Simon Riggs wrote:
>> I'm happy with this being a simple patch now, not least because I would
>> like to backpatch this to 9.4 where catalog scans became MVCC.
>>
>> A backpatch is warranted because it is a severe performance issue with
>> rep
On Mon, Jan 4, 2016 at 4:20 PM, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if we ought to backport this further: e.g. walsender
> > continously uses nonblocking sockets via pq_getbyte_if_available(). On
> > the other hand I can't immediately see a problem with that, besides
> > differi
On 2016-01-04 10:20:43 -0500, Tom Lane wrote:
> I'm slightly worried about breaking 3rd-party code that might be using
> recv() and somehow expecting the current behavior. However, it's equally
> arguable that such code would have Windows-specific problems that would be
> fixed by the patch.
I do
Andres Freund writes:
> I wonder if we ought to backport this further: e.g. walsender
> continously uses nonblocking sockets via pq_getbyte_if_available(). On
> the other hand I can't immediately see a problem with that, besides
> differing messages on windows/the rest of the world.
I'm slightly
Hi
2016-01-04 12:46 GMT+01:00 Shulgin, Oleksandr
:
> On Wed, Dec 30, 2015 at 8:28 PM, Pavel Stehule
> wrote:
>
>>
>>
>> 2015-12-30 17:33 GMT+01:00 Robert Haas :
>>
>>> On Mon, Dec 28, 2015 at 8:45 AM, Shulgin, Oleksandr
>>> wrote:
>>> > I didn't check out earlier versions of this patch, but th
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The RLS patch added this to struct Query:
>
> List *withCheckOptions;/* a list of WithCheckOption's, which
> * are only added during rewrite and
> * the
The list of objects used to link pg_xlogdump is coming from
$(wildcard *desc.c) which returns them in filesystem order. This makes
the build result depend on this ordering, yielding different
compilation results.
This patch fixes the reproducibility issue:
--- a/src/bin/pg_xlogdump/Makefile
+++ b
On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila wrote:
> On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas wrote:
>> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila
>> wrote:
>> > LWLock *LWLockAssignFromTranche(const char *tranche_name) will
>> > assign a lock for the specified tranche. This also ensures t
amul sul writes:
> In inheritance, child column's pg_attribute.attislocal flag not getting
> updated, if it is inherited using ALTER TABLE INHERIT .
I think this patch is wrong and you have broken the intended behavior.
It's a bit hard to tell though because your example is confused.
> CREATE
On Mon, Jan 4, 2016 at 9:28 AM, Rushabh Lathia wrote:
> On Mon, Jan 4, 2016 at 4:41 PM, amul sul wrote:
>> Hi,
>> In inheritance, child column's pg_attribute.attislocal flag not getting
>> updated, if it is inherited using ALTER TABLE INHERIT .
>>
>> Due to this, if we try to drop column(s) from
Hi,
On Mon, Jan 4, 2016 at 8:11 PM, amul sul wrote:
> Hi,
>
> In inheritance, child column's pg_attribute.attislocal flag not getting
> updated, if it is inherited using ALTER TABLE INHERIT .
>
> Due to this, if we try to drop column(s) from parent table, which are not
> getting drop from chil
On Mon, Jan 4, 2016 at 6:24 AM, Michael Paquier
wrote:
> Arg, actually it is not:
> https://wiki.postgresql.org/wiki/PostgreSQL_Conference_Europe_Talks_2015
> Greg could you add it there?
No, apparently that page is restricted to only some users.
I used plenty of images I pulled off the net with
On 01/03/2016 06:43 PM, Tom Lane wrote:
I see two ways to fix this.
1) Never use expanded display for the case where there is only one
column. There seems to me like there is little value in using expanded
display for when you only have one column, but I may be missing some use
case here.
2
On Mon, Jan 4, 2016 at 4:41 PM, amul sul wrote:
> Hi,
>
> In inheritance, child column's pg_attribute.attislocal flag not getting
> updated, if it is inherited using ALTER TABLE INHERIT .
>
> Due to this, if we try to drop column(s) from parent table, which are not
> getting drop from child.
> A
Tom Lane wrote:
> But some experimentation suggests that we could
> fix that by subdividing col_name_keyword into two categories, one being
> the keywords that can also be type names (BIGINT, BIT, etc) and one
> being those that can't (BETWEEN, COALESCE, etc). Everywhere
> col_name_keyword is use
Hi all,
Attached patch fixes the comment typo in RewindTest.pm
Please find it.
Regards,
--
Masahiko Sawada
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index c1c7d1f..41d294e 100644
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -
1 - 100 of 114 matches
Mail list logo