On Wed, Sep 11, 2019 at 10:52:01PM +0200, Fabien COELHO wrote:
AFAICR this is because the coverage was not the same:-) Some backslash
commands just skip silently to the end of the line, so that intermediate
\commands on the same line are not recognized/processed the same, so I moved
everything on
Hello,
While thinking about looping hash joins (an alternative strategy for
limiting hash join memory usage currently being investigated by
Melanie Plageman in a nearby thread[1]), the topic of parallel query
deadlock hazards came back to haunt me. I wanted to illustrate the
problems I'm aware of
On Wed, Sep 11, 2019 at 11:22:45PM +0800, Masahiko Sawada wrote:
> Hmm it will be more consistent with other functions but I think we
> would need to increase the pageinspect version to 1.8 and need the new
> sql file to rename the function name. And it will be for PG12, not
> PG13. If we have to d
On Wed, Sep 11, 2019 at 8:53 PM Masahiko Sawada wrote:
>
> I've attached the updated patch that incorporated all comments. I kept
> the function as superuser-restricted.
>
Thanks for the updated patch.
Few more comments:
*
+ if (!superuser())
+ ereport(ERROR,
+ (errcode
(ERRCODE_INSUFFICIENT_PR
On Wed, Sep 11, 2019 at 6:22 PM Robert Haas wrote:
>
> There are only four subsystems which require a callback at the
> beginning of each subtransaction: the relevant functions are
> AtSubStart_Memory, AtSubStart_ResourceOwner, AtSubStart_Notify, and
> AfterTriggerBeginSubXact. The AtSubStart_Memo
On 2019/09/11 14:44, Amit Kapila wrote:
On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila wrote:
The current example shows the usage of looping in plpgsql, so as such
there is no correctness issue, but OTOH there is no harm in updating
the example as proposed by Ian Barwick. Does anyone else see any
On 2019-Sep-06, vignesh C wrote:
> Hi Thomas,
>
> While testing one of the recovery scenarios I found one issue:
> FailedAssertion("!(logno == context->recovery_logno)
I marked this patch Waiting on Author.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 2
On Wed, Sep 11, 2019 at 7:10 PM Peter Geoghegan wrote:
> The patch has been committed already.
Oh, wait. It hasn't. Andrey didn't create a new thread for his largely
independent patch, so I incorrectly assumed he created a CF entry for
his original bugfix.
--
Peter Geoghegan
The patch has been committed already.
Peter Geoghegan
(Sent from my phone)
Hi Tom,
On Tue, Sep 10, 2019 at 9:48 PM Tom Lane wrote:
>
> > Can we try to pull up direct-correlated ANY SubLink with the help of
> > LATERAL?
>
> Perhaps. But what's the argument that you'd end up with a better
> plan? LATERAL pretty much constrains things to use a nestloop,
> so I'm not sur
Hello, thanks for pinging.
At Wed, 11 Sep 2019 19:15:24 -0300, Alvaro Herrera
wrote in <20190911221524.GA16563@alvherre.pgsql>
> On 2019-Aug-30, Peter Eisentraut wrote:
>
> > Attached is an updated patch for this. I have changed the initdb option
> > name per suggestion. The WAL receiver is n
On 2019-Jul-11, Dmitry Dolgov wrote:
> > On Thu, Jul 11, 2019 at 9:47 AM David Fetter wrote:
> >
> > Looks great!
> >
> > The tutorial piece has bit-rotted slightly. Please find attached a
> > patch atop yours that fixes it.
>
> Indeed, I've missed this change, thank you! Although there supposed
On 2019-Aug-15, Andrey Borodin wrote:
> PFA V1 of this check retry.
CFbot complains that this doesn't apply; can you please rebase?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Sep 11, 2019 at 10:52:01PM +0200, Fabien COELHO wrote:
> AFAICR this is because the coverage was not the same:-) Some backslash
> commands just skip silently to the end of the line, so that intermediate
> \commands on the same line are not recognized/processed the same, so I moved
> everyth
On Wed, Sep 11, 2019 at 04:53:16PM +0200, Daniel Verite wrote:
> I think it would be nice to have CREATE COLLATION report this
> information as feedback in the form of a NOTICE message.
> PFA a simple patch implementing that.
Why is that better than the descriptions provided with \dO[S]+ in
psql?
On Wed, Sep 11, 2019 at 3:09 PM Peter Geoghegan wrote:
> Hmm. So v12 seems to have some problems with the WAL logging for
> posting list splits. With wal_debug = on and
> wal_consistency_checking='all', I can get a replica to fail
> consistency checking very quickly when "make installcheck" is run
On Wed, Sep 11, 2019 at 01:44:28AM +0300, Nikita Glukhov wrote:
On 11.09.2019 1:03, Tomas Vondra wrote:
On Tue, Sep 10, 2019 at 04:30:41AM +0300, Nikita Glukhov wrote:
2. New AM method amattoptions().
amattoptions() is used to specify per-column AM-specific options.
The example is signat
On Sun, Sep 8, 2019 at 1:21 AM Andrey Borodin wrote:
> Maybe we should PageGetItemIdCareful() to amcheck.c too?
> I think it can be reused later by GIN entry tree and to some extent by
> SP-GiST.
> SP-GiST uses redirect tuples, but do not store this information in line
> pointer.
Well, the deta
On 2019-Aug-30, Peter Eisentraut wrote:
> Attached is an updated patch for this. I have changed the initdb option
> name per suggestion. The WAL receiver is now started concurrently with
> the base backup. There is progress reporting (ps display), fsyncing.
> Configuration files are not copied
On Wed, Sep 11, 2019 at 5:38 AM Anastasia Lubennikova
wrote:
> Attached is v12, which contains WAL optimizations for posting split and
> page
> deduplication.
Hmm. So v12 seems to have some problems with the WAL logging for
posting list splits. With wal_debug = on and
wal_consistency_checking='al
Here's a rebased version of this patch (it had a trivial conflict).
No further changes.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/post
On 2019-Jul-31, Rafia Sabih wrote:
> I had a look at this patch, seems like a useful thing to have.
So the two initial questions for this patch are
1. Is this a feature we want?
2. Is the user interface correct?
I think the feature is useful, and Rafia also stated as much. Therefore
ISTM we're
On 2019-Aug-21, Bruce Momjian wrote:
> > 1) How exactly should we report this incompatibility to a user?
> > I think it's fine to leave the warnings and also write some hint for the
> > user by analogy with other checks.
> > "Reset ACL on the problem functions to default in the old cluster to
> >
Stephen,
On 2019-Aug-20, Stephen Frost wrote:
> Will try to take a look at the actual patch later today.
Any word on that review?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello,
I moved this patch from "Bug Fixes" to Security.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Sep 11, 2019 at 5:38 AM Anastasia Lubennikova
wrote:
> I reviewed them and everything looks good except the idea of not
> splitting dead posting tuples.
> According to comments to scan->ignore_killed_tuples in genam.c:107,
> it may lead to incorrect tuple order on a replica.
> I don't sure
Bonjour Michaël,
+=item $node->icommand_checks(cmd, ...)
+
+=cut
+
+sub icommand_checks
Surely this can have a better description, like say
PostgresNode::command_checks_all.
Ok.
Is Expect compatible down to perl 5.8.0 which is the minimum required
for the TAP tests (see src/test/perl/READM
On 2019-Sep-03, Alvaro Herrera wrote:
> On 2019-Jul-25, Craig Ringer wrote:
>
> > Patch attached.
>
> Here's a non-broken version of this patch. I have not done anything
> other than reflowing the new comment.
Reading over this code, I noticed that the detection of the catch-up
state ends up b
Hi Alexander,
Thanks for the initial review!
> * Your patch doesn't follow coding convention. In particular, it
> uses spaces for indentation instead of tabs. Moreover, it changes
> tags to spaces in places it doesn't touch. As the result, patch is
> "dirty". Looks like your IDE isn't properl
I've not had time to work on this issue, and there are a few remaining
problems in the patch; mostly that I will need to change the way pg_dump
represents the replica identity so that it is only defined when the
index is dumped in all partitions rather than immediately after creating
the index. Al
Thanks for looking at it!
On Wed, Sep 11, 2019 at 6:45 AM Michael Paquier wrote:
>
> An invalid query ID is assumed to be 0 in the patch, per the way it is
> defined in pg_stat_statements. However this also maps with the case
> where we have a utility statement.
Oh indeed. Which means that if
On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
>
> On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > Good thought, but I think even if we want to change the name of
> > tuple_data_split, it might be better done separately.
>
> Yes, that's not the problem of this patch. Not
> > > Is it acceptable for PG12?
> > In general absolutely.
>
> It seems far too late to be considering any major rewrite for v12;
> even assuming that there was consensus on the rewrite being an
> improvement, which I bet there won't be.
Oops, I read 13. Yes, it's obviously way too late for 12.
On Wed, Sep 11, 2019 at 11:30 PM Alvaro Herrera from 2ndQuadrant
wrote:
>
> On 2019-Sep-11, Masahiko Sawada wrote:
>
> > On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
> > >
> > > On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > > > Good thought, but I think even if we wan
Thank you very much.
- 原始邮件 -
发件人：ilm...@ilmari.org (Dagfinn Ilmari Mannsåker)
收件人：
抄送人："pgsql-hackers"
主题：Re: Does PostgreSQL support debian Linux on Arm CPU Platform?
日期：2019年09月10日 18点08分
writes:
> Hi,I just want know does PostgreSQL support debian Linux with ARM CPU
> Platform,Than
As far as i can see，PostgreSQL BuildFarm is used to detect build failures on a
large collection of platforms and configurations.Is it necessary to do
function and performance test on a new platforms, Is there any tools to do
this.Thank you very much.
- 原始邮件 -
发件人：Andrew Dunstan
收件人：g
On 2019-Sep-11, Masahiko Sawada wrote:
> On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote:
> >
> > On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> > > Good thought, but I think even if we want to change the name of
> > > tuple_data_split, it might be better done separately.
>
On 09.09.2019 18:12, Konstantin Knizhnik wrote:
On 06.09.2019 19:41, Konstantin Knizhnik wrote:
On 06.09.2019 1:01, Jaime Casanova wrote:
Sadly i got a lot of FAILED tests, i'm attaching the diffs on
regression with installcheck and installcheck-parallel.
btw, after make installcheck-par
Hi,
The 'locale' or 'lc_collate/lc_ctype' argument of an ICU collation may
have a complicated syntax, especially with non-deterministic
collations, and input mistakes in these names will not necessarily be
detected as such by ICU.
The "display name" of a locale is a simple way to get human-reada
10.09.2019 14:42, Asim R P wrote:
Hi Anastasia
On Thu, Aug 22, 2019 at 9:43 PM Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
>
> But during the review, I found a bug in the current implementation.
> New behavior must apply to crash-recovery only, now it applies to
archiv
By the way, Fabien, you are marked as a reviewer of this patch since the
end of June. Are you planning to review it?
Not this round.
--
Fabien.
Hoi Tom,
On Wed, 11 Sep 2019 at 00:18, Tom Lane wrote:
>
> I pushed 0001 after doing some hacking on it --- it was sloppy about
> datatypes, and about whether the invalid-entry value is 0 or -1,
> and it was just wrong about keeping the list in backendid order.
> (You can't conditionally skip l
Michael Meskes writes:
> Hi Kuroda-san,
>> In order to modify bugs, I think many designs, implementations,
>> and specifications should be changed.
> I hope the authors of said patch speak up and explain why they
> implemented it as is.
>> Is it acceptable for PG12?
> In general absolutely.
I
On Tue, Sep 10, 2019 at 11:54 PM Michael Paquier wrote:
> On Tue, Sep 10, 2019 at 08:03:32AM -0400, Robert Haas wrote:
> > -1. I think it's very useful to have routines for this sort of thing
> > that return an error message rather than emitting an error report
> > directly. That gives the caller
On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
> I propose to settle this issue by applying "Robert's changes two and
> three", which has been +1'd by two people already and I also accept
> myself as improvement. I don't think any further changes are required.
Applied, marked item commit
There are only four subsystems which require a callback at the
beginning of each subtransaction: the relevant functions are
AtSubStart_Memory, AtSubStart_ResourceOwner, AtSubStart_Notify, and
AfterTriggerBeginSubXact. The AtSubStart_Memory and
AtSubStart_ResourceOwner callbacks seem relatively unob
On 2019-Sep-11, Amit Khandekar wrote:
> I reproduced the error "exceeded maxAllocatedDescs (492) while trying
> to open file ...", which was also discussed about in the thread [1].
> This issue is similar but not exactly the same as [1]. In [1], the
> file for which this error used to show up was
Hello Amit,
Thanks for the feedback.
+ case 11: /* partitions */
+ initialization_option_set = true;
+ partitions = atoi(optarg);
+ if (partitions < 0)
+ {
+ fprintf(stderr, "invalid number of partitions: \"%s\"\n",
+ optarg);
+ exit(1);
+ }
+ break;
Is there a reason why we treat "partitions
09.09.2019 22:54, Peter Geoghegan wrote:
Attached is v11, which makes the kill_prior_tuple optimization work
with posting list tuples. The only catch is that it can only work when
all "logical tuples" within a posting list are known-dead, since of
course there is only one LP_DEAD bit available f
On Sun, Sep 1, 2019 at 1:37 PM Alexander Korotkov
wrote:
>
> Hi!
>
> I found it weird that CLUSTER/VACUUM FULL don't write visibility map.
> Attached patch implements writing visibility map in
> heapam_relation_copy_for_cluster().
>
> I've studied previous attempt to implement this [1]. The main
Hi Kuroda-san,
> This feature, committed last February, has some bugs.
> ...
> * This syntax does not have oracle compatibility.
This in itself is not a bug. If the syntax is not standard compliant,
then it's a bug. That of course does not mean we would not like to be
Oracle compatible where poss
Hi,
I reproduced the error "exceeded maxAllocatedDescs (492) while trying
to open file ...", which was also discussed about in the thread [1].
This issue is similar but not exactly the same as [1]. In [1], the
file for which this error used to show up was
"pg_logical/mappings/map" , while here
On Wed, Sep 11, 2019 at 10:03 AM Pavel Stehule wrote:
>
> st 11. 9. 2019 v 9:49 odesílatel Erik Rijkers napsal:
>>
>> On 2019-09-11 08:14, Pavel Stehule wrote:
>> > Hi
>> >
>> > [matviews not showing up in information_schema.tables]
>> >
>> > Is it expected behave? Tested on master branch.
>>
>>
st 11. 9. 2019 v 11:51 odesílatel Amit Kapila
napsal:
> On Wed, Sep 11, 2019 at 11:40 AM Pavel Stehule
> wrote:
> >
> > st 11. 9. 2019 v 7:45 odesílatel Amit Kapila
> napsal:
> >>
> >> On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila
> wrote:
> >> >
> >> > The current example shows the usage of loop
On Wed, Sep 11, 2019 at 11:40 AM Pavel Stehule wrote:
>
> st 11. 9. 2019 v 7:45 odesílatel Amit Kapila napsal:
>>
>> On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila wrote:
>> >
>> > The current example shows the usage of looping in plpgsql, so as such
>> > there is no correctness issue, but OTOH ther
Dear ALL,
I want to report and consult about DECLARE STATEMENT.
This feature, committed last February, has some bugs.
* This is not thread-independent.
* If some cursors are declared for the same SQL identifier,
only one cursor you declared at last is enabled.
* This syntax does not have oracl
st 11. 9. 2019 v 10:52 odesílatel Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> napsal:
> On Wed, Sep 11, 2019 at 10:03 AM Pavel Stehule
> wrote:
> >
> > st 11. 9. 2019 v 9:49 odesílatel Erik Rijkers napsal:
> >>
> >> On 2019-09-11 08:14, Pavel Stehule wrote:
> >> > Hi
> >> >
> >> >
Hi Antonin,
On Wed, Sep 11, 2019 at 3:25 PM Antonin Houska wrote:
>
> Nevertheless, I don't know how to overcome the problems that I mentioned
> upthread.
>
Do you mean the problem "the WHERE clause of the subquery didn't
participate in the SEMI JOIN evaluation"? Good news is it has been fixed
st 11. 9. 2019 v 9:49 odesílatel Erik Rijkers napsal:
> On 2019-09-11 08:14, Pavel Stehule wrote:
> > Hi
> >
> > [matviews not showing up in information_schema.tables]
> >
> > Is it expected behave? Tested on master branch.
>
> I think it is; it has been like this all along.
>
> ( matviews are in
Tom Lane wrote:
> > Can we try to pull up direct-correlated ANY SubLink with the help of
> > LATERAL?
>
> Perhaps. But what's the argument that you'd end up with a better
> plan? LATERAL pretty much constrains things to use a nestloop,
> so I'm not sure there's anything fundamentally different
On 2019-09-11 08:14, Pavel Stehule wrote:
Hi
[matviews not showing up in information_schema.tables]
Is it expected behave? Tested on master branch.
I think it is; it has been like this all along.
( matviews are in pg_matviews. )
Hi Antonin,
On Tue, Sep 10, 2019 at 4:31 PM Antonin Houska wrote:
> Richard Guo wrote:
>
> > Can we try to pull up direct-correlated ANY SubLink with the help of
> > LATERAL?
>
> > By this way, we can convert the query:
> >
> > select * from a where a.i = ANY(select i from b where a.j > b.j);
>
Robert Haas wrote:
> > -1. I think it's very useful to have routines for this sort of thing
> > that return an error message rather than emitting an error report
> > directly. That gives the caller a lot more control.
Michael Paquier wrote:
> 1) Consistency with the error messages makes less work
63 matches
Mail list logo
