Hi,
On 2018-10-05 10:29:55 -0700, Andres Freund wrote:
> - remove the volatiles from GetSnapshotData(). As we've, for quite a
> while now, made sure both lwlocks and spinlocks are proper barriers
> they're not needed.
Attached is a patch that removes all the volatiles from procarray.c and
var
On Mon, Nov 5, 2018 at 5:10 PM Dilip Kumar wrote:
>
[review for undo record layer (0003-undo-interface-v3)]
I might sound repeating myself, but just to be clear, I was involved
in the design of this patch as well and I have given a few high-level
inputs for this patch. I have used this interface
Pavel Stehule writes:
> The problem is unsaved plan - probably there should be big PG_TRY block.
Yeah, agreed. Done -- thanks for the report!
regards, tom lane
Hi,
On 2018-11-07 12:58:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > ... in the case the attribute isn't already deformed, the
> > following hunk exists:
>
> > /*
> > * If the attribute's column has been dropped, we force a NULL result.
> > * This case should not happen in
On Fri, Nov 09, 2018 at 03:14:00PM +, Adam Berlin wrote:
> Nice cleanup. Also, I like the ability to enable/control more types of
> tests easily from the Makefile. What are the next steps for this
> patch?
Thanks. It seems to me that a complete review is still in order,
particularly regarding
On Fri, Nov 09, 2018 at 04:23:57PM +0100, Dmitry Dolgov wrote:
> This thread is being inactive for quite some time. As far as I understand, the
> agreement was to add it in the PG12 commit cycle, so probably it's a good time
> to do so. Any plans about that?
This thread needed a new patch to answe
On Fri, Nov 09, 2018 at 05:28:07PM +0100, Daniel Verite wrote:
> But again COPY is concerned with importing the data that preexists,
> even if it's weird, whereas a psql output formats are not.
Hm. I checked the contents of the patch in details which provide output
consistent with COPY, but after
Alvaro Herrera writes:
> On 2018-Nov-09, Jürgen Strobel wrote:
>> Regarding your example, what I expected is that *both* inserts would
>> consistently result in a tuple of (1, 42) since p should route the
>> insert to p1 and use p1's defaults. The current inconsistent behavior is
>> the heart of t
On 2018-Nov-09, Jürgen Strobel wrote:
> OK got it. I agree about differing COLLATE clauses making no sense and
> with the ERROR+WARNING solution, but I didn't report that.
Yeah, I happened to notice it on code inspection.
> The NULL violation is obvious too.
Yeah, IMO that was an obvious bugfix
On 2018-11-09 22:11, Alvaro Herrera wrote:
> On 2018-Nov-09, Jürgen Strobel wrote:
>
>> I am slightly confused now, I thought this landmine was already fixed in
>> master and what remains is only whether to backport it or not? Which I
>> guess depends on whether this is classified as a bug or not.
Summary:
Create new guc array_optimization_size_limit and use it to replace
MAX_SAOP_ARRAY_SIZE in predtest.c.
Among other things this allows tuning when `col IN (1,2,3)` style
expressions can be matched against partial indexes.
It also fixes the comment:
"XXX is it worth exposing this as a GUC k
On 2018-Nov-09, Jürgen Strobel wrote:
> I am slightly confused now, I thought this landmine was already fixed in
> master and what remains is only whether to backport it or not? Which I
> guess depends on whether this is classified as a bug or not.
Hmm, I changed (and back-patched) what happens t
On 2018-11-09 18:07, Alvaro Herrera wrote:
> On 2018-Nov-09, Jürgen Strobel wrote:
>
>> Regarding your example, what I expected is that *both* inserts would
>> consistently result in a tuple of (1, 42) since p should route the
>> insert to p1 and use p1's defaults. The current inconsistent behavio
> On 8 Aug 2018, at 21:34, Peter Eisentraut
> wrote:
>
> I found some unused and some redundant code in ri_triggers.c that was
> left around by some previous changes that aimed to optimize away certain
> trigger invocations. See attached patches.
Both of these patches apply cleanly with minima
pá 9. 11. 2018 v 20:07 odesílatel Pavel Stehule
napsal:
>
>
> pá 9. 11. 2018 v 20:05 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> There are some broken. I tried to fix plpgsql_check regression tests and
>> I found new error.
>>
>> Looks it is fresh regression.
>>
>> CREATE OR REPLACE PROCEDU
> Neglected to include the footnotes...
As I promised at PgConf.eu, here's a follow-up email about PostGIS
parallelism and function inlining (an odd combination, it is true).
So, context:
- We want PostGIS to parallelize more. In order to achieve that we need to
mark our functions with more real
pá 9. 11. 2018 v 20:05 odesílatel Pavel Stehule
napsal:
> Hi
>
> There are some broken. I tried to fix plpgsql_check regression tests and I
> found new error.
>
> Looks it is fresh regression.
>
> CREATE OR REPLACE PROCEDURE public.proc(a integer, INOUT b integer, c
> integer)
> LANGUAGE plpgsql
Hi
There are some broken. I tried to fix plpgsql_check regression tests and I
found new error.
Looks it is fresh regression.
CREATE OR REPLACE PROCEDURE public.proc(a integer, INOUT b integer, c
integer)
LANGUAGE plpgsql
AS $procedure$
begin
b := a + c + c;
end;
$procedure$
CREATE OR REPLACE
As I promised at PgConf.eu, here's a follow-up email about PostGIS
parallelism and function inlining (an odd combination, it is true).
So, context:
- We want PostGIS to parallelize more. In order to achieve that we need to
mark our functions with more realistic COSTs. Much much higher COSTs.
- Wh
I wrote:
> So it seems like testing ALTER DEFAULT PRIVILEGES in a script that
> runs in parallel with anything else is a damfool idea. But there
> is also a live bug of failure to correctly record privileges granted
> this way. Without that bug, we'd have had our noses rubbed in the
> parallel ra
Hi Amit,
On 11/9/18 3:55 AM, Amit Langote wrote:
And here are patches structured that way. I've addressed some of the
comments posted by Imai-san upthread. Also, since David's patch to
postpone PlannerInfo.total_pages calculation went into the tree earlier
this week, it's no longer included in
On 08.11.2018 22:05, Alvaro Herrera wrote:
On 2018-Nov-08, Konstantin Knizhnik wrote:
Before doing any other refactoring of projection indexes I want to attach
small bug fix patch which
fixes the original problem (SIGSEGV) and also disables recheck_on_update by
default.
As Laurenz has suggest
David G. Johnston wrote:
> POLA, for me at least, would be for \g [filename] to do exactly what
> you are describing with the \copyto feature.
I admit that if we could improve \g to handle COPY, it would be more
elegant than the current proposal adding two meta-commands.
But the copy-wor
On 2018-Nov-09, Jürgen Strobel wrote:
> Regarding your example, what I expected is that *both* inserts would
> consistently result in a tuple of (1, 42) since p should route the
> insert to p1 and use p1's defaults. The current inconsistent behavior is
> the heart of the bug.
I think that would b
On Fri, Nov 9, 2018 at 9:35 AM Daniel Verite wrote:
> If for instance psql received a notification between the two \o it would
> end up in the file, which it wouldn't with \copyto.
> The same is true for SELECT... \g file as opposed to \o file
Is that something we could change instead of adding
On 2018-11-09 16:59, Alvaro Herrera wrote:
> On 2018-Nov-09, Amit Langote wrote:
>
>> Or is it a *bug* of tuple-routing that it doesn't substitute default
>> values that may be defined for partitions? It kind of looks like one if
>> you see an example like this.
>>
>> create table p (a int, b int
David G. Johnston wrote:
> Do I understand correctly that you are proposing a slightly less
> verbose alternative of:
>
> \o :filename
> COPY TO STDOUT
> \o
Not strictly the same because of this:
\o or \out [ filename ]
“Query results” includes all tables, command responses, and
Michael Paquier wrote:
> Still what's the point except complicating the code? We don't care
> about anything fancy in the backend-side ProcessCopyOptions() when
> checking cstate->delim, and having some consistency looks like a good
> thing to me.
The backend has its reasons that don't a
On Fri, Nov 9, 2018 at 4:19 AM Daniel Verite wrote:
> Examples of use
>
> 1. $ psql -v filename="/path/data-$(date -I).csv"
> COPY (SELECT *
>FROM table
>WHERE ...)
> TO STDOUT (FORMAT csv) \copyto :filename
Do I understand correctly that you are proposing a slightly less
verbose alternat
On 2018-Nov-09, Haribabu Kommi wrote:
> On Thu, Oct 25, 2018 at 8:35 AM Alvaro Herrera
> wrote:
>
> > Recently while testing a patch I found it immensely useful to
> > distinguish which session each WARNING message came from, when bespoke
> > tests were run under isolationtester. Current code d
On 09.11.2018 2:27, Tom Lane wrote:
I wrote:
The bigger picture here, and the reason for my skepticism about having
any intelligence in the enabling logic, is that there is no scenario
in which this code can be smarter than the user about what to do.
We have no insight today, and are unlikely
On 2018-Nov-09, Amit Langote wrote:
> Or is it a *bug* of tuple-routing that it doesn't substitute default
> values that may be defined for partitions? It kind of looks like one if
> you see an example like this.
>
> create table p (a int, b int) partition by list (a);
> create table p1 partitio
As a newcomer to this patch, when I read this example:
COPY table_name WHEN (some_condition)
.. I expect COPY to only be run when the condition is true, and I do not expect
the WHEN clause to filter rows. I'm curious what you think about:
COPY table_name WHERE (some_condition)
Users should alr
> On Fri, 15 Jun 2018 at 17:09, Nathan Bossart wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
> -
Nice cleanup. Also, I like the ability to enable/control more types of tests
easily from the Makefile. What are the next steps for this patch?
On Thu, Nov 8, 2018 at 3:59 PM David Rowley
wrote:
> On 9 November 2018 at 05:34, Robert Haas wrote:
> > I suspect the only good way of fixing this problem is using a single
> > snapshot to perform both the scan of pg_inherits and the subsequent
> > pg_class lookups. That way, you know that you
Hi!
In order to support create subscription from non-superuser, we need to make it
possible to choose tables on the subscriber side:
1. add `FOR TABLE` clause in `CREATE SUBSCRIPTION`:
```
CREATE SUBSCRIPTION subscription_name
CONNECTION 'conninfo'
PUBLIC
On 11/9/18 9:33 AM, Kyotaro HORIGUCHI wrote:
Hello. This is rebased version.
At Thu, 8 Nov 2018 16:06:49 +0100, Tomas Vondra wrote
in
However a quite a few extensions in contrib seem are broken now. It
seems fixing it is as simple as including the new bestatus.h next to
pgstat.h.
The ad
> "Michael" == Michael Paquier writes:
> On Thu, Nov 08, 2018 at 04:00:26PM +0900, Michael Paquier wrote:
>> Yes, I don't disagree with you and I thought about it. Fetching the
>> value from the control file is easy, doing the comparison between
>> two LSNs is also simple by doing it dire
On Fri, Nov 09, 2018 at 11:40:44AM +0100, Daniel Verite wrote:
> The above is meant to accept a multibyte character as the separator,
> in which case strlen(value) would be greater than 1.
Still what's the point except complicating the code? We don't care
about anything fancy in the backend-side
Haribabu Kommi wrote:
> Added comments along the lines that you mentioned. And also try
> to update some more comments.
Looks ok to me, I'll mark it as "ready for committer".
Yours,
Laurenz Albe
On Fri, Sep 28, 2018 at 5:31 PM Haribabu Kommi
wrote:
>
> On Thu, Jul 19, 2018 at 10:59 PM Haribabu Kommi
> wrote:
>
>>
>> On Wed, Jul 18, 2018 at 10:53 PM Robert Haas
>> wrote:
>>
>>> On Wed, Jul 4, 2018 at 9:14 AM, Laurenz Albe
>>> wrote:
>>> > What about keeping the first successful conne
Hi,
Currently \copy cannot span multiple lines (like any meta-command)
and cannot use psql variables whereas \g can do both.
The POC patch attached implements two meta-commands \copyfrom
and \copyto that are to COPY what \g is to any other query:
- they take the COPY query already var-expanded
Michael Paquier wrote:
> +/* check for value being non-empty and with an MB length of 1 */
> +if (*value == '\0' || value[PQmblen(value, pset.encoding)] != '\0')
>
> It seems to me that this can just be replaced with that:
> if (strlen(value) != 1)
The above is meant to accept a
Thanks David.
> I'm highly against doing 'c' since both [1] and [3] are very useful patches
> which scale partitioning to work well with very large numbers of partitions.
Agreed.
>'a' is not that ideal a solution either as it means that anyone doing CREATE
>INDEX or TRUNCATE on a partition wou
(2018/11/09 14:39), Kyotaro HORIGUCHI wrote:
At Thu, 08 Nov 2018 21:52:31 +0900, Etsuro Fujita wrote
in<5be4318f.4040...@lab.ntt.co.jp>
(2018/11/08 10:50), Thomas Munro wrote:
I take back what I said earlier about false positives from other
pipes. I think it's only traditional Unix programs
Imai-san,
On 2018/11/07 10:00, Imai, Yoshikazu wrote:
> About inheritance_make_rel_from_joinlist(), I considered how it processes
> joins for sub-partitioned-table.
>
> sub-partitioned-table image:
> part
> sub1
> leaf1
> leaf2
>
> inheritance_make_rel_from_joinlist() translates join_l
Imai-san,
Thank you for reviewing.
On 2018/11/05 17:28, Imai, Yoshikazu wrote:
> Since it takes me a lot of time to see all of the patches, I will post
> comments
> little by little from easy parts like typo check.
I've fixed the typos you pointed out.
> 4.
> 0004:
> -static void expand_inheri
48 matches
Mail list logo
