On 2019-01-13 19:05:03 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-13 23:54:58 -0300, Alvaro Herrera wrote:
> > On 2019-Jan-13, Andres Freund wrote:
> >
> > > Alvaro, you'd introduced the split of HeapScanDesc and HeapScanDescData
> > > being in different files (in a3540b0f657c6352) - what
Hi Robert,
Thanks for the comments.
On Fri, Jan 11, 2019 at 2:45 AM Robert Haas wrote:
>
> I feel like there has been some other thread where this was discussed,
> but I can't find it right now. I think that the "query construction"
> logic in transformMergeStmt is fundamentally the wrong way
> "Jack" == Jack LIU writes:
Jack> (I tried to use SPI_connect_ext(SPI_OPT_NONATOMIC) to establish a
Jack> nonatomic connection but it doesn't help.)
You need to be specific here about how it didn't help, because this is
exactly what you're supposed to do, and it should at least change
Hi All,
I sent an email with the same problem in pgsql-general mailing but no one
has responded, so I try to reach out by asking this question in the hacker
list.
In PG-11, procedures were introduced. In the pg_partman PostgreSQL
extension, a procedure named run_maintenance_proc was developed to
On Mon, 3 Dec 2018 at 19:38, Dave Cramer wrote:
> Dmitry,
>
> Please see attached rebased patches
>
I'm fine with patch 0001, though I find this comment a bit hard to follow:
+ * The send_data callback must enqueue complete CopyData messages to libpq
+ * using pq_putmessage_noblock or similar,
On 2019-01-13 19:05:03 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-13 23:54:58 -0300, Alvaro Herrera wrote:
> > On 2019-Jan-13, Andres Freund wrote:
> >
> > > Alvaro, you'd introduced the split of HeapScanDesc and HeapScanDescData
> > > being in different files (in a3540b0f657c6352) - what
On Sunday, January 13, 2019, Donald Dong wrote:
>
> Also I wonder why do we need to make this change?
> -intextra_float_digits = 0; /* Added to DBL_DIG or
> FLT_DIG */
> +intextra_float_digits = 1; /* Added to DBL_DIG or
> FLT_DIG */
>
>From the original
Hi,
On 2019-01-13 23:54:58 -0300, Alvaro Herrera wrote:
> On 2019-Jan-13, Andres Freund wrote:
>
> > Alvaro, you'd introduced the split of HeapScanDesc and HeapScanDescData
> > being in different files (in a3540b0f657c6352) - what do you think about
> > this change? I didn't revert that split,
On 2019-Jan-13, Andres Freund wrote:
> Alvaro, you'd introduced the split of HeapScanDesc and HeapScanDescData
> being in different files (in a3540b0f657c6352) - what do you think about
> this change? I didn't revert that split, but I think we ought to
> consider just relying on a forward
There is a bug that remains, in the
else if (xpathobj->type == XPATH_STRING)
case.
As it is now, it simply passes the string value of the result
into the output column's type-input function, regardless of the
output column type.
If the output column type is xml, this will attempt to parse the
> On Jan 11, 2019, at 10:40 AM, Andres Freund wrote:
>
> And of course it'd change the dump's text contents between ryu and
> non-ryu backends even with extra_float_digits = 3, but the resulting
> floats ought to be the same. It's just that ryu is better at figuring
> out what the minimal text
Thomas Munro writes:
> On Thu, Aug 9, 2018 at 12:59 PM Asim R P wrote:
>> On Tue, Aug 7, 2018 at 7:00 PM, Peter Geoghegan wrote:
>>> I wonder if it would be a better idea to enable Valgrind's memcheck to
>>> mark buffers as read-only or read-write.
>> Basic question: how do you mark buffers as
Hi,
While working on pluggable storage (in particular, while cleaning it up
over the last few days), I grew concerned with widely heapam.h is
included in other headers. E.g. the executor (via execnodes.h,
executor.h relying on heapam.h) shouldn't depend on heapam.h details -
particularly after
s.cherkas...@postgrespro.ru writes:
> This patch adds verification of the connection with the client during
> the execution of the SQL query. The feature enables using the GUC
> variable ‘client_connection_check_interval’. The default check interval
> is 1 second. If you set the value of
A reminder that the CFP for PGCon 2019 closes on 19 January.
That's a Saturday, but in reality, we don't start closing access off
until Monday, so you have the whole weekend to get your submission in.
PGCon 2019 will be on 30-31 May 2019 at University of Ottawa.
* 28-29 May (Tue-Wed) tutorials
*
On Sun, 14 Oct 2018, Matheus de Oliveira wrote:
Updated the last patch so it can apply cleanly on HEAD.
Hi Matheus.
I applied your patch on top of bb874e30fbf9e85bdb117bad34865a5fae29dbf6.
It compiled, worked as expected, but some tests broke executing make
check:
test create_table
Elvis Pranskevichus writes:
> Currently, the following query
> SELECT q.b = row(2)
> FROM unnest(ARRAY[row(1, row(2))]) AS q(a int, b record);
> would fail with
> ERROR: column "b" has pseudo-type record
> This is due to CheckAttributeNamesTypes() being used on a function
>
Michael Paquier writes:
> Being able to relax a bit the case is better than nothing, so that's
> nice to see incremental improvements. Thanks Dimitri.
I'm afraid that this patch is likely to be, if not completely broken,
at least very much less useful than one could wish by the time we get
done
James Coleman writes:
> [ saop_is_not_null-v3.patch ]
There's still a logical problem here, which is that in order to
prove that the ScalarArrayOpExpr yields NULL when its LHS does,
you also have to prove that the RHS is not an empty array.
Otherwise you're up against the fact that the OR of
Richard Guo writes:
> On Tue, Jan 8, 2019 at 11:29 PM Tom Lane wrote:
>> The bigger picture here, of course, is that check_outerjoin_delay's
>> API is not at all well matched to what check_equivalence_delay needs:
>> it has to make the extra bms_copy shown above, and it has no use
>> for either
On Sat, Jan 12, 2019 at 8:52 PM David Rowley
wrote:
>
> Basically, the planner assumes that the WHERE a IS NOT NULL index
> implies WHERE b IN(1,...,101), which is definitely not the case.
>
> Probably your new code needs to be expanded to become:
>
> if (IsA(clause, ScalarArrayOpExpr))
> {
>
Nikolay Shaplov writes:
> [ check-for-ctags-in-make_ctags_v5.diff ]
Pushed with minor editorialization on the wording of the error messages.
regards, tom lane
I'm really disappointed by the direction this thread is going in.
The latest patches add an enormous amount of mechanism, and user-visible
complexity, to do something that we learned was a bad idea decades ago.
Putting a limit on the size of the syscaches doesn't accomplish anything
except to add
On 1/13/19 9:24 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 1/12/19 2:03 PM, Tom Lane wrote:
>>> I wonder if it's practical to scrape DLSUFFIX out of src/Makefile.port
>>> instead of listing all the possibilities here.
>> I'd rather get make to tell us directly, something like:
>>
ne 13. 1. 2019 v 10:43 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 11/01/2019 16:22, Pavel Stehule wrote:
> > The documentation contains paragraph
> >
> > + The generation expression can only use immutable functions and
> cannot
> > + use subqueries or
Andrew Dunstan writes:
> On 1/12/19 2:03 PM, Tom Lane wrote:
>> I wonder if it's practical to scrape DLSUFFIX out of src/Makefile.port
>> instead of listing all the possibilities here.
> I'd rather get make to tell us directly, something like:
> .PHONY: show_dl_suffix
> show_dl_suffix:
>
On 1/12/19 2:03 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 1/11/19 6:33 PM, Tom Lane wrote:
>>> While I think I've fixed this bug, I'm still quite confused about why
>>> only some buildfarm animals showed the problem.
>> ... Is there something weird about naming of library files on
On Sun, Jan 13, 2019 at 10:02 PM Michael Paquier wrote:
> On Sun, Jan 13, 2019 at 10:35:55AM +1300, 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
> 13 янв. 2019 г., в 14:02, Michael Paquier написал(а):
>
>> 3. We probably want SLRUs to use the main buffer pool, instead of
>> their own mini-pools, so they can benefit from the above.
>
> Wasn't there a thread about that on -hackers actually? I cannot see
> any reference to it.
I think
On 11/01/2019 22:05, Tom Lane wrote:
>> 2. If there's no pandoc, this coding silently produces a zero-size
>> INSTALL file. I do not find that acceptable.
>
> Seems like it might be sufficient for the rule to be
>
> $(PANDOC) $< -t plain > $@.tmp
> $(ICONV) -f utf8 -t
On 11/01/2019 16:22, Pavel Stehule wrote:
> The documentation contains paragraph
>
> + The generation expression can only use immutable functions and cannot
> + use subqueries or reference anything other than the current row
> in any
> + way.
>
> It is necessary for stored
On 03/01/2019 18:52, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 29/11/2018 16:34, Tom Lane wrote:
>>> After sleeping on it for awhile, I am liking the idea of probing
>>> python, python3, python2 (while keeping the $PYTHON override of
>>> course).
>
>> I think this was the option with the
On 12/01/2019 00:53, Michael Paquier wrote:
> On Fri, Jan 11, 2019 at 11:17:48AM +0100, Peter Eisentraut wrote:
>> Attached revised 0002 with those changes.
>
> This one looks fine.
committed
>> In that test, if I change the 'current' to 'latest', the test doesn't
>> fail, so it's probably not
On Sun, Jan 13, 2019 at 10:35:55AM +1300, 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
34 matches
Mail list logo
