On Wed, Nov 14, 2018 at 8:52 PM Noah Misch wrote:
> On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 6:34 PM Noah Misch wrote:
> > > On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > > > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
>
On Wed, Nov 14, 2018 at 2:42 PM Dilip Kumar wrote:
>
> On Sat, Nov 10, 2018 at 9:27 AM Amit Kapila wrote:
> >
> > 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
On Wed, Nov 14, 2018 at 7:04 AM Haribabu Kommi wrote:
>
> On Wed, Nov 14, 2018 at 12:26 AM Amit Kapila wrote:
>>
>> On Tue, Nov 13, 2018 at 11:32 AM Haribabu Kommi
>> wrote:
>> >
>> > On Mon, Nov 12, 2018 at 6:34 PM Amit Kapila
>> > wrote:
>> >> > I can revert it back to void,
>> >> >
>> >>
Hi .
On Tue, Jul 31, 2018 at 11:57 AM MyungKyu LIM
wrote:
>
> Feedback and suggestion will be very welcome.
>
Can you explain the purpose of this feature more because now we have
columns to report replication delay times like write_lag ,flush_lag and
replay_lag that can use for similar purpose
Hi,
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.
Example:
```
$ pg_config --cc
clang
Thanks, Tomas,
Yes, we want to add the hooks into postgres repo.
But before that, we plan to firstly get some feedbacks from community about
the diskquota extension implementation and usage?
Later, we'll modify our license and submit the hooks into CF.
Thanks
Hubert
On Wed, Nov 14, 2018 at 3:54
út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
tomas.von...@2ndquadrant.com> napsal:
> On Tue, 2018-11-13 at 13:55 +0100, Pavel Stehule wrote:
> > út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
> > legrand_legr...@hotmail.com> napsal:
> >
> > > Hello Pavel,
> > >
> > > What about using
Bonjour Michaël,
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 looking at the global picture I am
getting
On Wed, Nov 14, 2018 at 2:58 PM Amit Kapila wrote:
> I think you can keep it with XXX instead of Fixme as there is nothing to fix.
Changed
>
> Both the patches 0003-undo-interface-v4.patch and
> 0004-undo-interface-test-v4.patch appears to be same except for the
> name?
My bad, please find the
On 2018-Nov-15, David Rowley wrote:
> On 15 November 2018 at 07:10, Alvaro Herrera wrote:
> > What's with this comment?
> >
> > * Initially we must only set up 1 PartitionDispatch object; the
> > one for
> > * the partitioned table that's the target of the command. If we
> >
On 14/11/2018 21:42, Tom Lane wrote:
> I wrote:
>> Here's a v2 that transposes the code to C so that we can get that
>> optimization.
>
> Pushed after a bit more testing and documentation-wordsmithing.
Thank you, Tom!
--
Vik Fearing +33 6 46 75 15 36
On 2018-11-14 16:36:49 -0500, Robert Haas wrote:
> On Tue, Nov 13, 2018 at 6:44 PM Thomas Munro
> wrote:
> > I'm not sure if it matters whether we send the fd before or after the
> > write, but we still need some kind of global ordering of fds that can
> > order a given fd with respect to writes
On Wed, Nov 14, 2018 at 02:27:31PM -0500, Robert Haas wrote:
> Here are a couple of patches to illustrate this approach to this part
> of the overall problem. 0001 is, I think, a good cleanup that may as
> well be applied in isolation; it makes the code in
> RelationBuildPartitionDesc both
Progress on this patch seems to be blocked on the question of whether
we want to keep enlarging the amount of psql-specific information
in the GRANT reference page, or move that all somewhere else.
FWIW, I think I agree with Peter's position that moving it somewhere
else is the better option.
David Rowley writes:
> [ v4-0001-Add-documentation-section-appendix-detailing-some.patch ]
A few nitpicky gripes on this -
* I don't like inserting this as Appendix B, because that means
renumbering appendixes that have had their same names for a *long*
time; for instance the release notes have
On 2018/11/15 10:19, Imai, Yoshikazu wrote:
> On Tue, Nov 13, 2018 at 10:29 PM, Amit Langote wrote:
>> On 2018/11/12 13:35, Imai, Yoshikazu wrote:
>>> How amount of memory is used with above tests is...
>>>
>>> without v5 patches, Set1: 242MB
>>> without v5 patches, Set2: 247MB
>>> with v5
Fabien COELHO writes:
> I've put the patch as "Ready".
I think this could be improved some more. Perhaps something like this
(I've not bothered with markup...)
PostgreSQL does not support CHECK constraints that reference table
data other than the new or updated row being checked.
On 2018/11/15 8:58, Alvaro Herrera wrote:
> On 2018-Nov-15, David Rowley wrote:
>
>> On 15 November 2018 at 07:10, Alvaro Herrera
>> wrote:
>>> What's with this comment?
>>>
>>> * Initially we must only set up 1 PartitionDispatch object; the
>>> one for
>>> * the partitioned
Hi Amit,
On Tue, Nov 13, 2018 at 10:29 PM, Amit Langote wrote:
> On 2018/11/12 13:35, Imai, Yoshikazu wrote:
> > adjust_appendrel_attrs_multilevel for leaf1: root -> sub1 -> leaf1
> > adjust_appendrel_attrs_multilevel for leaf2: root -> sub1 -> leaf2
>
> Ah, I see what you mean.
>
> The root ->
On 2018/11/15 4:27, Robert Haas wrote:
> RelationBuildPartitionDesc doesn't lock the children
> whose relpartbounds it is fetching (!), so unless we're guaranteed to
> have already locked them children earlier for some other reason, we
> could grab the partition bound at this point and then it
Pavel Stehule wrote
> út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
> tomas.vondra@
>> napsal:
>
> My idea is very simple.
>
> 1. continual collect of data - planning start, execution start, waiting
> start, waiting end, query end
>
> 2. run a some callback function after query is
st 14. 11. 2018 v 14:06 odesílatel legrand legrand <
legrand_legr...@hotmail.com> napsal:
> Pavel Stehule wrote
> > út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
>
> > tomas.vondra@
>
> >> napsal:
> >
> > My idea is very simple.
> >
> > 1. continual collect of data - planning start, execution
>
>
>> At pgconf.eu, I canvassed this problem and some potential solutions:
>>
>
I wonder if there is a middle ground between #2 and #3. A proper mechanism
for deduplicating entries might be hard, but on the inlining stage we
already know they're going to get duplicated. Can we make a
Hello,
I noticed buildint2vector / buildoidvector assigns lbound1=0 as default
value, but array type shall have lbound1=1 in the default.
Is there some reasons for the difference?
When I made a simple C-function that returns result of int2vector which
carries attribute numbers of the argument.
Kohei KaiGai writes:
> I noticed buildint2vector / buildoidvector assigns lbound1=0 as default
> value, but array type shall have lbound1=1 in the default.
> Is there some reasons for the difference?
Backwards compatibility.
regards, tom lane
On Tue, Nov 13, 2018 at 5:03 PM Amit Kapila wrote:
>
> On Tue, Nov 13, 2018 at 3:37 PM John Naylor wrote:
> > > + In addition, extensions may have additional types.
> > >
> > > How about: "In addition, background workers registered by extensions
> > > may have additional types."?
> >
> >
On Tue, 2018-04-17 at 15:09 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Andres was working on a radix tree structure to fix this problem, but
> > that seems to be abandoned now, and it seems a major undertaking. While
> > I agree that the proposed solution is a wart, it seems much better
On Wed, Nov 14, 2018 at 3:48 PM Dilip Kumar wrote:
>
> On Wed, Nov 14, 2018 at 2:58 PM Amit Kapila wrote:
> > I think you can keep it with XXX instead of Fixme as there is nothing to
> > fix.
> Changed
> >
> > Both the patches 0003-undo-interface-v4.patch and
> >
On Thu, Nov 15, 2018 at 01:38:55PM +0900, Amit Langote wrote:
> I've fixed 0001 again to re-order the code so that allocations happen the
> correct context and now tests pass with the rebased patches.
I have been looking at 0001, and it seems to me that you make even more
messy the current
On Thu, Nov 15, 2018 at 2:05 AM Haribabu Kommi wrote:
>
> On Wed, Nov 14, 2018 at 8:45 PM Amit Kapila wrote:
>> Apart from the above, I think we should add a test where all the
>> parameters are valid as the corresponding code is not covered by any
>> existing tests.
>
>
> Added another test
On Tue, Oct 30, 2018 at 09:35:18AM +0100, Peter Eisentraut wrote:
> 1. (current implementation) New column attgenerated contains 's' for
> STORED, 'v' for VIRTUAL, '\0' for nothing. atthasdef means "there is
> something in pg_attrdef for this column".
>
> 2. Alternative: A generated column has
On Thu, Aug 2, 2018 at 6:34 PM MyungKyu LIM wrote:
>
> I changed field name from 'reply_time' to 'last_msg_send_time'.
> Because 'last_msg_send_time' is used in
> pg_stat_wal_receiver/pg_stat_subsctiption view.
> I think that field has the same meaning.
I got confused by the field name. If we
Hi,
On 2018-11-15 04:57:28 +, Noah Misch wrote:
> On Wed, Nov 14, 2018 at 12:01:52AM -0800, Andres Freund wrote:
> > - one pgbench test tested concurrent insertions into a table with
> > oids, as some sort of stress test for lwlocks and spinlocks. I *think*
> > this doesn't really have to
On 2018/11/15 14:38, Michael Paquier wrote:
> On Thu, Nov 15, 2018 at 01:38:55PM +0900, Amit Langote wrote:
>> I've fixed 0001 again to re-order the code so that allocations happen the
>> correct context and now tests pass with the rebased patches.
>
> I have been looking at 0001, and it seems to
On Thu, Nov 15, 2018 at 4:25 AM Tom Lane wrote:
> Thomas Munro writes:
> > What do you think about the attached?
>
> I think you need to cast MyStartTimestamp to uint64 before shifting
> to ensure portable behavior of the shifts. In principle it wouldn't
> matter because the int64 sign bit is
At Thu, 12 Jul 2018 10:31:46 +1200, Thomas Munro
wrote in
> I suppose someone might argue that even when it's not a hit and it's
> not a read, we might still want to count this buffer interaction in
> some other way. Perhaps there should be a separate counter? It may
> technically be a kind
Hi Tom,
Thanks for reviewing.
On Tue, Nov 13, 2018 at 10:05 AM, Tom Lane wrote:
> Richard Guo writes:
> > Currently for quals in the form of "NOT NOT (SubLink)", this SubLink
> would
> > not be considered when pulling up sublinks.
>
> Yup.
>
> > Should we give it a chance, like the attached
On 2018/11/15 11:03, Amit Langote wrote:
> As Michael pointed out, the first cleanup patch needs to be rebased due to
> a recent commit [1]. I did that to see if something we did in that commit
> made things worse for your patch, but seems fine. I had to go and change
> things outside
On Wed, Nov 14, 2018 at 12:01:52AM -0800, Andres Freund wrote:
> - one pgbench test tested concurrent insertions into a table with
> oids, as some sort of stress test for lwlocks and spinlocks. I *think*
> this doesn't really have to be a system oid column, and this was just
> because that's
Hi.
Thanks for your feedback.
> Can you explain the purpose of this feature more because now we have columns
> to report replication delay times like write_lag ,flush_lag and replay_lag
> that can use for similar purpose .
I think, time elapsed stats are very useful on DML query active system,
On Thu, Mar 1, 2018 at 10:40 AM Thomas Munro
wrote:
>
> Hi hackers,
>
> I was pinged off-list by a fellow -hackers denizen interested in the
> synchronous replay feature and wanting a rebased patch to test. Here
> it goes, just in time for a Commitfest. Please skip to the bottom of
> this
On Thu, Nov 15, 2018 at 11:38 AM Amit Kapila wrote:
>
> On Thu, Nov 15, 2018 at 2:05 AM Haribabu Kommi
> wrote:
> >
> > On Wed, Nov 14, 2018 at 8:45 PM Amit Kapila wrote:
> >> Apart from the above, I think we should add a test where all the
> >> parameters are valid as the corresponding code
On Thu, Nov 15, 2018 at 02:53:47PM +0900, Amit Langote wrote:
> As things stand today, rd_partdesc of a partitioned table must always be
> non-NULL. In fact, there are many places in the backend code that Assert it:
>
> [...]
I have noticed those, and they actually would not care much if
On 2018/11/15 15:22, Michael Paquier wrote:
>> If there are no partitions, nparts is 0, and other fields are NULL, though
>> rd_partdesc itself is never NULL.
>
> I find a bit confusing that both concepts have the same meaning, aka
> that a relation has no partition, and that it is actually
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= writes:
> I've been trying to run Postgis regress tests under Clang sanitizers and one
> of
> the issues I'm facing is the constant stream of errors during the `configure`
> step coming from calls to `pg_config`.
TBH, I do not think we should do
On 11/14/18 3:59 PM, Tom Lane wrote:
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= writes:
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.
TBH,
> On Wed, 14 Nov 2018 at 00:44, Thomas Munro
> wrote:
>
> Here is a rebased version of the patch, post pread()/pwrite(). I have
> also rewritten the commit message to try to explain the rationale
> concisely, instead of requiring the reader to consult multiple
> discussions that jump between
Hello!
I started work on patch (draft attached). Draft has changes related only to
`CREATE SUBSCRIPTION`.
I also introduce a new status (DEFFERED) for tables in `FOR TABLE` clause (but
not in publication).
New column in pg_subscription (suballtables) will be used in `REFRESH` clause
On 25/10/2018 19:35, Fabrízio de Royes Mello wrote:
>> > OK, I can refine those descriptions/comments. Do you have any concerns
>> > about the underlying principle of this patch?
>>
>> Patch with updated comments to reflect your input.
> I didn't found any issue, so the patch looks in a very
Hi,
I understand it, as I said it's not an issue; just annoying when using
sanitizers. Thanks for the information.
--
Raúl Marín Rodríguez
carto.com
I wrote:
> Hmmm ... looking at PGTYPESnumeric_from_asc, it seems like the current
> behavior is different from what was described in that old thread; the only
> case where a digit buffer wouldn't be created is a NaN. But maybe a crash
> could occur for NaN. Perhaps we should use "if (num->sign
> On Mon, 12 Nov 2018 at 13:55, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, 12 Nov 2018 at 13:29, Sergei Kornilov wrote:
> >
> > I found reproducible crash due assert failure: FailedAssertion("!(numCols >
> > 0)", File: "pathnode.c", Line: 2795)
> > > create table tablename (i int
> On Wed, 13 Jun 2018 at 06:30, Kato, Sho wrote:
>
> I add a function called ECPGfreeSQLDA() becasue there is no API for releasing
> the SQLDA stored the result set.
>
> On Mon, 18 Jun 2018 at 07:42, Thomas Munro
> wrote:
>
> I wonder how other ESQL/C implementations deal with this stuff (...)
Hello,
We've encountered a query which took forever on our database, and after
investigating why I managed to reduce the test case to something simple.
The problem is that the optimizer seems to fail to consider pushing a
predicate down a "unionized" view:
CREATE TABLE t1 AS SELECT i FROM
This is only a personal anecdote, but from my own experience with
serializability, this sort of blind update isn't often contended in
realistic workloads. The reason is that (again, IME), most blind writes
are either insertions, or "read-writes in disguise" (the client read an old
value in a
Tom Lane wrote:
> > but "one letter is enough" is not true since 9.3 that added
> > "latex-longtable" sharing the same start as "latex", and then
> > 9.5 added "asciidoc" with the same first letter as "aligned".
>
> Yeah, that text has clearly outstayed its welcome.
>
> > When a
On Wed, Nov 14, 2018 at 8:45 PM Amit Kapila wrote:
> On Wed, Nov 14, 2018 at 7:04 AM Haribabu Kommi
> wrote:
> >
> > On Wed, Nov 14, 2018 at 12:26 AM Amit Kapila
> wrote:
> >>
> >> On Tue, Nov 13, 2018 at 11:32 AM Haribabu Kommi
> >> wrote:
> >> >
> >> > On Mon, Nov 12, 2018 at 6:34 PM Amit
I wrote:
> Here's a v2 that transposes the code to C so that we can get that
> optimization.
Pushed after a bit more testing and documentation-wordsmithing.
regards, tom lane
Thanks for picking this up.
On 15 November 2018 at 07:10, Alvaro Herrera wrote:
> What's with this comment?
>
> * Initially we must only set up 1 PartitionDispatch object; the one
> for
> * the partitioned table that's the target of the command. If we must
> * route
On Fri, Nov 9, 2018 at 9:50 AM Robert Haas wrote:
> I had another idea, too. I think we might be able to reuse the
> technique Noah invented in 4240e429d0c2d889d0cda23c618f94e12c13ade7.
> That is:
>
> - make a note of SharedInvalidMessageCounter before doing any of the
> relevant catalog lookups
Hi everyone!I didn't noticed this thread for too long somehow, sorry.8 нояб. 2018 г., в 6:46, Peter Geoghegan написал(а):I don't thinkthe general "there can't be any inserters at this subtree" thing worksgiven that we have to couple buffer locks when moving right for otherreasons. We call
What's with this comment?
* Initially we must only set up 1 PartitionDispatch object; the one for
* the partitioned table that's the target of the command. If we must
* route a tuple via some sub-partitioned table, then its
* PartitionDispatch is only built
I've become more confident that this approach is correct after
discussions with others on my team and have added the patch to the
open commitfest.
I'm attaching v2 of the patch here with a regression test (that fails
on current master, but is green both with my patch and with current
master if
Also, my apologies for top posting; I forgot to remove the old email
before clicking send.
On Tue, Nov 13, 2018 at 10:45 PM Kuntal Ghosh
wrote:
> Currently, we're working on the serializable implementations for
> zheap.
Great!
> If transaction T1 reads a row version (thus acquiring a predicate lock
> on it) and a second transaction T2 updates that row version (thus
> creating a
On Tue, Nov 13, 2018 at 6:44 PM Thomas Munro
wrote:
> > That sounds a little like you are proposing to go back to the way
> > things were before 806a2aee3791244bf0f916729bfdb5489936e068 (and,
> > belatedly, bf405ba8e460051e715d0a91442b579e590328ce) although I guess
> > the division of labor
On Wed, Nov 14, 2018 at 5:43 AM Joshua Yanovski
wrote:
> This is only a personal anecdote, but from my own experience with
> serializability, this sort of blind update isn't often contended in realistic
> workloads.
> So, if this only affects transactions with blind updates, I doubt it will
"Daniel Verite" writes:
> Tom Lane wrote:
>> Ugh. Should we not fix the code so that it complains if there's
>> not a unique match? I would bet that the code was also written
>> on the assumption that any abbrevation must be unique.
> Here's a patch making "\pset format" reject ambiguous
68 matches
Mail list logo
