On Mon, Apr 9, 2018 at 5:52 PM, Amit Kapila wrote:
> On Sun, Apr 8, 2018 at 1:04 PM, Jeevan Chalke
> wrote:
> > Hi,
> >
> > At some places, I have observed that we are adding a partial path even
> when
> > rel's consider_parallel is false. Due to this, the partial path added has
> > parallel_saf
On Tue, Apr 10, 2018 at 03:15:47PM +0900, Amit Langote wrote:
> I too thought the same yesterday, as I couldn't see the commit even after
> about 35 minutes Alvaro actually had sent the email to -hackers (quoted
> above).
Bah, of course. Sorry for the noise.
--
Michael
signature.asc
Description:
Hi,
Trying covering indexes on partitioned tables i get this error
"""
postgres=# create index on t1_part (i) include (t);
ERROR: cache lookup failed for opclass 0
"""
To reproduce:
create table t1_part (i int, t text) partition by hash (i);
create table t1_part_0 partition of t1_part for value
On Mon, Apr 09, 2018 at 03:30:39PM +0300, Heikki Linnakangas wrote:
> There seems to be some confusion on the padding here. Firstly, what's the
> point of zero-padding the GID length to the next MAXALIGN boundary, which
> would be 8 bytes on 64-bit systems, if the start is only guaranteed 4-byte
>
Hi,
On Mon, Apr 9, 2018 at 10:46 PM, Tom Lane wrote:
> After further contemplation I decided that that was, in fact, the only
> reasonable way to improve matters. If we have multiple subdirectories
> independently firing the "make generated-headers" action, then we have
> parallel make hazards o
Hi.
I noticed that RelationBuildPartitionKey() is not doing the right thing
with respect to which context it passes to fmgr.c to set a the (cached)
partition support function's FmgrInfo's fn_mcxt.
I noticed a crash while trying to change partition pruning tests to use
manually created hash operat
I have added this in the Older Bugs section of open items page.
https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Older_Bugs
Thanks,
Amit
Hi,
There are some cases that power() function does not work
correctly with 'NaN' arguments in Windows environment.
Something like,
postgres=# select power('NaN',11);
ERROR: value out of range: underflow
postgres=# select power('NaN','NaN');
ERROR: value out of range: underflow
postgres=# sele
On 2018/04/10 13:27, Ashutosh Bapat wrote:
> On Mon, Apr 9, 2018 at 8:56 PM, Robert Haas wrote:
>> On Fri, Apr 6, 2018 at 11:41 PM, Tom Lane wrote:
>>> David Rowley writes:
Sounds like you're saying that if we have too many alternative files
then there's a chance that one could pass by
On Tue, Apr 10, 2018 at 10:08:16AM +0200, Julien Rouhaud wrote:
> Compilation of external extensions using PGXS appears to be broken
> since this commit:
>
> make[1]: *** /tmp/pgbuild/lib/postgresql/pgxs/src/makefiles/../../src/backend:
> No such file or directory. Stop.
> make: ***
> [/tmp/pgbu
On Fri, Mar 30, 2018 at 4:43 PM, Michael Paquier wrote:
> On Thu, Mar 01, 2018 at 04:01:28PM -0500, Robert Haas wrote:
>> If you have a clever idea how to make this work with as few atomic
>> operations as the current patch uses while at the same time reducing
>> the possibility of contention, I'm
On 2018/04/10 16:07, Jaime Casanova wrote:
> Hi,
>
> Trying covering indexes on partitioned tables i get this error
> """
> postgres=# create index on t1_part (i) include (t);
> ERROR: cache lookup failed for opclass 0
> """
>
> To reproduce:
>
> create table t1_part (i int, t text) partition b
Hi,
I used to run
"
cd src/backend
make submake-errcodes
"
in the RPM spec file, but looks like it was removed recently. Is that replaced
with something else, or removed completely?
Regards,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat Certified E
Re: Devrim Gündüz 2018-04-10 <1523353963.8169.26.ca...@gunduz.org>
> I used to run
>
> "
> cd src/backend
> make submake-errcodes
> "
>
> in the RPM spec file, but looks like it was removed recently. Is that replaced
> with something else, or removed completely?
It is gone:
https://git.postgresq
On Fri, Mar 30, 2018 at 5:37 AM, Fujii Masao wrote:
> On Wed, Jan 17, 2018 at 2:16 AM, Simon Riggs wrote:
>> On 16 January 2018 at 06:21, Michael Paquier
>> wrote:
>>> On Tue, Jan 16, 2018 at 10:40:43AM +0900, Masahiko Sawada wrote:
On Sun, Jan 14, 2018 at 12:43 AM, Simon Riggs
wrot
Hello,
One of our 2ndQuadrant support customers recently reported a sudden rush of
TOAST errors post a crash recovery, nearly causing an outage. Most errors
read like this:
ERROR: unexpected chunk number 0 (expected 1) for toast value
While we could bring back the cluster to normal quickly
Hello
See for example contrib pg_stat_statements extension. Setting
pg_stat_statements.max defined as PGC_POSTMASTER
regards, Sergei
Hello.
Note: This is not intended to be committed this time but just for
information.
At Tue, 10 Apr 2018 10:34:27 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180410.103427.244142052.horiguchi.kyot...@lab.ntt.co.jp>
> Just adding negation would work as a_expr is doing.
>
> >
Tom Lane writes:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> Tom Lane writes:
>>> I think you'd have to convert to text and back. That's kind of icky,
>>> but it beats failing.
>
>> I had a look, and that's what the PL/Python transform does. Attached is
>> a patc
On 10 April 2018 at 20:56, Amit Langote wrote:
> On 2018/04/10 13:27, Ashutosh Bapat wrote:
>> On Mon, Apr 9, 2018 at 8:56 PM, Robert Haas wrote:
>>> CREATE OR REPLACE FUNCTION hashint4_noop(int4, int8) RETURNS int8 AS
>>> $$SELECT coalesce($1,0)::int8$$ LANGUAGE sql IMMUTABLE;
>>> CREATE OPERATO
On Fri, 2018-04-06 at 20:31 +0200, Magnus Hagander wrote:
> I've been through this one again.
Thanks for taking the time!
> There is one big omission from it -- it fails to work with the view
> pg_hba_file_rules. When fixing that, things started to look kind of
> ugly with the "two booleans to ind
On Tue, Apr 10, 2018 at 5:32 PM, David Rowley
wrote:
> On 10 April 2018 at 20:56, Amit Langote wrote:
>> On 2018/04/10 13:27, Ashutosh Bapat wrote:
>>> On Mon, Apr 9, 2018 at 8:56 PM, Robert Haas wrote:
CREATE OR REPLACE FUNCTION hashint4_noop(int4, int8) RETURNS int8 AS
$$SELECT coale
On 10 April 2018 at 14:10, Michael Paquier wrote:
> Well, I think that there is place for improving reporting of failure
> in file_utils.c for frontends, or at worst have an exit() for any kind
> of critical failures equivalent to a PANIC.
Yup.
In the mean time, speaking of PANIC, here's the fi
On 4/10/18 08:10, Julian Markwort wrote:
>> Attached is an updated patch with these changes. I'd appreciate it if
>> you can run it through your tests to confirm that it didn't break any
>> of those usecases.
> I've tested a couple of things with this and it seems to work as
> expected. Unforunatel
Am Dienstag, den 10.04.2018, 15:59 +0530 schrieb Pavan Deolasee:
> One of our 2ndQuadrant support customers recently reported a sudden
> rush of
> TOAST errors post a crash recovery, nearly causing an outage. Most
> errors
> read like this:
>
> ERROR: unexpected chunk number 0 (expected 1) for toa
On 1/25/18 12:27 PM, Nikolay Shaplov wrote:
> В письме от 25 января 2018 11:29:34 пользователь Tom Lane написал:
>> Alvaro Herrera writes:
>>> Tom Lane wrote:
Well, maybe the right answer is to address that. It's clear to me
why that would happen if we store these things as reloptions o
Nikolay Shaplov wrote:
> В письме от 25 января 2018 11:29:34 пользователь Tom Lane написал:
> > Alvaro Herrera writes:
> > > Actually, Nikolay provided a possible solution: if you execute ALTER
> > > TABLE SET (toast.foobar = xyz), and a toast table doesn't exist, create
> > > one at that point.
On 3/29/18 9:40 AM, Tomas Vondra wrote:
> On 03/28/2018 08:55 PM, David Steele wrote:
>
>> I'm setting this entry to Waiting on Author, but based on the discussion
>> I think it should be Returned with Feedback.
>>
>
> Fine with me.
This entry has been marked Returned with Feedback.
Regards,
--
В письме от 10 апреля 2018 08:55:52 пользователь David Steele написал:
> On 1/25/18 12:27 PM, Nikolay Shaplov wrote:
> > В письме от 25 января 2018 11:29:34 пользователь Tom Lane написал:
> >> Alvaro Herrera writes:
> >>> Tom Lane wrote:
> Well, maybe the right answer is to address that. It'
On 4/9/18 11:56 AM, Alexander Korotkov wrote:
>
> Thank you very much for your efforts on reviewing this patch.
> I'm looking forward work with you on this feature for PG12.
Since there's a new patch I have changed the status to Needs Review and
moved the entry to the next CF.
Still, it seems to
Nikolay Shaplov wrote:
> But I need some confirmation, in order not to write patch in vain again :-)
Don't worry, rest assured that you will still write *many* patches in
vain, not just this one.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote
wrote:
>
> Attached fixes it. It teaches RelationBuildPartitionKey() to use
> fmgr_info_cxt and pass rd_partkeycxt to it.
The patch is using partkeycxt and not rd_partkeycxt. Probably a typo
in the mail. But a wider question, why that context? I gues
On 4/9/18 2:01 AM, Nikhil Sontakke wrote:
>
> Anyways, will now wait for the next commitfest/opportunity to try to
> get this in.
It looks like this patch should be in the Needs Review state so I have
done that and moved it to the next CF.
Regards,
--
-David
da...@pgmasters.net
On 3/27/18 11:13 AM, Nikita Glukhov wrote:
>
> Attached 14th version of the patches:
It appears this entry should be marked Needs Review, so I have done that
and moved it to the next CF.
Regards,
--
-David
da...@pgmasters.net
On 3/26/18 12:07 PM, Nikita Glukhov wrote:
> On 26.03.2018 17:19, David Steele wrote:
>
>> On 2/20/18 10:14 AM, Haozhou Wang wrote:
>>> Thank you very much for your review!
>>>
>>> I attached a new patch with typo fixed.
>> I think it's a bit premature to mark this Ready for Committer after a
>> r
On 10/04/18 13:29, Pavan Deolasee wrote:
Hello,
One of our 2ndQuadrant support customers recently reported a sudden rush of
TOAST errors post a crash recovery, nearly causing an outage. Most errors
read like this:
ERROR: unexpected chunk number 0 (expected 1) for toast value
While we coul
Julien Rouhaud writes:
> Compilation of external extensions using PGXS appears to be broken
> since this commit:
Ouch, sorry.
> I think the best fix if to define NO_GENERATED_HEADERS in pgxs.mk,
> patch attached.
Hm. I wonder if we don't also want NO_TEMP_INSTALL, like the doc/src/sgml
makefil
Hi Mark,
On 3/26/18 4:50 PM, Mark Rofail wrote:
> On 3/7/18 5:43 AM, Alvaro Herrera wrote:
>
> I searched for the new GIN operator so that I
> could brush it up for commit ahead of the rest -- only to find out that
> it was eviscerated from the patch between v5 and v5.1.
>
> The late
Hi Anastasia,
On 3/28/18 1:46 PM, David Steele wrote:
> On 2/27/18 8:54 PM, Michael Paquier wrote:
>> On Tue, Feb 27, 2018 at 05:52:20PM -0500, Tom Lane wrote:
>>> It already does treat SIGUSR1 as a log rotation request. Apparently
>>> the point of this patch is that some people don't find that e
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> While playing around some more with the extension, I discoverered a few
> more issues:
> ...
> 4) SV_to_JsonbValue() throws an error for infinite NVs, but not NaNs
The others sound like bugs, but that one's intentional, since
Hi Heikki,
On Tue, Apr 10, 2018 at 7:07 PM, Heikki Linnakangas wrote:
>
>>
> It would seem more straightforward to add a snapshot parameter to
> GetNewOidWithIndex(), so that the this one caller could pass SnapshotToast,
> while others pass SnapshotDirty. With your patch, you check the index
> t
Hello David,
On Tue, Apr 10, 2018 at 3:47 PM, David Steele wrote:
> You should produce a new version by then that addresses Alvaro's
> concerns and I imagine that will require quite a bit of discussion and
> work.
I'll get working.
I'll produce a patch with two alternate versions, one with and
Ashutosh Bapat wrote:
> On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote
> wrote:
> >
> > Attached fixes it. It teaches RelationBuildPartitionKey() to use
> > fmgr_info_cxt and pass rd_partkeycxt to it.
>
> The patch is using partkeycxt and not rd_partkeycxt. Probably a typo
> in the mail. But a wi
Mark Rofail wrote:
> Hello David,
>
> On Tue, Apr 10, 2018 at 3:47 PM, David Steele wrote:
>
> > You should produce a new version by then that addresses Alvaro's
> > concerns and I imagine that will require quite a bit of discussion and
> > work.
>
> I'll get working.
> I'll produce a patch wit
Hi Jeevan,
On 4/2/18 10:57 AM, Robert Haas wrote:
> On Thu, Mar 29, 2018 at 9:02 AM, Jeevan Chalke
> wrote:
>> Yep, I see the risk.
>
> Committed 0001 last week and 0002 just now. I don't really see 0003 a
> a critical need. If somebody demonstrates that this saves a
> meaningful amount of pla
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> I used to run
> "
> cd src/backend
> make submake-errcodes
> "
> in the RPM spec file, but looks like it was removed recently. Is that replaced
> with something else, or removed completely?
You could replace it with submake-generated-headers, since tha
2018-04-10 5:30 GMT-03:00 Huong Dangminh :
> There are some cases that power() function does not work
> correctly with 'NaN' arguments in Windows environment.
> Something like,
>
What is your exact OS version? What is your postgres version? I tested
with Windows 10 (10.0.16299) x64 and couldn't rep
Chapman Flack writes:
> I'm becoming increasingly glad I asked (or less embarrassed that I hadn't
> figured it all out yet). :)
> Am I right in thinking that, for my original purpose of detoasting something
> later in a transaction, all that matters is that I registered a snapshot
> from the tim
Tom Lane writes:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> While playing around some more with the extension, I discoverered a few
>> more issues:
>> ...
>> 4) SV_to_JsonbValue() throws an error for infinite NVs, but not NaNs
>
> The others sound like bugs, but th
/* XLOG stuff */
if (RelationNeedsWAL(rel))
{
...
if (P_ISLEAF(lpageop))
{
xlinfo = XLOG_BTREE_INSERT_LEAF;
/*
On Tue, Apr 10, 2018 at 3:59 PM, Alvaro Herrera
wrote:
>
> documentation to it and a few extensive tests to ensure it works well);
I think the existing regression tests verify that the patch works as
expectations, correct?
We need more *exhaustive* tests to test performance, not functionality.
On 4/10/18 6:14 AM, Masahiko Sawada wrote:
> On Fri, Mar 30, 2018 at 5:37 AM, Fujii Masao wrote:
>> On Wed, Jan 17, 2018 at 2:16 AM, Simon Riggs wrote:
>>> On 16 January 2018 at 06:21, Michael Paquier
>>> wrote:
On Tue, Jan 16, 2018 at 10:40:43AM +0900, Masahiko Sawada wrote:
> On Sun,
Mark Rofail wrote:
> On Tue, Apr 10, 2018 at 3:59 PM, Alvaro Herrera
> wrote:
> >
> > documentation to it and a few extensive tests to ensure it works well);
>
> I think the existing regression tests verify that the patch works as
> expectations, correct?
I meant for the GIN operator. (Remember,
On Tue, Apr 10, 2018 at 11:10 AM, Heikki Linnakangas wrote:
>> /* XLOG stuff */
>> if (RelationNeedsWAL(rel))
>> {
>> ...
>>
>> if (P_ISLEAF(lpageop))
>> {
>>
On Tue, Apr 10, 2018 at 7:49 PM, Claudio Freire
wrote:
> On Tue, Apr 10, 2018 at 11:10 AM, Heikki Linnakangas
> wrote:
>
> >
> > Why is this RelationSetTargetBlock() call inside the "XLOG stuff" block?
> > ISTM that we're failing to take advantage of this optimization for
> unlogged
> > tables,
On Tue, Apr 10, 2018 at 7:30 PM, David Steele wrote:
> Hi Jeevan,
>
> On 4/2/18 10:57 AM, Robert Haas wrote:
> > On Thu, Mar 29, 2018 at 9:02 AM, Jeevan Chalke
> > wrote:
> >> Yep, I see the risk.
> >
> > Committed 0001 last week and 0002 just now. I don't really see 0003 a
> > a critical need.
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Tom Lane writes:
>
>> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>>> While playing around some more with the extension, I discoverered a few
>>> more issues:
>>> ...
>>> 4) SV_to_JsonbValue() throws an error for inf
On 3 February 2018 at 12:04, Tom Lane wrote:
> Perhaps more useful to discuss: would that truly be the semantics we want,
> or should we just evaluate the expression and have done? It's certainly
> arguable that "IN (random())" ought to draw an error, not compute some
> random value and use that.
On 10 April 2018 at 23:13, Kyotaro HORIGUCHI
wrote:
> Note: This is not intended to be committed this time but just for
> information.
>
> At Tue, 10 Apr 2018 10:34:27 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20180410.103427.244142052.horiguchi.kyot...@lab.ntt.co.jp>
>> Just
>> Anyways, will now wait for the next commitfest/opportunity to try to
>> get this in.
>
> It looks like this patch should be in the Needs Review state so I have
> done that and moved it to the next CF.
>
Thanks David,
Regards,
Nikhils
--
Nikhil Sontakke http://www.2ndQuadrant
Jim Finnerty writes:
> What were the possible failure scenarios that throwing a fatal error was
> intended to avoid, i.e. what sort of "hooking into" is the comment below
> referring to that was regarded as a fate worse than death?
The point is that if the extension is marking the variable as
PGC
On Tue, Apr 10, 2018 at 12:47 PM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> On 2018/04/10 16:07, Jaime Casanova wrote:
> > Hi,
> >
> > Trying covering indexes on partitioned tables i get this error
> > """
> > postgres=# create index on t1_part (i) include (t);
> > ERROR: cache looku
On Tue, Apr 10, 2018 at 4:15 PM, David Steele wrote:
> On 4/9/18 11:56 AM, Alexander Korotkov wrote:
> >
> > Thank you very much for your efforts on reviewing this patch.
> > I'm looking forward work with you on this feature for PG12.
>
> Since there's a new patch I have changed the status to Nee
Changed CC to pgsql-hackers.
Tom Lane wrote:
> Alvaro Herrera writes:
> > Frankly, I don't like this. I would rather have an instrument->ntuples2
> > rather than these "divide this by nloops, sometimes" schizoid counters.
> > This is already being misused by ON CONFLICT (see "other_path" in
> >
On Mon, Apr 9, 2018 at 3:13 PM, Andres Freund wrote:
> Let's lower the pitchforks a bit here. Obviously a grand rewrite is
> absurd, as is some of the proposed ways this is all supposed to
> work. But I think the case we're discussing is much closer to a near
> irresolvable corner case than anyth
Hackers,
I have gone through all the remaining non-bug entries in CF 2018-03 and
pushed them or closed them as appropriate. The majority of the patches
were in Needs Review or Ready for Committer status and I did a brief
review of each to be sure the state was reasonable.
I moved a few Waiting o
David Steele wrote:
> Hackers,
>
> I have gone through all the remaining non-bug entries in CF 2018-03 and
> pushed them or closed them as appropriate. The majority of the patches
> were in Needs Review or Ready for Committer status and I did a brief
> review of each to be sure the state was reas
On 04/10/2018 10:06 AM, Tom Lane wrote:
> Chapman Flack writes:
>> Am I right in thinking that, for my original purpose of
>> detoasting something later in a transaction, all that matters
>> is that I registered a snapshot from the time at which I copied
>> the toasted datum, and the resource own
On 4/10/18 9:17 AM, Alvaro Herrera wrote:
> Nikolay Shaplov wrote:
>
>> But I need some confirmation, in order not to write patch in vain again :-)
>
> Don't worry, rest assured that you will still write *many* patches in
> vain, not just this one.
Despite the rather dubious pep talk, Álvaro is
Alvaro Herrera writes:
> Ashutosh Bapat wrote:
>> On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote
>> wrote:
>>> Attached fixes it. It teaches RelationBuildPartitionKey() to use
>>> fmgr_info_cxt and pass rd_partkeycxt to it.
>> The patch is using partkeycxt and not rd_partkeycxt. Probably a typo
On Tue, Apr 10, 2018 at 1:37 AM, Craig Ringer wrote:
> ... but *only if they hit an I/O error* or they're on a FS that
> doesn't reserve space and hit ENOSPC.
>
> It still does 99% of the job. It still flushes all buffers to
> persistent storage and maintains write ordering. It may not detect and
In writing extension update scripts, I find it to be really difficult to
grok diffs for example in changed view or function definitions when a new
extension script has to include the whole definition in a new file. I want
to rather use separate files for these objects, then use something like
psql
David Rowley writes:
> I imagined this would have had a check for volatile functions and some
> user-friendly error message to say partition bounds must be immutable,
> but instead, it does:
> postgres=# create table d_p1 partition of d for values in (Random());
> ERROR: specified value cannot b
Does the attached fix look correct? Haven't checked the fix with ATTACH
PARTITION though.
Attached patch seems to fix the problem. However, I would rather get
rid of modifying stmt->indexParams. That seems to be more logical
for me. Also, it would be good to check some covering index
Hi Robert,
On Tue, Apr 10, 2018 at 11:15:46AM -0400, Robert Haas wrote:
> On Mon, Apr 9, 2018 at 3:13 PM, Andres Freund wrote:
> > Let's lower the pitchforks a bit here. Obviously a grand rewrite is
> > absurd, as is some of the proposed ways this is all supposed to
> > work. But I think the cas
Alvaro Herrera writes:
> Questions:
> 1. Do we want to back-patch this to 10? I suppose (without checking)
> that EXPLAIN ANALYZE is already reporting bogus numbers for parallel
> index-only scans, so I think we should do that.
You can't back-patch a change in struct Instrumentation; that'd be
a
On 11 April 2018 at 03:14, Alvaro Herrera wrote:
> 2. Do we want to revert Andrew's test stabilization patch? If I
> understand correctly, the problem is the inverse of what was diagnosed:
> "any running transaction at the time of the test could prevent pages
> from being set as all-visible". Th
On 11 April 2018 at 03:42, Tom Lane wrote:
> Alvaro Herrera writes:
>> 2. Do we want to revert Andrew's test stabilization patch? If I
>> understand correctly, the problem is the inverse of what was diagnosed:
>> "any running transaction at the time of the test could prevent pages
>> from being
On Tue, Apr 10, 2018 at 11:14 AM, Alvaro Herrera
wrote:
> Questions:
> 1. Do we want to back-patch this to 10? I suppose (without checking)
> that EXPLAIN ANALYZE is already reporting bogus numbers for parallel
> index-only scans, so I think we should do that.
I haven't looked at this closely, b
* There is no pfree() within _bt_buildadd() for truncated tuples, even
though that's a context where it's clearly not okay.
Agree
* It might be a good idea to also pfree() the truncated tuple for most
other _bt_buildadd() callers. Even though it's arguably okay in other
cases, it seems worth b
On Tue, Apr 10, 2018 at 3:46 PM, Tom Lane wrote:
>
> Julien Rouhaud writes:
>> I think the best fix if to define NO_GENERATED_HEADERS in pgxs.mk,
>> patch attached.
>
> Hm. I wonder if we don't also want NO_TEMP_INSTALL, like the doc/src/sgml
> makefile. I don't know whether "make check" could
On Fri, Apr 6, 2018 at 8:59 PM, Andres Freund wrote:
> This is PROPARALLEL_RESTRICTED. That doesn't strike me right, shouldn't
> they be PROPARALLEL_UNSAFE? It might be fine, but I'd not want to rely
> on it.
Just a fine-grained note on this particular point:
It's totally fine for parallel-restr
Robert Haas wrote:
> On Tue, Apr 10, 2018 at 11:14 AM, Alvaro Herrera
> wrote:
> > Questions:
> > 1. Do we want to back-patch this to 10? I suppose (without checking)
> > that EXPLAIN ANALYZE is already reporting bogus numbers for parallel
> > index-only scans, so I think we should do that.
>
>
On 11 April 2018 at 03:34, Tom Lane wrote:
> David Rowley writes:
>> I imagined this would have had a check for volatile functions and some
>> user-friendly error message to say partition bounds must be immutable,
>> but instead, it does:
>
>> postgres=# create table d_p1 partition of d for value
On Tue, Apr 10, 2018 at 2:10 PM, Julian Markwort <
julian.markw...@uni-muenster.de> wrote:
> On Fri, 2018-04-06 at 20:31 +0200, Magnus Hagander wrote:
>
> I've been through this one again.
>
> Thanks for taking the time!
>
> There is one big omission from it -- it fails to work with the view
> pg_
On Tue, Apr 10, 2018 at 12:29 PM, Alvaro Herrera
wrote:
> In contrast, in an indexonly scan you have a single counter and it
> doesn't really matter the distribution of fetches done by workers, so it
> seems okay to aggregate them all in a single counter. And it being so
> simple, it seems reason
On 09.04.2018 20:05, Teodor Sigaev wrote:
Hi!
12 years ago I proposed patch to which could "union" OR clauses into
one range clause if it's possible. In that time pgsql could not use IS
NULL as index clause, so patch doesn't support that
https://www.postgresql.org/message-id/flat/45742C51.
On 9 April 2018 at 11:50, Anthony Iliopoulos wrote:
> On Mon, Apr 09, 2018 at 09:45:40AM +0100, Greg Stark wrote:
>> On 8 April 2018 at 22:47, Anthony Iliopoulos wrote:
> To make things a bit simpler, let us focus on EIO for the moment.
> The contract between the block layer and the filesystem l
On Tue, Apr 10, 2018 at 5:40 AM, Masahiko Sawada wrote:
> The probability of performance degradation can be reduced by
> increasing N_RELEXTLOCK_ENTS. But as Robert mentioned, while keeping
> fast and simple implementation like acquiring lock by a few atomic
> operation it's hard to improve or at
A report from a pgbouncer user revealed that running pg_dump -C/--create
does not work through a connection proxy if the virtual database name on
the proxy does not match the real database name on the database server.
That's because pg_dump looks up the database to be dumped using the
information f
Peter Eisentraut writes:
> A report from a pgbouncer user revealed that running pg_dump -C/--create
> does not work through a connection proxy if the virtual database name on
> the proxy does not match the real database name on the database server.
> That's because pg_dump looks up the database to
On 10 April 2018 at 02:59, Craig Ringer wrote:
> Nitpick: In most cases the kernel reserves disk space immediately,
> before returning from write(). NFS seems to be the main exception
> here.
I'm kind of puzzled by this. Surely NFS servers store the data in the
filesystem using write(2) or the i
Julien Rouhaud writes:
> On Tue, Apr 10, 2018 at 3:46 PM, Tom Lane wrote:
>> Hm. I wonder if we don't also want NO_TEMP_INSTALL, like the doc/src/sgml
>> makefile. I don't know whether "make check" could be useful in a PGXS
>> build, but certainly that recipe for making a temp install isn't gon
David Rowley writes:
> On 11 April 2018 at 03:34, Tom Lane wrote:
>> Well, that just begs the question: why do these expressions need to
>> be immutable? What we really want, I think, is to evaluate them
>> and reduce them to constants. After that, it hardly matters whether
>> the original expr
On Tue, Apr 10, 2018 at 6:58 PM, Tom Lane wrote:
>
> Well, the question that's bothering me is how come "make check" in
> an external build doesn't try to execute the temp-install rule before
> printing that error message. Experimentation shows that it doesn't,
> but it sure looks to me like it s
Hi,
On Tue, 2018-04-10 at 10:01 -0400, Tom Lane wrote:
> You could replace it with submake-generated-headers, since that's more
> general, but in principle you shouldn't need anything because that
> target is invoked automatically as of yesterday. What's the larger
> context here --- why do you
On Tue, Apr 10, 2018 at 2:59 AM, Jeevan Chalke
wrote:
> I actually wanted to have rel->consider_parallel in the condition (yes, for
> additional safety) as we are adding a partial path into rel. But then
> observed that it is same as that of final_rel->consider_parallel and thus
> used it along wi
Julien Rouhaud writes:
> On Tue, Apr 10, 2018 at 6:58 PM, Tom Lane wrote:
>> none of the three if-guards in the temp-install rule itself should
>> prevent this, so what is preventing it? I don't see it.
> I just checked, and for the record the second rule (ifneq
> ($(abs_top_builddir),) is actu
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> On Tue, 2018-04-10 at 10:01 -0400, Tom Lane wrote:
>> You could replace it with submake-generated-headers, since that's more
>> general, but in principle you shouldn't need anything because that
>> target is invoked automatically as of yesterday. What'
On Tue, Apr 10, 2018 at 9:07 AM, David Steele wrote:
> On 3/29/18 9:40 AM, Tomas Vondra wrote:
>> On 03/28/2018 08:55 PM, David Steele wrote:
>>> I'm setting this entry to Waiting on Author, but based on the discussion
>>> I think it should be Returned with Feedback.
>>
>> Fine with me.
>
> This e
1 - 100 of 167 matches
Mail list logo
