On 15/01/2019 08:18, Pavel Stehule wrote:
> I would to have a mechanism for safe replacement of triggers of type
>
> if TG_TYPE = 'INSERT' THEN
> NEW.inserted := CURRENT_TIMESTAMP;
> ELSE IF TG_TYPE = 'UPDATE' THEN
> NEW.updated := CURRENT_TIMESTAMP;
> ..
That kind of use is probably better
From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> I don't know what PgJDBC is doing, however I think libpq needs to do
> more than just retrying.
>
> 1) Try to find a node on which pg_is_in_recovery() returns false. If
>found, then we assume that is the primary. We also assume that
>other n
On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote:
> NOTICE seems unnecessary here.
>
> Unfortunally concurrently reindex loses comments, reproducer:
Yes, the NOTICE message makes little sense.
I am getting back in touch with this stuff. It has been some time but
the core of the p
st 16. 1. 2019 v 9:26 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 15/01/2019 08:18, Pavel Stehule wrote:
> > I would to have a mechanism for safe replacement of triggers of type
> >
> > if TG_TYPE = 'INSERT' THEN
> > NEW.inserted := CURRENT_TIMESTAMP;
> > ELSE IF
On Wed, Jan 16, 2019 at 5:24 AM Robert Haas wrote:
>
> On Mon, Jan 14, 2019 at 9:24 PM Masahiko Sawada wrote:
> > I think that because the tuples that got dead after heap_page_prune()
> > looked are recorded but not removed without lazy_vacuum_page() we need
> > to process them in lazy_vacuum_pag
On 1/16/19 1:40 AM, Kuroda, Hayato wrote:
By the way, I think the name of this parameter should be changed.
In the Cambridge dictionary, the word "rate" means as follows:
the speed at which something happens or changes,
or the amount or number of times it happens or changes in a particular perio
On Tue, Jan 15, 2019 at 2:51 PM Tomas Vondra
wrote:
> What do you mean by "raw statistic"?
>
I mean without further calculation to consider other operation
>
> IMHO the best thing you can do is call estimate_num_groups() and combine
> that with the number of input rows. That shall benefit fro
On Wed, Jan 16, 2019 at 2:03 AM Adrien NAYRAT
wrote:
>
> On 1/15/19 11:42 AM, Masahiko Sawada wrote:
> >> When you troubleshoot applicative issues with multi-statements
> >> transaction, you may have to log all queries to find all statements of one
> >> transaction. With high throughput, it coul
On 07/01/2019 00:16, Tom Lane wrote:
> BTW, this is a pre-existing problem not the fault of this patch,
> but while we're fooling with the behavior of python lookup would
> be a great time to fix it: we should add something like
>
> AC_ARG_VAR([PYTHON], [path to Python executable])
>
> Aside from
(2019/01/16 15:21), Ashutosh Bapat wrote:
On Wed, Jan 16, 2019 at 11:22 AM Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2019/01/15 13:29), Ashutosh Bapat wrote:
> I think, there's something better possible. Two partitioned relations
> won't use partition-wise join, if
Michael-san,
(2019/01/16 15:54), Michael Paquier wrote:
On Wed, Jan 16, 2019 at 02:59:15PM +0900, Etsuro Fujita wrote:
(2019/01/07 20:26), Etsuro Fujita wrote:
On second thought I'd like to propose another option:
execute_foreign_modify because I think this would match the existing
helper func
Hi hackers,
Consider this query plan:
create table t (i int, b bool);
create index on t(i, b);
set enable_bitmapscan to off;
explain select * from t where i = 300 and b;
QUERY PLAN
-
Index On
Hello Tomas,
On 16.01.2019 03:23, Tomas Vondra wrote:
I've looked at the patch today, and in general is seems quite solid to
me. I do have a couple of minor points
1) I think the comments need more work. Instead of describing all the
individual changes here, I've outlined those improvements in
Hi,
During the discussion in [1] an idea about refactoring ArchiveEntry was
suggested. The reason is that currently this function has significant number of
arguments that are "optional", and every change that has to deal with it
introduces a lot of useless diffs. In the thread, mentioned above, su
> On Wed, Jan 16, 2019 at 1:16 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Hi,
>
> During the discussion in [1] an idea about refactoring ArchiveEntry was
> suggested. The reason is that currently this function has significant number
> of
> arguments that are "optional", and every change t
Hi,
Per discussion in [1] about generic type subscripting pathc Pavel had
interesting commentary. So far jsonb_set, if is invoked for a jsonb array with
an index outside of the array boundaries, will implicitely add a value:
=# insert into table values('["a", "b", "c"]');
=# update table set data
On Tue, 15 Jan 2019 at 08:21, Tomas Vondra wrote:
> Turns out you were right - the attribute_referenced piece was quite
> unnecessary. So I've removed it. I've also extended the regression tests
> to verify changing type of another column does not reset the stats.
(Trying to find my feet over her
On 15/01/2019 08:13, Michael Paquier wrote:
> When testing a bulk INSERT into a table which has a stored generated
> column, memory keeps growing in size linearly, which does not seem
> normal to me. If inserting more tuples than what I tested (I stopped
> at 10M because of lack of time), it seems
Peter Eisentraut wrote:
> > On a table with pre-existing contents, the creation of a unique index
> > does not seem to detect the duplicates that are equal per the
> > collation and different binary-wise.
>
> Fixed in the attached updated patch.
Check. I've found another issue with aggre
On Fri, Jan 11, 2019 at 3:54 AM John Naylor wrote:
>
> On Wed, Jan 9, 2019 at 10:50 PM Amit Kapila wrote:
> > Thanks, Mithun for performance testing, it really helps us to choose
> > the right strategy here. Once John provides next version, it would be
> > good to see the results of regular pgbe
On Wed, Jan 16, 2019 at 9:25 AM Mithun Cy wrote:
>
> On Fri, Jan 11, 2019 at 3:54 AM John Naylor
> wrote:
> >
> > On Wed, Jan 9, 2019 at 10:50 PM Amit Kapila wrote:
> > > Thanks, Mithun for performance testing, it really helps us to choose
> > > the right strategy here. Once John provides next
Hello,
I already sent the following message to postgres-xl-developers list but
they don't seem so active. Therefore, I hope you accept this kind of
messages to this mail list.
I'm planning to run PostgreSQL-XL data nodes on CephFS as shared folder. My
goal is to provide scalability (auto/manual)
As discussed in the Ryu thread, herewith a draft of a patch to use
strtof() for float4 input (rather than using strtod() with its
double-rounding issue).
An exhaustive search shows that this does not change the resulting
bit-pattern for any input string that could have been generated by PG
with ex
On Tue, Jan 15, 2019 at 11:37 PM Tom Lane wrote:
> Well, as I said upthread, it seems like we need to think a bit more
> carefully about what it is that clause_is_strict_for is testing ---
> and if that ends up finding that some other name is more apposite,
> I'd not have any hesitation about rena
Alexander Kuzmenkov writes:
> The filter is not needed, why is it there? Turns out we can't recognize
> that the restriction clause 'b' and the index clause 'b = true' are
> equivalent.
Yeah, it's intentional that we don't get rid of the extra clause;
it doesn't really seem worth the expense an
>
> On Tue, Jan 15, 2019 at 10:17 AM Shay Rojansky wrote:
> > Unfortunately I'm extremely tight for time at the moment and don't have
> time to do the appropriate hot standby setup to test this... As the patch
> is pretty straightforward, and since I'm hoping you guys execute the tests
> on your e
Andrew Gierth writes:
> As discussed in the Ryu thread, herewith a draft of a patch to use
> strtof() for float4 input (rather than using strtod() with its
> double-rounding issue).
The errno handling in strtof seems bizarrely overcomplex; why do
you need the separate caller_errno variable?
> Th
> "Tom" == Tom Lane writes:
>> As discussed in the Ryu thread, herewith a draft of a patch to use
>> strtof() for float4 input (rather than using strtod() with its
>> double-rounding issue).
Tom> The errno handling in strtof seems bizarrely overcomplex; why do
Tom> you need the separate
On Tue, Jan 15, 2019 at 8:48 PM Michael Paquier wrote:
> > So the answer to your question is: the WAL receiver fails to start.
>
> Robert, does this answer your question? I agree that depending on the
> timing, we could finish by having the startup process spawning a WAL
> receiver with a given c
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The errno handling in strtof seems bizarrely overcomplex; why do
> Tom> you need the separate caller_errno variable?
> Eh. I was preserving the conventional behaviour of setting errno only on
> errors and not resetting it to 0,
Oh, I se
On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
wrote:
> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
> because nodes/relation.h is related to planner. utils/rel.h is some how
> related to relation caches.
Insofar as we can reasonably do so, I'd rather pick unique names for
See if Windows likes this one any better.
--
Andrew (irc:RhodiumToad)
diff --git a/configure b/configure
index 06fc3c6835..e3176e24e9 100755
--- a/configure
+++ b/configure
@@ -15802,6 +15802,19 @@ esac
fi
+ac_fn_c_check_func "$LINENO" "strtof" "ac_cv_func_strtof"
+if test "x$ac_cv_func_str
Robert Haas writes:
> On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> wrote:
>> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
>> because nodes/relation.h is related to planner. utils/rel.h is some how
>> related to relation caches.
> Insofar as we can reasonably do so, I'd
Andrew Gierth writes:
> See if Windows likes this one any better.
Doubtful, because AFAICT it's the same patch.
regards, tom lane
On Sat, Jan 12, 2019 at 4:36 PM Thomas Munro
wrote:
> 1. We need a new "bgreader" process to do read-ahead. I think you'd
> want a way to tell it with explicit hints (for example, perhaps
> sequential scans would advertise that they're reading sequentially so
> that it starts to slurp future blo
On 09/01/2019 09:20, Mi Tar wrote:
> I tested this patch and it applied cleanly and all tests passed. I haven't
> looked if the changes to tests are reasonable or extensive to cover all
> aspects of what they want to cover.
I have committed this with additional tests for partitioned tables, as
r
On January 16, 2019 8:08:09 AM PST, Robert Haas wrote:
>On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> wrote:
>> access/relation.[c|h] name is fine. Or how about access/rel.[c|h],
>> because nodes/relation.h is related to planner. utils/rel.h is some
>how
>> related to relation caches.
>
>In
On 14/01/2019 15:37, Andreas Karlsson wrote:
>> Nondeterministic collations do address this by allowing canonically
>> equivalent code point sequences to compare as equal. You still need a
>> collation implementation that actually does compare them as equal; ICU
>> does this, glibc does not AFAICT
Peter Eisentraut writes:
> On 07/01/2019 00:16, Tom Lane wrote:
>> BTW, this is a pre-existing problem not the fault of this patch,
>> but while we're fooling with the behavior of python lookup would
>> be a great time to fix it: we should add something like
>> AC_ARG_VAR([PYTHON], [path to Python
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> See if Windows likes this one any better.
Tom> Doubtful, because AFAICT it's the same patch.
Sigh. copied wrong file. Let's try that again.
--
Andrew (irc:RhodiumToad)
diff --git a/configure b/configure
index 06fc3c6835..e3176e24
On Wed, Jan 16, 2019 at 3:30 AM Masahiko Sawada wrote:
> As the above comment says, it's possible that the state of an
> INSERT_IN_PROGRESS tuple could be changed to 'dead' after
> heap_page_prune(). Since such tuple is not truncated at this point we
> record it and set it as UNUSED in lazy_vacuum
On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila wrote:
>
> On Fri, Jan 11, 2019 at 3:54 AM John Naylor
> wrote:
> 1.
> Commit message:
> > Any pages with wasted free space become visible at next relation extension,
> > so we still control table bloat.
>
> I think the free space will be available af
On Mon, Jan 14, 2019 at 1:41 PM Dimitri Fontaine wrote:
> One idea would be that if every temp table in the session belongs to the
> transaction, and their namespace too (we could check through pg_depend
> that the namespace doesn't contain anything else beside the
> transaction's tables), then we
On 1/16/19 9:27 AM, Michael Paquier wrote:> Regarding the grammar, we
tend for the last couple of years to avoid
complicating the main grammar and move on to parenthesized grammars
(see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think that
it would make sense to only support CONCURREN
Looking into a bug report on the -general list about grouping sets,
which turns out to be an issue of collation assignment: if the query has
CASE GROUPING(expr) WHEN 1 ...
then the expression is rejected as not matching the one in the GROUP BY
clause, because CASE already assigned collations to
On Thu, Nov 22, 2018 at 10:16 AM Peter Eisentraut
wrote:
> On 15/11/2018 15:10, Robert Haas wrote:
> > I don't have a strong position on 1 vs. 2 vs. 3, but I do think it
> > would be nicer not to use '\0' as a column value. I'd suggest you use
> > 'n' or '0' or '-' or some other printable charact
On 2018-Dec-21, Greg Stark wrote:
> But I had a second look to see if the output pointed out any actual
> bugs. I found one though it's pretty minor:
>
> lockfuncs.c:234:3: warning: enumeration value
> ‘LOCKTAG_SPECULATIVE_TOKEN’ not handled in switch [-Wswitch-enum]
>switch ((LockTagType) in
On Wed, Jan 16, 2019 at 11:40 AM John Naylor
wrote:
> On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila
wrote:
> > can use a macro for the same? I have changed this in the attached
> > patch, see what you think about it. I have used it at a few other
> > places as well.
>
> The macro adds clarity, so
I wrote:
> (FWIW, I'm running the patch on gaur's host, just to confirm it
> does what you expect. Should have an answer in an hour or so ...)
It does --- it compiles cleanly, and the float4 output matches
float4-misrounded-input.out.
(This is the v1 patch not v2.)
regar
Andrew Gierth writes:
> Looking into a bug report on the -general list about grouping sets,
> which turns out to be an issue of collation assignment: if the query has
> CASE GROUPING(expr) WHEN 1 ...
> then the expression is rejected as not matching the one in the GROUP BY
> clause, because CASE
John Naylor writes:
> It just occured to me that the style FSM_LOCAL_MAP_EXISTS seems more
> common for macros that refer to constants, and FSMLocalMapExists for
> expressions, but I've only seen a small amount of the code base. Do we
> have a style preference here, or is it more a matter of match
On 2019-Jan-16, Michael Paquier wrote:
> Regarding the grammar, we tend for the last couple of years to avoid
> complicating the main grammar and move on to parenthesized grammars
> (see VACUUM, ANALYZE, EXPLAIN, etc). So in the same vein I think that
> it would make sense to only support CONCURR
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> > On reflection, maybe the problem is not that we're giving the file
> > the wrong permissions, but that we're putting it in the wrong place?
> > That is, seems like it should be
James Coleman writes:
> One other question on testing: do you think the "calculated array"
> tests are good enough by themselves (i.e., remove the ones with array
> constants of > 100 values)? I dislike that it's not as obvious what's
> going on, but given that the code shouldn't care about array
Stephen Frost writes:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
>>> On reflection, maybe the problem is not that we're giving the file
>>> the wrong permissions, but that we're putting it in the wrong place?
> I'm not really sure
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> >> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> >>> On reflection, maybe the problem is not that we're giving the file
> >>> the wrong permissions, but tha
On 2019-Jan-11, Amit Langote wrote:
> Looking around a bit more, I started thinking even build_child_join_sjinfo
> doesn't belong in appendinfo.c (just to be clear, it was defined in
> prepunion.c before this commit), so maybe we should move it to joinrels.c
> and instead export adjust_child_relid
On 05/01/2019 15:53, Peter Eisentraut wrote:
> On 21/11/2018 15:46, Christoph Berg wrote:
>> A startup looks like this:
>>
>> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1",
>> port 5431
>> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address
>> "127.0.0.
On 16/01/2019 14:20, Daniel Verite wrote:
> I've found another issue with aggregates over distinct:
> the deduplication seems to ignore the collation.
I have a fix for that. I'll send it with the next update.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 2
> [v5]
Hi Tomas,
Peter suggested upthread to use 'settings' rather than 'gucs' for the
explain option (and output?), and you seemed to agree. Are you going
to include that in a future version? Speaking of the output, v5's
default text doesn't match that of formatted text ('GUCs' / 'GUC').
I couldn't compile v7-0001 and I am testing with the older v6-0001 (of
which I still had an instance).
So the problem below may have been fixed already.
If you add a generated column to a file_fdw foreign table, it works OK
wih VIRTUAL (the default) but with STORED it adds an empty column,
si
>On Thu, Nov 15, 2018 at 2:30 PM Alvaro Herrera
>wrote:
>>
>> On 2018-Nov-15, Laurenz Albe wrote:
>>
> > > This new option would not only mitigate the long shared_buffers
> > > scan, it would also get rid of the replication conflict caused by
> > > the AccessExclusiveLock taken during truncatio
On Wed, Jan 16, 2019 at 11:02:48AM -0500, Robert Haas wrote:
> I think you have some valid points here, but I also think that the
> patch as written doesn't really seem to have any user-visible
> benefits. Sure, ready_to_display is a crock, but getting rid of it
> doesn't immediately help anybody.
On Wed, Jan 16, 2019 at 02:14:41PM +0100, Peter Eisentraut wrote:
> On 15/01/2019 08:13, Michael Paquier wrote:
>> When testing a bulk INSERT into a table which has a stored generated
>> column, memory keeps growing in size linearly, which does not seem
>> normal to me. If inserting more tuples th
On Wed, Jan 16, 2019 at 02:59:31PM -0300, Alvaro Herrera wrote:
> That's my opinion too, but I was outvoted in another subthread -- see
> https://postgr.es/m/20181214144529.wvmjwmy7wxgmgyb3@alvherre.pgsql
> Stephen Frost, Andrew Gierth and Andres Freund all voted to put
> CONCURRENTLY outside the p
On 1/16/19 7:56 AM, David Rowley wrote:> On Tue, 15 Jan 2019 at 08:21,
Tomas Vondra wrote:
>> Turns out you were right - the attribute_referenced piece was quite
>> unnecessary. So I've removed it. I've also extended the regression tests
>> to verify changing type of another column does not
On Thu, 17 Jan 2019 at 14:19, Tomas Vondra wrote:
> > 12. Should we be referencing the source from the docs?
> >
> > See mcv_clauselist_selectivity
> > in src/backend/statistics/mcv.c for details.
> >
> > hmm. I see it's not the first going by: git grep -E "\w+\.c\<"
> > gt
> Hmm, tha
> "Tom" == Tom Lane writes:
>> (FWIW, I'm running the patch on gaur's host, just to confirm it
>> does what you expect. Should have an answer in an hour or so ...)
Tom> It does --- it compiles cleanly, and the float4 output matches
Tom> float4-misrounded-input.out.
Well I'm glad _somet
> "Tom" == Tom Lane writes:
>> I'll be looking into this in detail later, but right now, cam anyone
>> think of any reason why parseCheckAggregates couldn't be moved to
>> after assign_query_collations?
Tom> I never particularly liked assign_query_collations, as a matter of
Tom> overall
On Wed, Jan 16, 2019 at 11:25 PM Tom Lane wrote:
>
> John Naylor writes:
> > It just occured to me that the style FSM_LOCAL_MAP_EXISTS seems more
> > common for macros that refer to constants, and FSMLocalMapExists for
> > expressions, but I've only seen a small amount of the code base. Do we
> >
On Wed, Jan 16, 2019 at 10:10 PM John Naylor
wrote:
>
> On Wed, Jan 16, 2019 at 8:41 AM Amit Kapila wrote:
> >
> > On Fri, Jan 11, 2019 at 3:54 AM John Naylor
> > wrote:
> > 1.
> > Commit message:
> > > Any pages with wasted free space become visible at next relation
> > > extension, so we sti
On Thu, 17 Jan 2019 at 01:56, David Rowley wrote:
> At this stage I'm trying to get to know the patch. I read a lot of
> discussing between you and Dean ironing out how the stats should be
> used to form selectivities. At the time I'd not read the patch yet,
> so most of it went over my head.
>
On 2019/01/04 9:53, David Rowley wrote:
> Without PREPAREd statements, if the planner itself was unable to prune
> the partitions it would already have obtained the lock during
> planning, so AcquireExecutorLocks(), in this case, would bump into the
> local lock hash table entry and forego trying t
Although we've got a few NetBSD and OpenBSD buildfarm critters,
none of them are doing --enable-tap-tests. If they were, we'd
have noticed the pgbench regression tests falling over:
not ok 3 - pgbench option error: bad option stderr /(?^:(unrecognized|illegal)
option)/
# Failed test 'pgbench o
> On Jan 15, 2019, at 2:37 AM, Andrew Gierth
> wrote:
>
> Andres> strtod()'s job ought to computationally be significantly easier
> Andres> than the other way round, no? And if there's buggy strtod()
> Andres> implementations out there, why would they be guaranteed to do
> Andres> the correct t
On Wed, Jan 16, 2019 at 05:56:15PM +0100, Andreas Karlsson wrote:
> On 1/16/19 9:27 AM, Michael Paquier wrote:
>> Does somebody mind if I jump into the ship after so long? I was the
>> original author of the monster after all...
>
> Fine by me. Peter?
Okay, I have begun digging into the patch, a
> "Donald" == Donald Dong writes:
Donald> Hi,
Donald> I'm trying to reproduce the results by calling float4in in my
Donald> test code. But I have some difficulties linking the code:
Donald> testfloat4.c:(.text+0x34): undefined reference to `float4in'
Donald> testfloat4.c:(.text+0x3c):
(2019/01/16 20:30), Etsuro Fujita wrote:
(2019/01/16 15:54), Michael Paquier wrote:
On Wed, Jan 16, 2019 at 02:59:15PM +0900, Etsuro Fujita wrote:
If there are no objections, I'll commit that version of the patch.
I think that you could use PgFdwModifyState for the second argument of
execute_
On Tue, Jan 08, 2019 at 09:09:56AM +0100, Christoph Berg wrote:
> Re: Andres Freund 2019-01-08
> <20190108011837.n4mx7dadvojv2...@alap3.anarazel.de>
>>> Here's another revision that doesn't add an extra CXXOPT variable but
>>> just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
>>>
On Thu, Jan 17, 2019 at 02:44:25PM +0900, Etsuro Fujita wrote:
> Pushed. I left that argument alone. I think we can change it later, if
> necessary :).
Sure, that's fine as well. Thanks for committing the patch.
--
Michael
signature.asc
Description: PGP signature
>> On 2018-Dec-03, Tatsuo Ishii wrote:
>>
>>> To:
>>> ---
>>> -M querymode
>>> --protocol=querymode
>>>
>>> Protocol to use for submitting queries to the server:
>>>
>>> simple: use simple query protocol.
>>>
>>>
On Thu, Jan 17, 2019 at 1:33 AM Robert Haas wrote:
>
> On Wed, Jan 16, 2019 at 3:30 AM Masahiko Sawada wrote:
> > As the above comment says, it's possible that the state of an
> > INSERT_IN_PROGRESS tuple could be changed to 'dead' after
> > heap_page_prune(). Since such tuple is not truncated at
On Thu, 17 Jan 2019 at 03:42, David Rowley wrote:
> 35. The evaluation order of this macro is wrong.
>
> #define ITEM_SIZE(ndims) \
> (ndims * (sizeof(uint16) + sizeof(bool)) + 2 * sizeof(double))
>
> You'd probably want ITEM_SIZE(10) to return 170, but:
>
> select (10 * (2 + 1) + 2 * 8);
> ?colu
On 16/01/2019 22:40, Erik Rijkers wrote:
> I couldn't compile v7-0001 and I am testing with the older v6-0001 (of
> which I still had an instance).
>
> So the problem below may have been fixed already.
>
> If you add a generated column to a file_fdw foreign table, it works OK
> wih VIRTUAL (the
84 matches
Mail list logo
