On Thu, Mar 19, 2020 at 3:34 PM Amit Langote wrote:
>
> Thank you Chris, Amit.
>
> On Thu, Mar 19, 2020 at 1:46 PM Amit Kapila wrote:
> > On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote:
> > >
> > >
> > > Sorry for these troubles. Attached are patches created using `git
> > > format-patch -n -
On Fri, Mar 20, 2020 at 11:24:25AM +0530, Amit Kapila wrote:
> On Fri, Mar 20, 2020 at 5:59 AM Justin Pryzby wrote:
> That makes sense. I have a few more comments:
>
> 1.
> + VACUUM_ERRCB_PHASE_INDEX_CLEANUP,
> +} errcb_phase;
>
> Why do you need a comma after the last element in the above enum
On Thu, Mar 19, 2020 at 8:21 PM Chris Bandy wrote:
>
> On 3/18/20 11:46 PM, Amit Kapila wrote:
> > On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote:
> >>
> >>
> >> Sorry for these troubles. Attached are patches created using `git
> >> format-patch -n -v6` on master at 487e9861d0.
> >>
> >
> > No
Hi,
On 2020-03-20 06:59:57 +0100, Laurenz Albe wrote:
> On Thu, 2020-03-19 at 15:17 -0700, Andres Freund wrote:
> > I am *VERY* doubtful that the attempt of using a large threshold, and a
> > tiny scale factor, is going to work out well. I'm not confident enough
> > in my gut feeling to full throa
On Fri, Mar 6, 2020 at 10:18 PM Fujii Masao
wrote:
>
> OK, so patch attached.
>
> This patch causes, if a promotion is triggered while recovery is paused,
> the paused state to end and a promotion to continue. OTOH, this patch
> makes pg_wal_replay_pause() and _resume() throw an error if it's exe
Hi,
On 2020-03-19 06:45:48 +0100, Laurenz Albe wrote:
> On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote:
> > I don't think a default scale factor of 0 is going to be ok. For
> > large-ish tables this will basically cause permanent vacuums. And it'll
> > sometimes trigger for tables that act
On Fri, 20 Mar 2020 at 01:38, Bruce Momjian wrote:
>
> On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote:
> > On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> > Well, the issue is if the user can control the user key, there is might
> > be
> > a way to make the user key
On Thu, 2020-03-19 at 14:38 -0700, Andres Freund wrote:
> > I am not sure about b). In my mind, the objective is not to prevent
> > anti-wraparound vacuums, but to see that they have less work to do,
> > because previous autovacuum runs already have frozen anything older than
> > vacuum_freeze_min
Hi,
Thanks for looking!
On 2020-03-20 18:23:03 +1300, Thomas Munro wrote:
> On Sun, Mar 1, 2020 at 9:36 PM Andres Freund wrote:
> > I'm still working on cleaning that part of the patch up, I'll post it in
> > a bit.
>
> I looked at that part on your public pgxact-split branch. In that
> versio
On Thu, 2020-03-19 at 15:17 -0700, Andres Freund wrote:
> I am doubtful it should be committed with the current settings. See below.
>
> > From 3ba4b572d82969bbb2af787d1bccc72f417ad3a0 Mon Sep 17 00:00:00 2001
> > From: Laurenz Albe
> > Date: Thu, 19 Mar 2020 20:26:43 +0100
> > Subject: [PATCH] A
On Fri, Mar 20, 2020 at 5:59 AM Justin Pryzby wrote:
>
> On Thu, Mar 19, 2020 at 03:29:31PM -0500, Justin Pryzby wrote:
> > I was going to suggest that we could do that by passing in a pointer to a
> > local
> > variable "LVRelStats olderrcbarg", like:
> > |update_vacuum_error_cbarg(vacre
On Fri, Mar 20, 2020 at 1:20 PM Pengzhou Tang wrote:
> Hi,
>
> I happen to notice that "set enable_sort to false" cannot guarantee the
> planner to use hashagg in test groupingsets.sql,
> the following comparing results of sortagg and hashagg seems to have no
> meaning.
>
>
Please forget my comme
On Sun, Mar 1, 2020 at 9:36 PM Andres Freund wrote:
> conns tps master tps pgxact-split
>
> 1 26842.49284526524.194821
> 10 246923.158682 249224.782661
> 50 695956.539704 709833.746374
> 100 1054727.043139 1903616.306028
>
Hi,
I happen to notice that "set enable_sort to false" cannot guarantee the
planner to use hashagg in test groupingsets.sql,
the following comparing results of sortagg and hashagg seems to have no
meaning.
Thanks,
Pengzhou
On Thu, Mar 19, 2020 at 7:36 AM Jeff Davis wrote:
>
> Committed.
>
> Th
Hi,
On 2020-03-19 22:32:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if it'd become a relevant backpatch pain if we started to have
> > some ereports() without the additional parens in 13+.
>
> Yeah, it would be a nasty backpatch hazard.
>
> > Would it perhaps
> > make sense t
Andres Freund writes:
> I wonder if it'd become a relevant backpatch pain if we started to have
> some ereports() without the additional parens in 13+.
Yeah, it would be a nasty backpatch hazard.
> Would it perhaps
> make sense to backpatch just the part that removes the need for the
> parents,
Hi,
On 2020-03-20 15:05:03 +1300, David Rowley wrote:
> On Fri, 20 Mar 2020 at 11:17, Andres Freund wrote:
> > I think there's too much "reinventing" autovacuum scheduling in a
> > "local" insert-only manner happening in this thread. And as far as I can
> > tell additionally only looking at a som
On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote:
> On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote:
> > - The new entry in the documentation, specially as the PG_COLORS parameter
> > seems to be currently undocumented. The programs that can use PG_COLOR
>
Hi,
On 2020-03-19 21:03:17 -0400, Tom Lane wrote:
> I wrote:
> > I think that at least some compilers will complain about side-effect-free
> > subexpressions of a comma expression. Could we restructure things so
> > that the errcode/errmsg/etc calls form a standalone comma expression
> > rather t
On Fri, 20 Mar 2020 at 11:17, Andres Freund wrote:
> I think there's too much "reinventing" autovacuum scheduling in a
> "local" insert-only manner happening in this thread. And as far as I can
> tell additionally only looking at a somewhat narrow slice of insert only
> workloads.
I understand yo
Hi,
On 2020-03-19 19:32:55 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-03-19 14:07:04 -0400, Tom Lane wrote:
> >> Now that we can rely on having varargs macros, I think we could
> >> stop requiring the extra level of parentheses,
>
> > I think that'd be an improvement, because:
> >
On Thu, Mar 19, 2020 at 8:11 PM Alvaro Herrera
wrote:
> I gave this a look. I first reformatted it so I could read it; that's
> 0001. Second I changed all the long items into s, which
>
Thanks! I didn't know about xrefs, that is a big improvement.
> are shorter and don't have to repeat the
On Thu, Mar 19, 2020 at 9:26 PM Justin Pryzby wrote:
>
> On Mon, Mar 16, 2020 at 09:08:36AM -0400, James Coleman wrote:
> > Does the original optimization cover parallel bitmap heap scans like this?
>
> It works for parallel bitmap only scans.
>
> template1=# explain analyze select count(*) from e
On Mon, Mar 16, 2020 at 09:08:36AM -0400, James Coleman wrote:
> Does the original optimization cover parallel bitmap heap scans like this?
It works for parallel bitmap only scans.
template1=# explain analyze select count(*) from exp where a between 25 and 35
and d between 5 and 10;
Finalize Ag
I wrote:
> I think that at least some compilers will complain about side-effect-free
> subexpressions of a comma expression. Could we restructure things so
> that the errcode/errmsg/etc calls form a standalone comma expression
> rather than appearing to be arguments of a varargs function?
Yeah, t
On Thu, Mar 19, 2020 at 9:34 AM Anastasia Lubennikova
wrote:
> During tests, we catched an assertion failure in _bt_killitems() for
> posting tuple in unique index:
>
> /* kitem must have matching offnum when heap TIDs match */
> Assert(kitem->indexOffset == offnum);
>
> https://github.com/postgre
On Thu, Mar 19, 2020 at 03:29:31PM -0500, Justin Pryzby wrote:
> I was going to suggest that we could do that by passing in a pointer to a
> local
> variable "LVRelStats olderrcbarg", like:
> |update_vacuum_error_cbarg(vacrelstats, VACUUM_ERRCB_PHASE_SCAN_HEAP,
> |
I gave this a look. I first reformatted it so I could read it; that's
0001. Second I changed all the long items into s, which
are shorter and don't have to repeat the title of the refered to page.
(Of course, this changes the link to be in the same style as every other
link in our documentation;
On Mon, Mar 16, 2020 at 9:08 AM James Coleman wrote:
> ...
> One question though: if I change the query to:
> explain (analyze, buffers) select count(*) from exp where a between 50
> and 100 and d between 5 and 10;
> then I get a parallel bitmap heap scan, and I only see exact heap
> blocks (see a
On Thu, Mar 19, 2020 at 9:34 AM Anastasia Lubennikova
wrote:
> Unfortunately I cannot attach test and core dump, since they rely on the
> enterprise multimaster extension code.
> Here are some details from the core dump, that I find essential:
>
> Stack is
> _bt_killitems
> _bt_release_current_pos
Andres Freund writes:
> On 2020-03-19 14:07:04 -0400, Tom Lane wrote:
>> Now that we can rely on having varargs macros, I think we could
>> stop requiring the extra level of parentheses,
> I think that'd be an improvement, because:
> ane of the ones I saw confuse people is just:
> /home/andres/sr
Hi,
On 2020-03-19 14:07:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-03-17 10:09:18 -0400, Tom Lane wrote:
> >> We might want to spend some effort thinking how to find or prevent
> >> additional bugs of the same ilk ...
>
> > Yea, that'd be good. Trying to help people new to po
Hi,
I was looking at [1], wanting to suggest a query to monitor what
autovacuum is mostly waiting on. Partially to figure out whether it's
mostly autovacuum cost limiting.
But uh, unfortunately the vacuum delay code just sleeps without setting
a wait event:
void
vacuum_delay_point(void)
{
...
Hi,
On 2020-03-20 01:11:23 +0300, Darafei "Komяpa" Praliaskouski wrote:
> > > According to my reckoning, that is the remaining objection to the patch
> > > as it is (with ordinary freezing behavior).
> > >
> > > How about a scale_factor od 0.005? That will be high enough for large
> > > tables, w
Hi,
On 2020-03-19 20:47:40 +0100, Laurenz Albe wrote:
> On Thu, 2020-03-19 at 21:39 +1300, David Rowley wrote:
> > I've attached a small fix which I'd like to apply to your v8 patch.
> > With that, and pending one final look, I'd like to push this during my
> > Monday (New Zealand time). So if an
> > According to my reckoning, that is the remaining objection to the patch
> > as it is (with ordinary freezing behavior).
> >
> > How about a scale_factor od 0.005? That will be high enough for large
> > tables, which seem to be the main concern here.
>
> Seems low on a first blush. On a large-i
Hi,
I was working on Asymmetric encryption in postgres using pgcrypto . I have
generated the keys and stored in data folder and had inserted the data
using pgcrypto encrypt function .
here the problem comes, I was trying to decrypt the data but it was
throwing me the below error
ERROR: invalid
> On 19 Mar 2020, at 22:32, Bruce Momjian wrote:
>
> bOn Mon, Mar 16, 2020 at 09:10:25PM -0300, Alvaro Herrera wrote:
>> On 2020-Mar-16, Bruce Momjian wrote:
>>
>>> On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote:
Report bugs mailto:pgsql-b...@lists.postgresql.org
P
Noah Misch writes:
> On Sun, Jan 05, 2020 at 01:33:55AM +0100, Tomas Vondra wrote:
>> It's a bit unfortunate that a patch for a data corruption / loss issue
>> (even if a low-probability one) fell through multiple commitfests.
> Thanks for investing in steps to fix that.
Yeah, this patch has bee
> On 7 Feb 2020, at 01:33, Michael Paquier wrote:
>
> On Thu, Feb 06, 2020 at 11:30:40PM +0100, Daniel Gustafsson wrote:
>> Or change to the v1 patch in this thread, which avoids the problem by doing
>> it
>> in the OpenSSL code. It's a shame to have generic TLS functionality be
>> OpenSSL
>>
Hi,
On 2020-03-19 06:45:48 +0100, Laurenz Albe wrote:
> On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote:
> > I don't think a default scale factor of 0 is going to be ok. For
> > large-ish tables this will basically cause permanent vacuums. And it'll
> > sometimes trigger for tables that act
bOn Mon, Mar 16, 2020 at 09:10:25PM -0300, Alvaro Herrera wrote:
> On 2020-Mar-16, Bruce Momjian wrote:
>
> > On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote:
> > > Report bugs mailto:pgsql-b...@lists.postgresql.org
> > > PostgreSQL home page https://www.postgresql.org/
> > >
>
Hi,
On 2020-03-19 11:35:41 +0100, Peter Eisentraut wrote:
> On 2020-03-18 17:07, Mike Palmiotto wrote:
> > On Wed, Mar 18, 2020 at 11:26 AM Mike Palmiotto
> > wrote:
> > >
> > > On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby
> > > wrote:
> > > > Also, I saw this was failing tests both before an
On Thu, Mar 19, 2020 at 1:42 PM Alvaro Herrera wrote:
>
> On 2020-Mar-16, Paul A Jungwirth wrote:
>
> > On Sat, Mar 14, 2020 at 11:13 AM Paul A Jungwirth
> > wrote:
> > > I think that should fix the cfbot failure.
> >
> > I saw this patch was failing to apply again. There was some
> > refactoring
On 2020-Mar-16, Paul A Jungwirth wrote:
> On Sat, Mar 14, 2020 at 11:13 AM Paul A Jungwirth
> wrote:
> > I think that should fix the cfbot failure.
>
> I saw this patch was failing to apply again. There was some
> refactoring to how polymorphic types are determined. I added my
> changes for anym
Hi,
I was working on Asymmetric encryption in postgres using pgcrypto . I have
generated the keys and stored in data folder and had inserted the data
using pgcrypto encrypt function .
here the problem comes, I was trying to decrypt the data but it was
throwing me the below error
ERROR: invalid
On Thu, Mar 19, 2020 at 03:18:32PM +0530, Amit Kapila wrote:
> > You're right. PHASE_SCAN_HEAP was set, but only inside a conditional.
>
> I think if we do it inside for loop, then we don't need to set it
> conditionally at multiple places. I have changed like that in the
> attached patch, see i
Hi,
I was working on Asymmetric encryption in postgres using pgcrypto . I have
generated the keys and stored in data folder and had inserted the data
using pgcrypto encrypt function .
here the problem comes, I was trying to decrypt the data but it was
throwing me the below error
ERROR: invalid
On Thu, 2020-03-19 at 16:04 -0400, Robert Haas wrote:
> Other people may have different concerns, but that was the only thing
> that was bothering me.
OK, thank you for raising it.
Perhaps we can re-fix the issue for HashAgg if necessary, or I can
tweak some accounting things within HashAgg itsel
On Thu, 2020-03-19 at 15:33 -0400, Robert Haas wrote:
> On Thu, Mar 19, 2020 at 3:27 PM Jeff Davis wrote:
> > I think omitting the tail of the current block is an unqualified
> > improvement for the purpose of obeying work_mem, regardless of the
> > OS.
> > The block sizes keep doubling up to 8MB,
On Thu, Mar 19, 2020 at 3:44 PM Jeff Davis wrote:
> On Thu, 2020-03-19 at 15:26 -0400, Robert Haas wrote:
> > Well, the issue is, if I understand correctly, that this means that
> > MemoryContextStats() might now report a smaller amount of memory than
> > what we actually allocated from the operat
Hi,
On 2020-03-19 16:51:59 +1300, Thomas Munro wrote:
> On Fri, Mar 13, 2020 at 4:13 PM Andres Freund wrote:
> > Thomas, could you look at the first two patches here, and my review
> > questions?
>
> Ack.
Thanks!
> > > dsa_pointer item_pointer = hash_table->buckets[i];
> > > @@
On Mon, 2020-03-16 at 11:45 -0700, Jeff Davis wrote:
> Although that's technically correct, the purpose of
> MemoryContextMemAllocated() is to give a "real" usage number so we
> know
> when we're out of work_mem and need to spill (in particular, the
> disk-
> based HashAgg work, but ideally other o
Hi,
On 2020-03-19 20:30:04 +0900, Kyotaro Horiguchi wrote:
> > I think we also can get rid of the dshash_delete changes, by instead
> > adding a dshash_delete_current(dshash_seq_stat *status, void *entry) API
> > or such.
>
> [009] (Fixed)
> I'm not sure about the point of having two interfaces th
On Wed, 18 Mar 2020 at 00:29, Tomas Vondra wrote:
>
> OK, I took a look. I think from the correctness POV the patch is OK, but
> I think the dependencies_clauselist_selectivity() function now got a bit
> too complex. I've been able to parse it now, but I'm sure I'll have
> trouble in the future :-
On Thu, 2020-03-19 at 21:39 +1300, David Rowley wrote:
> > According to my reckoning, that is the remaining objection to the patch
> > as it is (with ordinary freezing behavior).
> >
> > How about a scale_factor od 0.005? That will be high enough for large
> > tables, which seem to be the main con
On Thu, 2020-03-19 at 15:26 -0400, Robert Haas wrote:
> Well, the issue is, if I understand correctly, that this means that
> MemoryContextStats() might now report a smaller amount of memory than
> what we actually allocated from the operating system. That seems like
> it might lead someone trying
Bruce Momjian writes:
> On Wed, Feb 26, 2020 at 06:32:00PM +, Dagfinn Ilmari Mannsåker wrote:
>> Tom Lane writes:
>>
>> > Michael Paquier writes:
>> >> On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:
>> >>> +1, seems like that would be a regression in value.
>> >
>> >> Hav
On Thu, Mar 19, 2020 at 12:25:16PM -0700, Jeff Davis wrote:
On Thu, 2020-03-19 at 19:11 +0100, Tomas Vondra wrote:
AFAICS the 2x allocation is the worst case, because it only happens
right after allocating a new block (of twice the size), when the
"utilization" drops from 100% to 50%. But in pra
On Thu, Mar 19, 2020 at 3:27 PM Jeff Davis wrote:
> I think omitting the tail of the current block is an unqualified
> improvement for the purpose of obeying work_mem, regardless of the OS.
> The block sizes keep doubling up to 8MB, and it doesn't make a lot of
> sense to count that last large mos
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 3/19/20 2:03 PM, Alexander Korotkov wrote:
> > Does your project imply any coding? AFAIR, GSoC doesn't allow pure
> > documentation projects.
>
> That's a good question. The idea as I proposed it is more of an
> infrastructure projec
On Thu, 2020-03-19 at 11:44 -0400, Robert Haas wrote:
> Procedurally, I think that it is highly inappropriate to submit a
> patch two weeks after the start of the final CommitFest and then
> commit it just over 48 hours later without a single endorsement of
> the
> change from anyone.
Reverted.
On Thu, Mar 19, 2020 at 2:11 PM Tomas Vondra
wrote:
> My understanding is that this is really just an accounting issue, where
> allocating a block would get us over the limit, which I suppose might be
> an issue with low work_mem values.
Well, the issue is, if I understand correctly, that this me
On Thu, 2020-03-19 at 19:11 +0100, Tomas Vondra wrote:
> AFAICS the 2x allocation is the worst case, because it only happens
> right after allocating a new block (of twice the size), when the
> "utilization" drops from 100% to 50%. But in practice the utilization
> will be somewhere in between, wit
On Wed, Feb 26, 2020 at 06:32:00PM +, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
> > Michael Paquier writes:
> >> On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:
> >>> +1, seems like that would be a regression in value.
> >
> >> Having more generic messages is less
On 3/19/20 2:03 PM, Alexander Korotkov wrote:
> Does your project imply any coding? AFAIR, GSoC doesn't allow pure
> documentation projects.
That's a good question. The idea as I proposed it is more of an
infrastructure project, adjusting the toolchain that currently
autogenerates the docs (alon
On Thu, Mar 19, 2020 at 12:31:54PM +0900, Michael Paquier wrote:
> On Wed, Mar 18, 2020 at 04:35:43PM +0100, Julien Rouhaud wrote:
> > On Wed, Mar 18, 2020 at 09:56:40AM +0100, Julien Rouhaud wrote:
> > AFAICT it was only missing a call to index_update_collation_versions() in
> > ReindexRelationCon
On Wed, 18 Mar 2020 at 19:31, Tomas Vondra wrote:
>
> Attached is a rebased patch series, addressing both those issues.
>
> I've been wondering why none of the regression tests failed because of
> the 0.0 vs. 1.0 issue, but I think the explanation is pretty simple - to
> make the tests stable, all
> On Mar 19, 2020, at 11:30 AM, Mark Dilger
> wrote:
>
> Will post v3 shortly.
v3-0001-Adding-missing-Object-Access-hook-invocations.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Dean Rasheed writes:
> On Wed, 4 Mar 2020 at 14:41, David Steele wrote:
>> Are these improvements targeted at PG13 or PG14? This seems a pretty
>> big change for the last CF of PG13.
> Well of course that's not entirely up to me, but I was hoping to
> commit it for PG13.
> It's very well cover
Hi,
On 2020-03-19 17:21:38 +0900, Fujii Masao wrote:
> Pushed! Thanks!
FWIW, I'm a bit doubtful that incuring the overhead of this by default
on everybody is a nice thing. On filesystems with high latency and with
a lot of small relations the overhead of stating a lot of files can be
almost as hi
> On Mar 19, 2020, at 11:17 AM, Alvaro Herrera wrote:
>
> On 2020-Mar-18, Mark Dilger wrote:
>
>> Here is the latest patch.
>
> So you insist in keeping the Drop hook calls?
My apologies, not at all. I appear to have attached the wrong patch. Will
post v3 shortly.
—
Mark Dilger
Enterpri
On 2020-Mar-18, Mark Dilger wrote:
> Here is the latest patch.
So you insist in keeping the Drop hook calls?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Mar 19, 2020 at 11:44:05AM -0400, Robert Haas wrote:
On Mon, Mar 16, 2020 at 2:45 PM Jeff Davis wrote:
Attached is a patch that makes mem_allocated a method (rather than a
field) of MemoryContext, and allows each memory context type to track
the memory its own way. They all do the same
Greetings,
* Alexander Korotkov (a.korot...@postgrespro.ru) wrote:
> On Wed, Mar 18, 2020 at 8:13 AM p.b uday wrote:
> > Hi PostgreSQL team,
> > I am looking forward to participating in the GSoC with PostgreSQL this
> > summer. Below is my draft proposal for your review. Any feedback would be
>
Andres Freund writes:
> On 2020-03-17 10:09:18 -0400, Tom Lane wrote:
>> We might want to spend some effort thinking how to find or prevent
>> additional bugs of the same ilk ...
> Yea, that'd be good. Trying to help people new to postgres write their
> first patches I found that ereport is very
Hi!
On Wed, Mar 18, 2020 at 8:13 AM p.b uday wrote:
> Hi PostgreSQL team,
> I am looking forward to participating in the GSoC with PostgreSQL this
> summer. Below is my draft proposal for your review. Any feedback would be
> greatly appreciated.
>
> PL/Java online documentation improvements
Do
Hi,
On 2020-03-17 10:09:18 -0400, Tom Lane wrote:
> We might want to spend some effort thinking how to find or prevent
> additional bugs of the same ilk ...
Yea, that'd be good. Trying to help people new to postgres write their
first patches I found that ereport is very confusing to them - large
On 3/19/20 3:41 PM, Peter Eisentraut wrote:
What is that status of this patch set? I think we have nailed down the
behavior, but there were some concerns about certain performance
characteristics. Do people feel that those are required to be addressed
in this cycle?
Personally I would rathe
On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote:
> On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> Well, the issue is if the user can control the user key, there is might be
> a way to make the user key do nothing.
>
> Well I meant ‘USER_KEY:’ is a fixed length string
Thanks you to review this patch.
On Thu, Mar 19, 2020 at 10:09 AM Tomas Vondra
wrote:
> Hi,
>
> unfortunately this got a bit broken by the disk-based hash aggregation,
> committed today, and so it needs a rebase. I've started looking at the
> patch before that, and I have it rebased on e00912e11
On Sun, Mar 15, 2020 at 7:32 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
>
> I have committed that last one also, after some corrections.
>
IMHO we should also update file_fdw documentation. See attached!
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.ti
During tests, we catched an assertion failure in _bt_killitems() for
posting tuple in unique index:
/* kitem must have matching offnum when heap TIDs match */
Assert(kitem->indexOffset == offnum);
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtutils.c#L1809
I str
čt 19. 3. 2020 v 16:44 odesílatel Tom Lane napsal:
> I wrote:
> > Here's a pretty-nearly-final version of the patch.
> > In 0001 below, I've left it throwing an error for the case of all
> > ANYCOMPATIBLE inputs being unknown, but the documentation fails to
> > acknowledge that. 0002 below is a
On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote:
> > On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
> > >
> > > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > > > On Thu, 19 Mar 2020 at 15:59, Masahiko
I wrote:
> Here's a pretty-nearly-final version of the patch.
> In 0001 below, I've left it throwing an error for the case of all
> ANYCOMPATIBLE inputs being unknown, but the documentation fails to
> acknowledge that. 0002 below is a delta patch that switches to the
> other approach of resolving
On Mon, Mar 16, 2020 at 2:45 PM Jeff Davis wrote:
> Attached is a patch that makes mem_allocated a method (rather than a
> field) of MemoryContext, and allows each memory context type to track
> the memory its own way. They all do the same thing as before
> (increment/decrement a field), but Alloc
On Wed, Mar 18, 2020 at 4:25 PM Andres Freund wrote:
> I don't see a valid reason for that though - if anything it's dangerous,
> because we're not persistently saving the slot. It should fail the
> checkpoint imo. Robert, do you have an idea?
Well, the comment atop SaveSlotToPath says:
* This
On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote:
> On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
> >
> > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> > > > I understand that your idea is to include fixed
On Thu, Mar 19, 2020 at 09:03:02PM +0900, Fujii Masao wrote:
>
> On 2020/03/19 2:19, Julien Rouhaud wrote:
> >
> > I'm attaching a v5 with fp records only for temp tables, so there's no risk
> > of
> > instability. As I previously said I'm fine with your two patches, so unless
> > you have obje
On Wed, 18 Mar 2020 at 08:56, gmail Vladimir Koković <
vladimir.koko...@gmail.com> wrote:
> Hi,
>
>
> After a thorough Java-Swig-libpq test, I can confirm that INSERT/SELECT is
> working properly:
> 1. server_encoding: SQL_ASCII
> 2. client_encoding: SQL_ASCII
> 3. INSERT / SELECT java string with
On 3/18/20 11:46 PM, Amit Kapila wrote:
> On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote:
>>
>>
>> Sorry for these troubles. Attached are patches created using `git
>> format-patch -n -v6` on master at 487e9861d0.
>>
>
> No problem. I have extracted your code changes as a separate patch
> (se
On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
>
> On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> > > I understand that your idea is to include fixed length string to the
> > > 256 bit key in order to separate key space. But
What is that status of this patch set? I think we have nailed down the
behavior, but there were some concerns about certain performance
characteristics. Do people feel that those are required to be addressed
in this cycle?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreS
Hi,
On 3/18/20 1:11 AM, p.b uday wrote:
> summer. Below is my draft proposal for your review. Any feedback would be
> greatly appreciated.
> ...
> The goal of the project is to improve the PL/JAVA online documentation
> website in terms of appearance, usability, information showcase and
> function
On 2020-03-18 08:33, Amit Langote wrote:
By the way, I have rebased the patches, although maybe you've got your
own copies; attached.
Looking through 0002 and 0003 now.
The structure looks generally good.
In 0002, the naming of apply_handle_insert() vs.
apply_handle_do_insert() etc. seems a
On Thu, Mar 19, 2020 at 09:52:11PM +1300, David Rowley wrote:
> On Thu, 19 Mar 2020 at 19:07, Justin Pryzby wrote:
> >
> > On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote:
> > > On 2020-03-13 13:44:42 -0500, Justin Pryzby wrote:
> > > > Having now played with the patch, I'll suggest
On Thu, Mar 19, 2020 at 6:35 AM Peter Eisentraut
wrote:
>
> While working on (My)BackendType, I was attempting to get rid of
> (My)AuxProcType altogether. This would mostly work except that it's
> sort of wired into the pgstats subsystem (see NumBackendStatSlots).
> This can probably be reorganiz
On Thu, Mar 19, 2020 at 08:48:58AM +0100, Daniel Gustafsson wrote:
> Taking a look at this to see if we can achieve closure on this long-running
> patchset. The goal of the patch is IMO a clear win for usability.
>
> The patchset applies with a bit of fuzzing and offsetting, it has tests (which
>
> On 15 Jan 2020, at 00:04, Alvaro Herrera wrote:
>
> On 2020-Jan-14, Tom Lane wrote:
>
>> I can't get terribly excited about persuading that test to cover this
>> trivial little bit of logic, but if you are, I won't stand in the way.
>
> Hmm, that's a good point actually: the patch changed sev
1 - 100 of 128 matches
Mail list logo
