Reviewing pg_dump-rows-per-insert-option-v14.
Mostly going back over things that Fabien mentioned:
On Sat, 2 Feb 2019 at 21:26, Fabien COELHO wrote:
> There is a test, that is good! Charater "." should be backslashed in the
> regexpr. I'd consider also introducing limit cases: empty table, empty
nightjar just did this:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2019-02-11%2004%3A33%3A07
The critical bit seems to be that the publisher side of the
010_truncate.pl test failed like so:
2019-02-10 23:55:58.765 EST [40771] sub3 LOG: statement: BEGIN READ ONLY
ISOLAT
On Sat, Feb 02, 2019 at 03:38:22AM -0500, Noah Misch wrote:
> The main consequence is the false alarm. A prudent DBA will want to react to
> true wraparound, but no such wraparound has occurred. Also, we temporarily
> waste disk space in pg_xact. This feels like a recipe for future bugs. The
>
On Mon, 11 Feb 2019 at 01:22, Julien Rouhaud wrote:
> The patch is quite straightforward, so I don't have general comments
> on it. However, I think that the idxlockmode initialization is
> problematic: you're using the statement's commandType so this doesn't
> work with CTE. For instance, with
Thomas Munro writes:
> Hello,
> step lsto: SET lock_timeout = 5000; SET statement_timeout = 6000;
> step update: DELETE FROM accounts WHERE accountid = 'checking';
> step update: <... completed>
> -ERROR: canceling statement due to lock timeout
> +ERROR: canceling statement due to statement
Hi,
On Mon, Feb 11, 2019 at 11:11:32AM +1100, Thomas Munro wrote:
> I haven't ever managed to reproduce that one yet. It's great you have
> a reliable repro... Let's discuss it on the #15585 thread.
I realized that I gave bad information (at least to Thomas). On the server
where I've been repr
Hello,
step lsto: SET lock_timeout = 5000; SET statement_timeout = 6000;
step update: DELETE FROM accounts WHERE accountid = 'checking';
step update: <... completed>
-ERROR: canceling statement due to lock timeout
+ERROR: canceling statement due to statement timeout
No matter how slow the m
Peter Geoghegan writes:
> On Sun, Feb 10, 2019 at 5:18 PM Tom Lane wrote:
>> Apparently, whoever went through indxpath.c to substitute nkeycolumns
>> for ncolumns was not paying attention. As far as I can tell, the
>> *only* place in there where it's correct to reference ncolumns is in
>> check_
On 2019-Feb-10, Tom Lane wrote:
> Alvaro Herrera writes:
> > If we disregard the scenario were people downgrade across minor
> > versions, it's likely possible to produce SQL queries to transform from
> > the old arrangement to the new one, and include those in release notes
> > or a wiki page;
On Sun, Feb 10, 2019 at 5:18 PM Tom Lane wrote:
> Apparently, whoever went through indxpath.c to substitute nkeycolumns
> for ncolumns was not paying attention. As far as I can tell, the
> *only* place in there where it's correct to reference ncolumns is in
> check_index_only, where we determine
Thomas Munro writes:
> On Mon, Feb 11, 2019 at 10:33 AM Tom Lane wrote:
>> I observe from
>> https://coverage.postgresql.org/src/backend/utils/mmgr/freepage.c.gcov.html
>> that the edge cases in this function aren't too well exercised by
>> our regression tests, meaning that the buildfarm might n
Apparently, whoever went through indxpath.c to substitute nkeycolumns
for ncolumns was not paying attention. As far as I can tell, the
*only* place in there where it's correct to reference ncolumns is in
check_index_only, where we determine which columns can be extracted from
an index-only scan.
On Mon, Feb 11, 2019 at 10:33 AM Tom Lane wrote:
> I observe from
>
> https://coverage.postgresql.org/src/backend/utils/mmgr/freepage.c.gcov.html
>
> that the edge cases in this function aren't too well exercised by
> our regression tests, meaning that the buildfarm might not prove
> much either w
On Mon, Feb 11, 2019 at 11:02 AM Justin Pryzby wrote:
> On Mon, Feb 11, 2019 at 09:45:07AM +1100, Thomas Munro wrote:
> > Ouch. Yeah, that'd do it and matches the evidence. With this change,
> > I couldn't reproduce the problem after 90 minutes with a test case
> > that otherwise hits it within
On Mon, Feb 11, 2019 at 09:45:07AM +1100, Thomas Munro wrote:
> Ouch. Yeah, that'd do it and matches the evidence. With this change,
> I couldn't reproduce the problem after 90 minutes with a test case
> that otherwise hits it within a couple of minutes.
...
> Note that this patch addresses the e
I will preface this with that I am not a security guy and that also do
not know how the Zstd vompression works, so take any of what I say with
a grain of salt.
On 2/8/19 8:14 AM, Andres Freund wrote:> I think compression is pretty
useful, and I'm not convinced that the
threat model underlying
Thomas Munro writes:
> This brings us to a difficult choice: we're about to cut a new
> release, and this could in theory be included. Even though the fix is
> quite convincing, it doesn't seem wise to change such complicated code
> at the last minute, and I know from an off-list chat that that i
On Sun, Feb 10, 2019 at 5:41 PM Robert Haas wrote:
> On Sun, Feb 10, 2019 at 2:37 AM Thomas Munro
> wrote:
> > But at first glance it shouldn't be allocating pages, because it just
> > does consolidation to try to convert to singleton format, and then it
> > does recycle list cleanup using soft=t
Daniel Gustafsson writes:
>> On 10 Feb 2019, at 04:50, Tom Lane wrote:
>> Does anyone else feel that this is interesting/useful data?
> Absolutely, +1 on this. In Greenplum we print the runtime of the script and
> the runtime of the diff, both of which have provided useful feedback on where
> t
> On 10 Feb 2019, at 04:50, Tom Lane wrote:
> Does anyone else feel that this is interesting/useful data?
Absolutely, +1 on this. In Greenplum we print the runtime of the script and
the runtime of the diff, both of which have provided useful feedback on where
to best spend optimization efforts
Alvaro Herrera writes:
> On 2019-Feb-10, Peter Geoghegan wrote:
>> On Sun, Feb 10, 2019 at 8:13 AM Tom Lane wrote:
>>> Just to be be clear, my inclination is to do nothing about this in v11.
>>> It's not apparent to me that any fix is possible given the v11 dependency
>>> data, at least not witho
On 2019-Feb-10, Peter Geoghegan wrote:
> On Sun, Feb 10, 2019 at 8:13 AM Tom Lane wrote:
> > Just to be be clear, my inclination is to do nothing about this in v11.
> > It's not apparent to me that any fix is possible given the v11 dependency
> > data, at least not without downsides that'd likel
Alvaro Herrera writes:
> On 2019-Feb-10, Tom Lane wrote:
>> Primary and secondary partition dependencies behave identically
>> except that the primary dependency is preferred for use in error
>> messages; hence, a partition-dependent object should have one
>> primary partition dependency and one o
On 2019-Feb-10, Tom Lane wrote:
>Primary and secondary partition dependencies behave identically
>except that the primary dependency is preferred for use in error
>messages; hence, a partition-dependent object should have one
>primary partition dependency and one or
On Mon, Feb 11, 2019 at 7:07 AM raam narayana wrote:
> After the latest commit in master branch, I was trying to test the python
> script. Ironically I still see that the output from the script is completely
> different from the unaccent.rules file content. Am I missing anything.My
> testing in
Hi,
After the latest commit in master branch, I was trying to test the python
script. Ironically I still see that the output from the script is completely
different from the unaccent.rules file content. Am I missing anything.My
testing includes the following
Downloaded the following files
htt
On Sun, Feb 10, 2019 at 11:34 AM Tom Lane wrote:
> After looking closer, I find that it's valid SGML to collapse the two
> items into one entry
I'll have to remember that detail -- seems like it'll come in handy again.
>
> DEPENDENCY_PARTITION_PRI
> (P)
> DEPENDENCY_PARTITION_SEC
Peter Geoghegan writes:
> I think that the wording for this example needs to be tweaked.
> Other than that, looks good to me.
After looking closer, I find that it's valid SGML to collapse the two
items into one entry, so how about:
DEPENDENCY_PARTITION_PRI
(P)
DEPENDENCY_PARTITIO
On Fri, Feb 8, 2019 at 2:12 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 08/02/2019 12:27, Magnus Hagander wrote:
> > I'd be more than happy for somebody with morge knowledge of such matters
> > than me to think up a better color scheme. The only reason it has those
> > colo
On Sun, Feb 10, 2019 at 10:05 AM Tom Lane wrote:
> Peter Geoghegan writes:
> > On Fri, Feb 8, 2019 at 6:00 PM Tom Lane wrote:
> The v10 release notes just say
>
> Reduce page locking during vacuuming of GIN indexes
> (Andrey Borodin)
>
> so it doesn't seem like there's any differ
On Sun, Feb 10, 2019 at 8:50 AM Tom Lane wrote:
> >>> [ invent separate primary and secondary partition dependencies? ]
> Here's a version of the patch that does it that way.
Now that I see separate DEPENDENCY_PARTITION_PRI and
DEPENDENCY_PARTITION_SEC dependency types, I agree that it's clearer
Peter Geoghegan writes:
> On Fri, Feb 8, 2019 at 6:00 PM Tom Lane wrote:
>> Yeah, I saw that in the commit message, but didn't really think that
>> the release note entry needed to explain it that way. Could be
>> argued differently though.
> I'm pretty confident that somebody is going to miss
On Sun, Feb 10, 2019 at 8:13 AM Tom Lane wrote:
> How about this comment text?
>
> /*
> * The current target object should have been added to
> * targetObjects while processing the owning object; but it
> * probably got only the fl
I updated the patch. And also I added some explanations and simple
examples in the modular_multiply function.
Fabian-san,
To make easily understanding, I think it is a good idea to add a brief
explanation of outline the pseudorandom_perm function and bijective
functions/transformations. What
Note: I sent an email last night with updated patches, which was not received
because of a spamhaus reputation issue for my email provider.
In working that out with my provider, at the moment I cannot send email at all,
so I am using this comment to explain why the status went back to "needs
re
On Sun, Feb 10, 2019 at 07:11:22PM +0300, Sergei Kornilov wrote:
> > I ran overnight with this patch, but all parallel processes ended up stuck
> > in
> > the style of bug#15585. So that's either not the root cause, or there's a
> > 2nd
> > issue.
>
> Maybe i missed something in this discussion,
I wrote:
> Peter Geoghegan writes:
>>> [ invent separate primary and secondary partition dependencies? ]
>> I lean towards changing these on HEAD, ...
> Me too.
Here's a version of the patch that does it that way.
regards, tom lane
diff --git a/doc/src/sgml/catalogs.sg
Peter Geoghegan writes:
> On Fri, Feb 8, 2019 at 8:15 AM Tom Lane wrote:
>> * The other such issue is a pre-existing bug, which maybe we ought to
>> back-patch, though I can't recall seeing any field reports that seem
>> to match it: after recursing to an internal/extension dependency,
>> we need
Hi
> I ran overnight with this patch, but all parallel processes ended up stuck in
> the style of bug#15585. So that's either not the root cause, or there's a 2nd
> issue.
Maybe i missed something in this discussion, but you can reproduce bug#15585?
How? With this testcase:
https://www.postgres
On Sun, Feb 10, 2019 at 12:10:52PM +0530, Robert Haas wrote:
> I think I see what's happening. At the moment the problem occurs,
> there is no btree - there is only a singleton range. So
> FreePageManagerInternal() takes the fpm->btree_depth == 0 branch and
> then ends up in the section with the
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> Uh-huh. And what happens after DETACH PARTITION ... are you going to run
> >> around and recreate these triggers?
>
> > Yep, that's there too.
>
> OK, then I guess it's fine.
Thanks for verifying
Hi,
On Tue, Feb 5, 2019 at 5:16 AM David Rowley
wrote:
>
> I've changed a couple of things:
>
> 1. Changed nodeBitmapIndexscan.c now properly uses the RangeTblEntry's
> idxlockmode field.
> 2. Renamed a few variables in finalize_lockmodes().
>
> I'm keen to get some feedback if we should go about
Hi!
> 29 янв. 2019 г., в 14:51, Evgeniy Efimkin написал(а):
>
>
Thanks for the next version.
1. In tests the code for "sub reset_pg_hba" is taken from authentication tests
(which is fine), but comments are omitted. Let's take them too?
2. 011_rep_changes_nonsuperuser.pl seems a lot like 001_
43 matches
Mail list logo
