On 03/26/19 21:39, Ryan Lambert wrote:
> I can't verify technical accuracy for many of the details (nuances between
> XPath 1.0, et. al), but overall my experience with the XML functionality
> lines up with what has been documented here.
By the way, in case it's buried too far back in the email
On Wed, 27 Mar 2019 at 18:39, Amit Langote
wrote:
>
> On 2019/03/27 14:26, David Rowley wrote:
> > Perhaps the way to make this work, at least in the long term is to do
> > in the planner what we did in the executor in d73f4c74dd34.
>
> Maybe you meant 9ddef36278a9?
Probably.
> What would be
Hi,
On 2019-01-29 07:22:16 -0800, Andres Freund wrote:
> On January 29, 2019 6:25:59 AM PST, Tomas Vondra
> wrote:
> >On 1/29/19 8:18 AM, David Rowley wrote:
> >> ...
> >> Here are my performance tests of with and without your change to the
> >> memory contexts (I missed where you posted your
On Wed, Mar 27, 2019 at 1:31 AM Masahiko Sawada
wrote:
> On Tue, Mar 26, 2019 at 10:19 AM Haribabu Kommi
> wrote:
> >
> >
> > + for (i = 0; i < nindexes; i++)
> > + {
> > + LVIndStats *s = &(copied_indstats[i]);
> > +
> > + if (s->updated)
> > + lazy_update_index_statistics(Irel[i],
On 2019/03/27 14:26, David Rowley wrote:
> On Wed, 27 Mar 2019 at 18:13, Amit Langote
> wrote:
>>
>> On 2019/03/27 13:50, Amit Langote wrote:
>>> On 2019/03/27 12:06, Amit Langote wrote:
I wonder if I should rework inherit.c so that its internal interfaces
don't pass around parent
On Wed, 27 Mar 2019 at 18:13, Amit Langote
wrote:
>
> On 2019/03/27 13:50, Amit Langote wrote:
> > On 2019/03/27 12:06, Amit Langote wrote:
> >> I wonder if I should rework inherit.c so that its internal interfaces
> >> don't pass around parent Relation, but make do with the RelOptInfo? I'll
>
On 2019/03/27 13:50, Amit Langote wrote:
> On 2019/03/27 12:06, Amit Langote wrote:
>> I wonder if I should rework inherit.c so that its internal interfaces
>> don't pass around parent Relation, but make do with the RelOptInfo? I'll
>> need to add tupdesc and reltype fields to RelOptInfo to go
On 03/26/19 21:39, Ryan Lambert wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:tested, passed
Thanks for the
On 2019/03/27 12:06, Amit Langote wrote:
> I wonder if I should rework inherit.c so that its internal interfaces
> don't pass around parent Relation, but make do with the RelOptInfo? I'll
> need to add tupdesc and reltype fields to RelOptInfo to go ahead with that
> though.
To give more context
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> while going through the old patch where the GUC_REPORT is implemented, Tom
> has commented the logic of sending the signal to all backends to process
> the hot standby exit with SIGHUP, if we add the logic of updating the GUC
> variable
Thank you for sharing the updated patch!
On Tue, Mar 26, 2019 at 6:26 PM Pavan Deolasee wrote:
>
>
> On Fri, Mar 22, 2019 at 12:19 PM Masahiko Sawada
> wrote:
>>
>> I've looked at the patch and have comments and questions.
>>
>> +/*
>> + * While we are holding the lock on the page,
Ryan Lambert writes:
> I have two recommendations for features.sgml. You state:
>> relies on the libxml library
> Should this be clarified as the libxml2 library? That's what I installed to
> build postgres from source (Ubuntu 16/18). If it is the libxml library and
> the "2" is
On Tue, Mar 26, 2019 at 10:03:35AM -0400, Tom Lane wrote:
> +1 for the general idea, but I find the switch a bit overly verbose.
> Do we really need to force every new EXPR_KIND to visit this spot,
> when so few of them have a need to do anything? I'd be a bit inclined
> to simplify it to
>
>
On Tue, Mar 26, 2019 at 09:14:46AM +, Daniel Gustafsson wrote:
> Nice, I had missed them as I my eyes set on pg_malloc(). I've done another
> pass over
> the codebase and I can't spot any other on top of the additional ones you
> found where
> MemSet() in palloc0 is preferrable over
On Wed, Mar 27, 2019 at 11:40:12AM +0900, Amit Langote wrote:
> I'm thinking of adding this to open items under Older Bugs. Attached the
> patch that I had posted on -bugs, but it's only a rough sketch as
> described above, not a full fix.
Adding it to the section for older bugs sounds fine to
On 2019/03/08 19:22, Amit Langote wrote:
> On 2019/03/07 20:36, Amit Langote wrote:
>> On Thu, Mar 7, 2019 at 11:17 AM Amit Langote
>> wrote:
>>> The problem start when ALTER TABLE users ALTER COLUMN is executed.
>>> create table users(user_id int, name varchar(64), unique (user_id, name))
>>>
On Tue, Mar 26, 2019 at 02:16:00PM +, Daniel Gustafsson wrote:
> The new status of this patch is: Ready for Committer
Thanks Daniel for the review, committed.
--
Michael
signature.asc
Description: PGP signature
On Thu, Mar 21, 2019 at 02:22:40AM +0100, Tomas Vondra wrote:
...
OK, so here is a bit more polished version of the dlist-based patch.
It's almost identical to what I posted before, except that it:
1) undoes the non-working optimization in DropRelationFiles()
2) removes
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> On Wed, Mar 27, 2019 at 2:30 AM Robert Haas wrote:
> >
> > On Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada
> wrote:
> > > > I don't see a patch with the naming updated, here or there, and I'm
> > > > going to be really unhappy if we end up
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Overall I think this patch [1] improves the docs and help
On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila wrote:
> On Mon, Mar 25, 2019 at 6:55 PM Haribabu Kommi
> wrote:
> >
> >
> > Thanks to everyone for their opinions and suggestions to improve.
> >
> > Without parallel workers, there aren't many internal implementation
> > logic code that causes the
On Wed, Mar 27, 2019 at 2:30 AM Robert Haas wrote:
>
> On Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada
> wrote:
> > > I don't see a patch with the naming updated, here or there, and I'm
> > > going to be really unhappy if we end up with inconsistent naming
> > > between two patches that do
On Tue, 26 Mar 2019 22:18:53 +0900 (JST)
Tatsuo Ishii wrote:
> > One of our clients suggested that the installation document[1] lacks
> > description
> > about requriements of installing *-devel packages. For example,
> > postgresqlxx-devel
> > is required for using --with-pgsql, and
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-03-26 21:01:27 -0400, Stephen Frost wrote:
> > I'm also not convinced that these changes to pg_basebackup will be free
> > of issues that may impact users in a negative way, making me concerned
> > that we're going to end up doing
Hi,
On 2019-03-26 21:01:27 -0400, Stephen Frost wrote:
> I'm also not convinced that these changes to pg_basebackup will be free
> of issues that may impact users in a negative way, making me concerned
> that we're going to end up doing more harm than good with such a change
> being back-patched.
Hi Andres,
Sorry for the late reply.
On 2019/03/26 9:44, Andres Freund wrote:
Hi,
For the tableam work I'd like to remove heapam.h from
nodeModifyTable.c. The only remaining impediment to that is a call to
setLastTid(), which is defined in tid.c but declared in heapam.h.
That doesn't seem
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-03-26 20:18:31 -0400, Stephen Frost wrote:
> > > >>I thought Robert's response was generally good, pointing out that
> > > >>we're talking about this being an issue if the corruption happens in a
> > > >>certain set of bytes. That
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Mar 26, 2019 at 08:18:31PM -0400, Stephen Frost wrote:
> >* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >>On Tue, Mar 26, 2019 at 04:49:21PM -0700, Andres Freund wrote:
> >>>On 2019-03-26 19:22:03 -0400, Stephen
On Wed, Mar 27, 2019 at 3:03 AM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> On 3/20/19 8:36 PM, Haribabu Kommi wrote:
> > Hi Hackers,
> >
> > Here I attached a patch that supports building of PostgreSQL with VS
> 2019.
> > VS 2019 is going to release on Apr 2nd 2019, it will be
On Tue, Mar 26, 2019 at 08:18:31PM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
On Tue, Mar 26, 2019 at 04:49:21PM -0700, Andres Freund wrote:
>On 2019-03-26 19:22:03 -0400, Stephen Frost wrote:
>>* Andres Freund (and...@anarazel.de) wrote:
>>> As
Hello hackers,
This email is regarding the Postgres pg_stat_statements extension.
I noticed that enabling pg_stat_statements can effect performance. I thought
that changing the pg_stat_statements.track parameter to 'none' could reduce
this overhead without requiring a restart to remove it from
Hi,
On 2019-03-26 20:18:31 -0400, Stephen Frost wrote:
> > >>I thought Robert's response was generally good, pointing out that
> > >>we're talking about this being an issue if the corruption happens in a
> > >>certain set of bytes. That said, I'm happy to see improvements in
> > >>this area but
From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Here a benchmark doing that using pgbench's script weight feature.
Wow, I didn't know that pgbench has evolved to have such a convenient feature.
Thanks for telling me how to utilize it in testing. PostgreSQL is cool!
Regards
On Tue, Mar 26, 2019 at 5:10 PM Tomas Vondra
wrote:
> Bogus might be a bit too harsh, but yeah - failure to reliably detect
> obviously
> invalid checksums when the LSN just happens to be high due to randomness is
> not
> a good thing. We'll still detect pages corrupted in other places, but
On 2019/03/27 1:06, Tom Lane wrote:
> Amit Langote writes:
>> 0002 is a new patch to get rid of the duplicate RTE and PlanRowMark that's
>> created for partitioned parent table, as it's pointless. I was planning
>> to propose it later, but decided to post it now if we're modifying the
>> nearby
From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> My understanding of what David wrote is that the slowness of bloated hash
> table is hard to notice, because planning itself is pretty slow. With the
> "speeding up planning with partitions" patch, planning becomes quite fast,
> so the
Thanks for having another look.
On Wed, 27 Mar 2019 at 00:22, Julien Rouhaud wrote:
> A few, mostly nitpicking, comments:
>
> + if (rel->part_scheme != NULL && IS_SIMPLE_REL(rel) &&
> + partitions_are_ordered(root, rel))
>
> shouldn't the test be IS_PARTITIONED_REL(rel) instead of
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Tue, Mar 26, 2019 at 04:49:21PM -0700, Andres Freund wrote:
> >On 2019-03-26 19:22:03 -0400, Stephen Frost wrote:
> >>* Andres Freund (and...@anarazel.de) wrote:
> >>> As detailed in
> >>>
Hi,
On 2019-02-22 14:52:08 -0500, Robert Haas wrote:
> On Fri, Feb 22, 2019 at 11:19 AM Amit Khandekar
> wrote:
> > Thanks for the review. Attached v2.
>
> Thanks. I took this, combined it with Andres's
> v12-0040-WIP-Move-xid-horizon-computation-for-page-level-.patch, did
> some polishing of
On Tue, Mar 26, 2019 at 04:49:21PM -0700, Andres Freund wrote:
Hi,
On 2019-03-26 19:22:03 -0400, Stephen Frost wrote:
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> As detailed in
> https://postgr.es/m/20190319200050.ncuxejradurjakdc%40alap3.anarazel.de
> the way the backend's
Hi,
On 2019-03-26 19:22:03 -0400, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > As detailed in
> > https://postgr.es/m/20190319200050.ncuxejradurjakdc%40alap3.anarazel.de
> > the way the backend's basebackup checksum verification works makes its
> > error
On 2019-Mar-26, Alvaro Herrera wrote:
> Thanks for the thorough testing and bug analysis! It was spot-on. I've
> applied your two proposed fixes, as well as added a new test setup that
> covers both these bugs. The attached set is rebased on 7c366ac969ce.
Attached is rebased on 126d63122232.
here is a new version:
- "track_planning" GUC added
to permit to keep previous behavior unchanged
- columns names have been changed / added:
total_plan_time, total_exec_time, total_time
- trailing whitespaces and comments wider than 80 characters
not fixed
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> As detailed in
> https://postgr.es/m/20190319200050.ncuxejradurjakdc%40alap3.anarazel.de
> the way the backend's basebackup checksum verification works makes its
> error detection capabilities very dubious.
I disagree that it's 'very
Hello, my name is Victor Kuvshiev.
Currently I'm third-year student of Petrozavodsk State University, studying
information systems and technologies.
I have relatively good knowledge of HTML, CSS and Python also have some
skills in javascript language.
example of my works: ruletka, console game
Ryan Lambert writes:
> Is the xml-functions-type-docfix-4.patch [1] the one needing review? I'll
> test applying it and review the changes in better detail. Is there a
> section in the docs that shows how to verify if the updated pages render
> properly? I would assume the pages are build when
Amit Langote writes:
> On 2019/03/23 6:07, Tom Lane wrote:
>> I also feel like you used a dartboard while deciding where to insert the
>> call in query_planner(); dropping it into the middle of a sequence of
>> equivalence-class-related operations seems quite random. Maybe we could
>> delay that
Ok, I'll give it a go.
> If you happened to feel moved to look over a documentation patch, that
> would be what this CF entry most needs in the waning days of the
> commitfest.
Is the xml-functions-type-docfix-4.patch [1] the one needing review? I'll
test applying it and review the changes in
Hello Amit
On 2019-Mar-26, Amit Langote wrote:
> + Oid objectClass = getObjectClass(thisobj);
>
> I guess you meant to use ObjectClass, not Oid here.
Absolutely.
> Tested 0002 a bit more and found some problems.
Thanks for the thorough testing and bug
On Tue, Mar 26, 2019 at 12:58 PM Thomas Munro wrote:
> ... I think you could probably reclaim that space by
> using a more compact representation of vacuumFlags, overflowed,
> delayChkpt, nxids (it's funny, the comment says "as tightly as
> possible", which clearly isn't the case).
Woops, I
On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote:
On Sun, 24 Feb 2019 at 00:06, Tomas Vondra wrote:
Hi,
attached is an updated patch, fixing and slightly tweaking the docs.
Barring objections, I'll get this committed later next week.
I was having a look at this patch, and this
Hi
út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-03-20 03:51, Michael Paquier wrote:
> > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote:
> >> postgres=# update foo set name = 'bbbxx' where id = 1; -- error
> >> ERROR: no
út 26. 3. 2019 v 19:52 odesílatel Pavel Stehule
napsal:
> Hi
>
> út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> napsal:
>
>> On 2019-03-20 03:51, Michael Paquier wrote:
>> > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote:
>> >> postgres=#
On Thu, Mar 7, 2019 at 6:26 PM Thomas Munro wrote:
> On Fri, Mar 8, 2019 at 12:35 PM Jerry Jelinek
> wrote:
> > On Thu, Mar 7, 2019 at 3:09 PM Thomas Munro
> wrote:
> >> My understanding is that it's not really the COW-ness that makes it
> >> not necessary, it's the fact that fdatasync()
On Fri, Mar 22, 2019 at 9:07 AM Tom Lane wrote:
> IMO, the main value of checksums is that they allow the Postgres
> project to deflect blame. That's nice for us but I'm not sure
> that it's a benefit for users. I've seen little if any data to
> suggest that checksums actually catch enough
Hi
út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-03-20 03:51, Michael Paquier wrote:
> > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote:
> >> postgres=# update foo set name = 'bbbxx' where id = 1; -- error
> >> ERROR: no
Alvaro Herrera writes:
> On 2019-Mar-26, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
>> I've never cared for the ntstatus.h reference, but how stable is
>> the URL you suggest going to
Hi,
Am Dienstag, den 26.03.2019, 10:30 -0700 schrieb Andres Freund:
> On 2019-03-26 18:22:55 +0100, Michael Banck wrote:
> > Am Dienstag, den 19.03.2019, 13:00 -0700 schrieb Andres Freund:
> > > CREATE TABLE corruptme AS SELECT g.i::text AS data FROM
> > > generate_series(1, 100) g(i);
> > >
On 2019-Mar-26, Tom Lane wrote:
> Alvaro Herrera writes:
> >> 0xC028 is STATUS_BAD_STACK, per
> >> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
> >> Not sure how credible/useful a stack trace is going to be.
>
> > BTW I think we
Nikolay Shaplov writes:
> In caf626b2 type of vacuum_cost_delay have been switched from int to real,
> everywhere, but not in *RelOpts[] arrays.
Ugh.
> For some reason it continued to build and work.
I'm not quite sure why it worked either; apparently, the type of that
array entry doesn't
On 2019-03-26 18:22:55 +0100, Michael Banck wrote:
> Hi,
>
> Am Dienstag, den 19.03.2019, 13:00 -0700 schrieb Andres Freund:
> > CREATE TABLE corruptme AS SELECT g.i::text AS data FROM generate_series(1,
> > 100) g(i);
> > SELECT pg_relation_size('corruptme');
> > postgres[22890][1]=# SELECT
On Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada wrote:
> > I don't see a patch with the naming updated, here or there, and I'm
> > going to be really unhappy if we end up with inconsistent naming
> > between two patches that do such fundamentally similar things. -1
> > from me to committing
Hi,
Am Dienstag, den 19.03.2019, 13:00 -0700 schrieb Andres Freund:
> CREATE TABLE corruptme AS SELECT g.i::text AS data FROM generate_series(1,
> 100) g(i);
> SELECT pg_relation_size('corruptme');
> postgres[22890][1]=# SELECT current_setting('data_directory') || '/' ||
>
Alvaro Herrera writes:
>> 0xC028 is STATUS_BAD_STACK, per
>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55
>> Not sure how credible/useful a stack trace is going to be.
> BTW I think we should update our message to use this URL
On 3/26/19 12:53 PM, Alvaro Herrera wrote:
> On 2019-Mar-26, Alvaro Herrera wrote:
>
>>> 2019-03-26 00:49:02.208 EDT [5c99ae9e.20cc:6] LOG: server process (PID
>>> 8368) was terminated by exception 0xC028
>> 0xC028 is STATUS_BAD_STACK, per
>>
Hi,
As detailed in
https://postgr.es/m/20190319200050.ncuxejradurjakdc%40alap3.anarazel.de
the way the backend's basebackup checksum verification works makes its
error detection capabilities very dubious.
I think we need to fix this before the next set of backbranch releases,
or at the very
On 2019-Mar-26, Alvaro Herrera wrote:
> > 2019-03-26 00:49:02.208 EDT [5c99ae9e.20cc:6] LOG: server process (PID
> > 8368) was terminated by exception 0xC028
>
> 0xC028 is STATUS_BAD_STACK, per
>
Hi,
I have applied and submitted an initial draft of my proposal for GSoC 2019
through the Summer of Code site. The project is titled 'pgAdmin4 Graphing
Query Tool'.
I would like to get some feedback for the same so that I can improve on
making the final proposal better. The link to the draft is
Hi,
On 2019-03-26 19:11:13 +1300, Edmund Horner wrote:
> The changes in heapam.c were required for backward scan support, as
> used by ORDER BY ctid DESC and MAX(ctid); and also for FETCH LAST and
> FETCH PRIOR. I have removed the backward scans functionality from the
> current set of patches,
Hi!
In caf626b2 type of vacuum_cost_delay have been switched from int to real,
everywhere, but not in *RelOpts[] arrays.
For some reason it continued to build and work. But I think it is better to
move vacuum_cost_delay from int to real there too...
Patch attached.
PS. As you can see current
Amit Langote writes:
> 0002 is a new patch to get rid of the duplicate RTE and PlanRowMark that's
> created for partitioned parent table, as it's pointless. I was planning
> to propose it later, but decided to post it now if we're modifying the
> nearby code anyway.
Good idea, but it needs a
On 3/20/19 8:36 PM, Haribabu Kommi wrote:
> Hi Hackers,
>
> Here I attached a patch that supports building of PostgreSQL with VS 2019.
> VS 2019 is going to release on Apr 2nd 2019, it will be good if version 12
> supports compiling. The attached for is for review, it may needs some
> updates
>
Em ter, 26 de mar de 2019 às 09:54, David Rowley
escreveu:
>
> As I mentioned in [1], I've had a few cases recently about auto-vacuum
> not working. On the other thread, it was all about auto-vacuum being
> configured to run too slowly. The other culprit for auto-vacuum not
> working is when
On Tue, Mar 26, 2019 at 10:30 PM Robert Haas wrote:
>
> On Tue, Mar 26, 2019 at 3:57 AM Tsunakawa, Takayuki
> wrote:
> > From: David Steele [mailto:da...@pgmasters.net]
> > > This patch appears to have been stalled for a while.
> > >
> > > Takayuki -- the ball appears to be in your court.
On Tue, Mar 26, 2019 at 01:37:33PM +, Dean Rasheed wrote:
On Tue, 26 Mar 2019 at 11:59, Dean Rasheed wrote:
On Mon, 25 Mar 2019 at 23:36, Tomas Vondra wrote:
>
> Attached is an updated patch...
I just looked through the latest set of changes and I have a couple of
additional review
Re: Tom Lane 2019-03-22 <4368.1553270...@sss.pgh.pa.us>
> Christoph Berg writes:
> > I think, the next step in that direction would be to enable data
> > checksums by default. They make sense in most setups,
>
> Well, that is exactly the point that needs some proof, not just
> an unfounded
On Sat, Mar 23, 2019 at 3:25 AM Robert Haas wrote:
>
> On Fri, Mar 8, 2019 at 12:14 AM Masahiko Sawada wrote:
> > IIUC we've discussed the field-and-value style vacuum option. I
> > suggested that since we have already the disable_page_skipping option
> > the disable_page_skipping option would
On Tue, Mar 26, 2019 at 11:59:56AM +, Dean Rasheed wrote:
On Mon, 25 Mar 2019 at 23:36, Tomas Vondra wrote:
Attached is an updated patch, fixing all the issues pointed out so far.
Unless there are some objections, I plan to commit the 0001 part by the
end of this CF. Part 0002 is a matter
On Tue, Mar 26, 2019 at 5:32 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Got access to that buildfarm animal thanks to Tom Turelinckx. Now
> > running check-world in a loop on the same commit hash with same build
> > options. Error wasn't triggered yet.
>
> I notice that snapper is
Version of the patch correctly working when no compression algorithm are
avaiable.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/configure b/configure
index 8068108..8ebd961 100755
--- a/configure
+++ b/configure
@@ -701,6
On Tue, Mar 26, 2019 at 03:06:52PM +0300, Surafel Temesgen wrote:
On Thu, Feb 28, 2019 at 11:16 PM Tomas Vondra
wrote:
To give you a (admittedly, somewhat contrived and artificial example):
SELECT * FROM t1 WHERE id IN (
SELECT id FROM t2 ORDER BY x FETCH FIRST 10 PERCENT ROWS
On 2019-Mar-26, Peter Eisentraut wrote:
> On 2019-03-26 03:42, Alvaro Herrera wrote:
> > Patch tester didn't like that one bit. Here's v10 with the fixup
> > applied.
>
> Looks good to me.
Thanks!
I ran "make installcheck-parallel" using this psql version on all
supported branches plus 9.2.
On Tue, Mar 26, 2019 at 10:19 AM Haribabu Kommi
wrote:
>
>
> On Fri, Mar 22, 2019 at 4:06 PM Masahiko Sawada wrote:
>>
>>
>> Attached the updated version patch. 0001 patch allows all existing
>> vacuum options an boolean argument. 0002 patch introduces parallel
>> lazy vacuum. 0003 patch adds -P
Alexander Korotkov writes:
> Got access to that buildfarm animal thanks to Tom Turelinckx. Now
> running check-world in a loop on the same commit hash with same build
> options. Error wasn't triggered yet.
I notice that snapper is using force_parallel_mode = regress ...
have you got that
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Reviewing the codepath in question (as well as the commit that
Michael Paquier writes:
> One idea which came from Amit, and it seems to me that it is a good
> idea, would be to have more context-related error messages directly in
> transformColumnRef(), so as we can discard at an early stage column
> references which are part of contexts where there is no
On Tue, 26 Mar 2019 at 11:59, Dean Rasheed wrote:
>
> On Mon, 25 Mar 2019 at 23:36, Tomas Vondra
> wrote:
> >
> > Attached is an updated patch...
>
> I just looked through the latest set of changes and I have a couple of
> additional review comments:
>
I just spotted another issue while
On Thu, Mar 21, 2019 at 9:28 PM Michael Paquier wrote:
> By the way, as the commit fest is coming to its end in a couple of
> days, and that we are still discussing how the thing should be shaped,
> I would recommend to mark the patch as returned with feedback. Any
> objections with that?
+1.
On Tue, Mar 26, 2019 at 3:57 AM Tsunakawa, Takayuki
wrote:
> From: David Steele [mailto:da...@pgmasters.net]
> > This patch appears to have been stalled for a while.
> >
> > Takayuki -- the ball appears to be in your court. Perhaps it would be
> > helpful to summarize what you think are next
Bonjour Michaël,
Here is an attempt at improving the Notes. [...]
So, the ordering of the notes for each paragraph is as follows: 1)
Replication issues when mixing different checksum setups across nodes.
2) Consistency of the operations if killed. 3) Don't start Postgres
while the
On Tue, Mar 26, 2019 at 12:20 AM Thomas Munro wrote:
> I've been trying to decide if that is a problem. Maybe there is a
> performance angle, and I'm also wondering if it might increase the
> risk of missing a write-back error. Of course we'll find a proper
> solution to that problem (perhaps
> One of our clients suggested that the installation document[1] lacks
> description
> about requriements of installing *-devel packages. For example,
> postgresqlxx-devel
> is required for using --with-pgsql, and openssl-devel for --with-openssl, and
> so on,
> but these are not documented.
>
Hi Amit,
On 3/26/19 2:06 AM, Amit Langote wrote:
Wouldn't you get the same numbers on HEAD too? IOW, I'm not sure how the
patch here, which seems mostly about getting DDL in order to support
foreign keys on partitioned tables, would have affected the result of this
benchmark. Can you clarify
Peter Eisentraut writes:
> On 2019-03-25 22:57, Tom Lane wrote:
>> +fprintf(script, "echo %sYou may wish to add --jobs=N for parallel
>> analyzing.%s\n",
>> +ECHO_QUOTE, ECHO_QUOTE);
> But then you get that information after you have already started the script.
Yes, but
As I mentioned in [1], I've had a few cases recently about auto-vacuum
not working. On the other thread, it was all about auto-vacuum being
configured to run too slowly. The other culprit for auto-vacuum not
working is when people periodically use pg_stat_reset().
The problem with
(2019/03/20 20:47), Etsuro Fujita wrote:
Attached is an updated version of the patch set.
One thing I noticed while self-reviewing the patch for UPPERREL_FINAL
is: the previous versions of the patch don't show EPQ plans in EXPLAIN,
as shown in the below example, so we can't check if those
>> One idea that might be useful is to have walsenders refuse to transmit
> >> any logical-replication data if they see wal_level is too low. That
> >> would get users' attention pretty quickly.
>
> > They do:
>
I checked this before creating the patch
>
> Oh, OK, then this seems like it's
On Thu, Feb 28, 2019 at 11:16 PM Tomas Vondra
wrote:
>
> To give you a (admittedly, somewhat contrived and artificial example):
>
> SELECT * FROM t1 WHERE id IN (
> SELECT id FROM t2 ORDER BY x FETCH FIRST 10 PERCENT ROWS ONLY
> );
>
> Maybe this example is bogus and/or does not
On Mon, 25 Mar 2019 at 23:36, Tomas Vondra wrote:
>
> Attached is an updated patch, fixing all the issues pointed out so far.
> Unless there are some objections, I plan to commit the 0001 part by the
> end of this CF. Part 0002 is a matter for PG13, as previously agreed.
>
Yes, I think that's
Hi,
I apologize that I accidentally sent the following email to this list.
Please disregard this.
I am sorry for making a lot of noise.
Regard,
On Tue, 26 Mar 2019 20:38:31 +0900
Yugo Nagata wrote:
> Hi,
>
> One of our clients suggested that the installation document[1] lacks
> description
1 - 100 of 133 matches
Mail list logo
