On Thu, 23 Jan 2020 at 00:00, Tom Lane wrote:
> The problem is that the planner's initial analysis of the query tree
> concludes that the scan of "tab" has to return "x", because it looks
> through the tree for plain Vars, and "x" is what it's going to find.
> This conclusion is in fact true for
Sorry, I didn't notice this email until now.
On Wed, Nov 27, 2019 at 5:17 PM Michael Paquier wrote:
> On Tue, Nov 05, 2019 at 04:04:25PM +1300, Thomas Munro wrote:
> > On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
> > wrote:
> > > Here's a rebased version of this patch (it had a trivial
On Thu, Jan 23, 2020 at 12:56:41PM +0800, Craig Ringer wrote:
> We could definitely improve on that by exposing a view that integrates
> everything that holds down xmin and catalog_xmin. It'd show
>
> * the datfrozenxid and datminmxid for the oldest database
> * if that database is the current
On Wed, Jan 22, 2020 at 02:34:57PM +0900, Michael Paquier wrote:
> Shouldn't the last part of the sentence be "we should mark it so"
> instead of "we should so mark it"? I would rephrase the whole as
> follows:
> "If the all-visible page is all-frozen but not marked as such yet,
> mark it as
On Wed, Jan 22, 2020 at 11:18:12PM +0100, Daniel Gustafsson wrote:
> Once my plate clears up a bit I will return to this one, but feel free to mark
> it rwf for this cf.
Thanks for the update. I have switched the patch status to returned
with feedback.
--
Michael
signature.asc
Description: PGP
On Thu, 23 Jan 2020 at 01:20, Tom Lane wrote:
>
> Bruce Momjian writes:
> > I think the big question is whether we want to make active prepared
> > transactions more visible to administrators, either during server start
> > or idle duration.
>
> There's already the pg_prepared_xacts view ...
I
On Wed, Jan 22, 2020 at 8:48 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > I wonder if we shouldn't be using errtablecol() here instead of (in
> > addition to?) patching the errmsg() to include the table name.
>
> > Discussion: If we really like having the table names in errtable(), then
> >
Arthur Zakirov writes:
> On 2020/01/23 7:11, Tom Lane wrote:
>> Closer examination shows that the "max" argument is pretty bogus as
>> well. It doesn't do anything except confuse the reader, because there
>> are no cases where the value passed is less than the maximum array entry
>> length, so
On Wed, 22 Jan 2020 at 23:22, Tom Lane wrote:
>
> Thomas Kellerer writes:
> > Tom Lane schrieb am 22.01.2020 um 16:05:
> >> Right. It's the XA transaction manager's job not to forget uncommitted
> >> transactions. Reasoning as though no TM exists is not only not very
> >> relevant, but it
On Wed, Jan 22, 2020 at 3:23 PM MBeena Emerson wrote:
>
> > -
> > 14. src/backend/commands/tablecmds.c
> >
> > 5310 else
> > 5311 ereport(ERROR,
> > 5312
On Wed, Jan 22, 2020 at 10:07 PM Alvaro Herrera
wrote:
>
> I looked at this patchset and it seemed natural to apply 0008 next
> (adding work_mem to subscriptions).
>
I am not so sure whether we need this patch as the exact scenario
where it can help is not very clear to me and neither did anyone
On 2020/01/23 7:11, Tom Lane wrote:
Closer examination shows that the "max" argument is pretty bogus as
well. It doesn't do anything except confuse the reader, because there
are no cases where the value passed is less than the maximum array entry
length, so it never acts to change seq_search's
On Fri, Jan 17, 2020 at 1:05 AM Tomas Vondra
wrote:
> On Fri, Nov 29, 2019 at 03:03:01PM +0900, Michael Paquier wrote:
> >On Mon, Aug 19, 2019 at 01:15:19AM +0300, Alexander Korotkov wrote:
> >> The revised patch seems to fix all of above.
> >
> >The latest patch is failing to apply. Please
On Wed, Jan 22, 2020 at 10:55 AM Peter Geoghegan wrote:
> On Tue, Jan 21, 2020 at 11:50 PM Floris Van Nee
> wrote:
> > As far as I know, a page split could happen at any random element in the
> > page. One of the situations we could be left with is:
> > Leaf page 1 = [2,4]
> > Leaf page 2 =
> "Alvaro" == Alvaro Herrera writes:
Alvaro> My own inclination is that Andrew's implementation, being more
Alvaro> general in nature, would be the better one to have in the
Alvaro> codebase; but we don't have a complete patch yet. Can we reach
Alvaro> some compromise such as if Andrew's
On Mon, Jan 20, 2020 at 11:11:20AM -0800, Andres Freund wrote:
> > @@ -966,8 +986,11 @@ lazy_scan_heap(Relation onerel, VacuumParams *params,
> > LVRelStats *vacrelstats,
> > /* Work on all the indexes, then the heap */
> > + /* Don't use the errcontext
On Wed, Jan 22, 2020 at 1:35 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Oh, that's what you mean. Yes, I was somehow tricked by the name of this
> function and didn't notice that it checks only one boundary, so in case
> of backward scan it returns wrong result. I think in the situation
>
Malthe writes:
> Referencing the example given in the documentation for index-only
> scans [0], we consider an index:
> CREATE INDEX tab_f_x ON tab (f(x));
> This index currently will not be used for an index-scan for the
> following query since the planner isn't smart enough to know that "x"
>
Referencing the example given in the documentation for index-only
scans [0], we consider an index:
CREATE INDEX tab_f_x ON tab (f(x));
This index currently will not be used for an index-scan for the
following query since the planner isn't smart enough to know that "x"
is not needed:
SELECT f(x)
On Wed, Jan 22, 2020 at 1:09 PM Floris Van Nee wrote:
> The loose index scan shouldn't return a tuple twice. It should only be able
> to skip 'further', so that shouldn't be a problem. Out of curiosity, why
> can't index scans return the same tuple twice? Is there something in the
> executor
> On 26 Nov 2019, at 06:44, Michael Paquier wrote:
Re this patch being in WoA state for some time [0]:
> The regression tests of contrib/test_decoding are still failing here:
> +ERROR: could not resolve cmin/cmax of catalog tuple
This is the main thing left with this patch, and I've been
I wrote:
> One thing I completely don't understand is why it's sufficient for
> seq_search_localized to do "initcap" semantics. Shouldn't it cover
> the all-upper and all-lower cases as well, as the existing seq_search
> code does? (That is, why is it okay to ignore the "type" argument?)
I took
On Wed, Jan 22, 2020 at 3:28 PM Magnus Hagander wrote:
> > I think the argument about adding catalog flags adding overhead is
> > pretty much bogus. Fixed-width fields in catalogs are pretty cheap.
>
> If that's the general view, then yeah our "cost calculations" were
> off. I guess I may have
Hello
As this is a valuable feature, it would be good to have something happen
here. I wouldn't like to have pg13 ship with no implementation of WITH
TIES at all.
My own inclination is that Andrew's implementation, being more general
in nature, would be the better one to have in the codebase;
On 2020-Jan-20, Heikki Linnakangas wrote:
> That case arises at least with the range_union() function, when one of
> the arguments is an 'empty' range:
>
> CREATE TABLE brintest (n numrange);
> CREATE INDEX brinidx ON brintest USING brin (n);
> INSERT INTO brintest VALUES ('empty');
> INSERT
> On Wed, Jan 22, 2020 at 09:08:59PM +, Floris Van Nee wrote:
> > Note in particular that index scans cannot return the same index tuple
> > twice -
> > - processing a page at a time ensures that that cannot happen.
> >
> > Can a loose index scan return the same tuple (i.e. a tuple with the
> On Wed, Jan 22, 2020 at 05:24:43PM +, Floris Van Nee wrote:
>
> > > Anyone please correct me if I'm wrong, but I think one case where the
> > > current patch relies on some data from the page it has locked before it
> > > in checking this hi/lo key. I think it's possible for the following
> Note in particular that index scans cannot return the same index tuple twice -
> - processing a page at a time ensures that that cannot happen.
>
> Can a loose index scan return the same tuple (i.e. a tuple with the same heap
> TID) to the executor more than once?
>
The loose index scan
Hi,
After review the patches and build all and run regress checks for each
patch, those are the ones that don't break.
Not all leaks detected by Coverity are fixed.
regards,
Ranier Vilela
auth_leak.patch
Description: Binary data
logging_leaks.patch
Description: Binary data
On Wed, Jan 22, 2020 at 12:20 PM Robert Haas wrote:
>
> On Wed, Jan 22, 2020 at 2:50 PM Magnus Hagander wrote:
> > The reasoning that led us to *not* doing that is that it's a one-off
> > operation. That along with the fact that we hope to at some point be
> > able to change the default to
On Wed, Jan 22, 2020 at 2:50 PM Magnus Hagander wrote:
> The reasoning that led us to *not* doing that is that it's a one-off
> operation. That along with the fact that we hope to at some point be
> able to change the default to chekcsums on (and t wouldn't be
> necessary for the transition
On 2020-Jan-22, Robert Haas wrote:
> On Wed, Jan 22, 2020 at 2:26 PM Alvaro Herrera
> wrote:
> > I'm not sure I see the point of keeping json.h split from jsonapi.h. It
> > seems to me that you could move back all the contents from jsonapi.h
> > into json.h, and everything would work just as
On Fri, Jan 17, 2020 at 5:43 PM Peter Geoghegan wrote:
> I tried to come up with a specific example of how this could be
> unsafe, but my explanation was all over the place (this could have had
> something to do with it being Friday evening). Even still, it's up to
> the patch to justify why it's
On Wed, Jan 22, 2020 at 2:26 PM Alvaro Herrera wrote:
> I'm not sure I see the point of keeping json.h split from jsonapi.h. It
> seems to me that you could move back all the contents from jsonapi.h
> into json.h, and everything would work just as well. (Evidently the
> Datum in
On Mon, Jan 20, 2020 at 12:14 PM Robert Haas wrote:
>
> On Sat, Jan 18, 2020 at 6:18 PM Daniel Gustafsson wrote:
> > Thanks again for reviewing (and working on the infrastructure required for
> > this
> > patch to begin with)! Regarding the persisting the progress; that would be
> > a
> >
On 2020-Jan-22, Robert Haas wrote:
> Here is a new version that is, I think, much closer what I would
> consider a final form. 0001 through 0003 are as before, and unless
> somebody says pretty soon that they see a problem with those or want
> more time to review them, I'm going to commit them;
I wrote:
> This just says it doesn't lock up, of course. I've not attempted
> any performance-oriented tests.
I've now done some light performance testing -- just stuff like
pgbench -S -M prepared -c 20 -j 20 -T 60 bench
I cannot see any improvement on either FreeBSD 12 or NetBSD 8.1,
either as
On Wed, Jan 22, 2020 at 10:55 AM Peter Geoghegan wrote:
> This is a good summary. This is the kind of scenario I had in mind
> when I expressed a general concern about "stopping between pages".
> Processing a whole page at a time is a crucial part of how
> _bt_readpage() currently deals with
On Tue, Jan 21, 2020 at 11:50 PM Floris Van Nee
wrote:
> Anyone please correct me if I'm wrong, but I think one case where the current
> patch relies on some data from the page it has locked before it in checking
> this hi/lo key. I think it's possible for the following sequence to happen.
>
On Tue, Jan 21, 2020 at 9:06 AM Jesper Pedersen
wrote:
> If you apply the attached patch on master it will fail the test suite;
> did you mean something else ?
Yeah, this is exactly what I had in mind for the _bt_readpage() assertion.
As I said, it isn't a great sign that this kind of assertion
>> + int num_workers = planstate->worker_instrument->num_workers;
>> + int n;
>> + worker_strs = (StringInfo *) palloc0(num_workers *
>> sizeof(StringInfo));
>> + for (n = 0; n < num_workers; n++) {
>>
>> I think C99 would be better here. Also no parenthesis needed.
>
>
>
Hi Dmitry,
> > On Wed, Jan 22, 2020 at 07:50:30AM +, Floris Van Nee wrote:
> >
> > Anyone please correct me if I'm wrong, but I think one case where the
> > current patch relies on some data from the page it has locked before it in
> > checking this hi/lo key. I think it's possible for the
Bruce Momjian writes:
> I think the big question is whether we want to make active prepared
> transactions more visible to administrators, either during server start
> or idle duration.
There's already the pg_prepared_xacts view ...
regards, tom lane
Matteo Beccati writes:
> On 22/01/2020 17:06, Tom Lane wrote:
>> Matteo Beccati writes:
>>> I had a NetBSD 8.0 VM lying around and I gave the patch a spin on latest
>>> master.
>>> With the kqueue patch, a pgbench -c basically hangs the whole postgres
>>> instance. Not sure if it's a kernel
On Wed, Jan 22, 2020 at 10:22:21AM -0500, Tom Lane wrote:
> Thomas Kellerer writes:
> > Tom Lane schrieb am 22.01.2020 um 16:05:
> >> Right. It's the XA transaction manager's job not to forget uncommitted
> >> transactions. Reasoning as though no TM exists is not only not very
> >> relevant,
Thanks! I'll fix the brace issues. Re: the other items:
> + int num_workers = planstate->worker_instrument->num_workers;
> + int n;
> + worker_strs = (StringInfo *) palloc0(num_workers *
> sizeof(StringInfo));
> + for (n = 0; n < num_workers; n++) {
>
> I think C99 would
Hi,
First, it seems you did not reply to Alvaro's concerns in your new set of
patch. See:
https://www.postgresql.org/message-id/20190917195800.GA16694%40alvherre.pgsql
On Tue, 24 Dec 2019 21:26:14 +0900 (JST)
Kyotaro Horiguchi wrote:
[...]
> > Indeed, "loosing" is a better match for this
I looked at this patchset and it seemed natural to apply 0008 next
(adding work_mem to subscriptions). Attached is Dilip's latest version,
plus my review changes. This will break the patch tester's logic; sorry
about that.
What part of this change is what sets the process's
On 22/01/2020 17:06, Tom Lane wrote:
> Matteo Beccati writes:
>> On 21/01/2020 02:06, Thomas Munro wrote:
>>> [1]
>>> https://www.postgresql.org/message-id/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com
>
>> I had a NetBSD 8.0 VM lying around and I gave the patch a
Matteo Beccati writes:
> On 21/01/2020 02:06, Thomas Munro wrote:
>> [1]
>> https://www.postgresql.org/message-id/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com
> I had a NetBSD 8.0 VM lying around and I gave the patch a spin on latest
> master.
> With the kqueue
> On Wed, Jan 22, 2020 at 07:50:30AM +, Floris Van Nee wrote:
>
> Anyone please correct me if I'm wrong, but I think one case where the current
> patch relies on some data from the page it has locked before it in checking
> this hi/lo key. I think it's possible for the following sequence to
Hello
> In short, the following things:
> - wal_receiver_create_temp_slot should be made PGC_POSTMASTER,
> similarly to primary_slot_name and primary_conninfo.
> - WalReceiverMain() should not load the parameter from the GUC context
> by itself.
> - RequestXLogStreaming(), called by the startup
Hello
> Yeah, you are right. I was not paying much attention but something
> does not stick here. My understanding is that we should have the WAL
> receiver receive the value it needs to use from the startup process
> (aka via RequestXLogStreaming from xlog.c), and that we ought to make
> this
Thomas Kellerer writes:
> Tom Lane schrieb am 22.01.2020 um 16:05:
>> Right. It's the XA transaction manager's job not to forget uncommitted
>> transactions. Reasoning as though no TM exists is not only not very
>> relevant, but it might lead you to put in features that actually
>> make the
Alvaro Herrera writes:
> I wonder if we shouldn't be using errtablecol() here instead of (in
> addition to?) patching the errmsg() to include the table name.
> Discussion: If we really like having the table names in errtable(), then
> we should have psql display it by default, and other tools
Tom Lane schrieb am 22.01.2020 um 16:05:
> Craig Ringer writes:
>> So I don't really see the point of doing anything with 2PC xacts
>> within Pg proper. It's the job of the app that prepares the 2PC xacts,
>> and if that app is unable to resolve them for some reason there's no
>>
Craig Ringer writes:
> So I don't really see the point of doing anything with 2PC xacts
> within Pg proper. It's the job of the app that prepares the 2PC xacts,
> and if that app is unable to resolve them for some reason there's no
> generally-correct action to take without administrator action.
On Wed, Jan 22, 2020 at 02:09:39PM +0900, Michael Paquier wrote:
On Tue, Jan 21, 2020 at 05:20:17PM +0100, Tomas Vondra wrote:
Yeah, you're right returning them with feedback seems more appropriate,
given the long inactivity. Plus, the CF app apparently does not allow
moving WoA patches to the
On 2020-Jan-22, Michael Paquier wrote:
> On Tue, Jan 21, 2020 at 05:20:17PM +0100, Tomas Vondra wrote:
> > Those are the patches that have been set as WoA before this CF, and have
> > not been updated since. It's quite possible the state is stale for some
> > of those patches, although I've
I wonder if we shouldn't be using errtablecol() here instead of (in
addition to?) patching the errmsg() to include the table name.
Discussion: If we really like having the table names in errtable(), then
we should have psql display it by default, and other tools will follow
suit; in that case we
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
> TEXT format was tricky due to its inconsistencies, but I think I have
>
On Wed, 22 Jan 2020 at 16:45, Ants Aasma wrote:
> The intended use case of two phase transactions is ensuring atomic
> durability of transactions across multiple database systems.
Exactly. I was trying to find a good way to say this.
It doesn't make much sense to embed a 2PC resolver in Pg
Hi Mahendra,
Thanks for working on this.
On Wed, 22 Jan 2020 at 13:26, Mahendra Singh Thalor wrote:
>
> On Tue, 21 Jan 2020 at 10:51, Amit Kapila wrote:
> >
> > On Mon, Jan 6, 2020 at 6:31 PM Mahendra Singh Thalor
> > wrote:
> > >
> > > On Sat, 6 Jul 2019 at 09:53, Amit Kapila wrote:
> > >
On Wed, 22 Jan 2020 at 09:02, Hamid Akhtar wrote:
>
> At this stage, I'm not sure of the scale of changes this will require,
> however, I wanted to get an understanding and consensus on whether (a) this
> is something we should work on, and (b) whether an approach to implementing a
> timeout
On Wed, 22 Jan 2020 at 10:17, Justin Pryzby wrote:
>
> On Tue, Jan 21, 2020 at 05:54:59PM -0300, Alvaro Herrera wrote:
> > > On Tue, Jan 21, 2020 at 03:11:35PM +0900, Masahiko Sawada wrote:
> > > > Some of them conflicts with the current HEAD(62c9b52231). Please rebase
> > > > them.
> > >
> > >
> On 22 Jan 2020, at 01:41, David Fetter wrote:
>
> On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote:
>> On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote:
>>> On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
On Tue, Jan 21, 2020 at 10:12:52AM -0500,
66 matches
Mail list logo
