On Tue, Mar 17, 2020 at 03:37:49PM +0900, Michael Paquier wrote:
> On Mon, Mar 16, 2020 at 03:05:20PM +0100, Julien Rouhaud wrote:
> > On Mon, Mar 16, 2020 at 04:57:38PM +0900, Michael Paquier wrote:
> >> This comes from a regression test doing a sanity check to look for
> >> catalogs which have a
Hi Ashutosh,
On Wed, Mar 4, 2020 at 1:48 AM Ashutosh Bapat
wrote:
> I reviewed the patch. Except for the logic of matching the pairs of
> partitions from already merged partitions, I think the code changes are good.
> But there are several places where it needs further changes to comments. The
Hi,
In PageIsVerified() we report a WARNING as follows:
ereport(WARNING,
(ERRCODE_DATA_CORRUPTED,
errmsg("page verification failed, calculated checksum
%u but expected %u",
checksum, p->pd_checksum)));
However the error message won
On Tue, Mar 17, 2020 at 2:08 PM Masahiko Sawada
wrote:
>
> Hi,
>
> In PageIsVerified() we report a WARNING as follows:
>
> ereport(WARNING,
> (ERRCODE_DATA_CORRUPTED,
> errmsg("page verification failed, calculated checksum
> %u but expected %u",
>
On Tue, Mar 17, 2020 at 10:00 AM Amit Kapila wrote:
>
> On Tue, Mar 17, 2020 at 2:08 PM Masahiko Sawada
> wrote:
> >
> > Hi,
> >
> > In PageIsVerified() we report a WARNING as follows:
> >
> > ereport(WARNING,
> > (ERRCODE_DATA_CORRUPTED,
> > errmsg("page
About v13, seens as one patch:
Function "pg_ls_dir_metadata" documentation suggests a variable number of
arguments with brackets, but parameters are really mandatory.
postgres=# SELECT pg_ls_dir_metadata('.');
ERROR: function pg_ls_dir_metadata(unknown) does not exist
LINE 1: SELECT pg_ls
On Tue, Mar 17, 2020 at 10:26:57AM +0100, Julien Rouhaud wrote:
> On Tue, Mar 17, 2020 at 10:00 AM Amit Kapila wrote:
>> +1. This looks like an oversight to me.
>
> good catch! And patch LGTM.
Definitely an oversight. All stable branches down to 9.5 have
mistakes in the same area, with nothin
Hi
> Hi
>
> please rebase this patch
>
here is a attached fixed first patch
v30-0001-Base-implementation-of-subscripting-mechanism.patch
My objectives are fixed. I checked this patch and
There are not problems with build (code, documentation)
All tests passed
The code is well documented
I li
On Tue, Mar 17, 2020 at 3:28 PM Michael Paquier wrote:
>
> On Tue, Mar 17, 2020 at 10:26:57AM +0100, Julien Rouhaud wrote:
> > On Tue, Mar 17, 2020 at 10:00 AM Amit Kapila
> > wrote:
> >> +1. This looks like an oversight to me.
> >
> > good catch! And patch LGTM.
>
> Definitely an oversight.
> On Tue, Mar 17, 2020 at 11:03:22AM +0100, Pavel Stehule wrote:
>
> here is a attached fixed first patch
>
> v30-0001-Base-implementation-of-subscripting-mechanism.patch
>
> My objectives are fixed. I checked this patch and
>
> There are not problems with build (code, documentation)
> All tests pa
Hi,
Nice performance gains.
On Sun, 1 Mar 2020 at 21:36, Andres Freund wrote:
> The series currently consists out of:
>
> 0001-0005: Fixes and assert improvements that are independent of the patch,
> but
>are hit by the new code (see also separate thread).
>
> 0006: Move delayChkpt
I was trying to figure out what exactly the "crosscheck snapshot" does in the
RI checks, and hit some assertion failures:
postgres=# create table p(i int primary key);
CREATE TABLE
postgres=# create table f (i int references p on delete cascade on update
cascade deferrable initially deferred);
CR
On Mon, Mar 16, 2020 at 3:24 PM Dilip Kumar wrote:
>
+
+ /*
+ * Indicate that the lock is released for certain types of locks
+ */
+#ifdef USE_ASSERT_CHECKING
+ CheckAndSetLockHeld(locallock, false);
+#endif
}
/*
@@ -1618,6 +1666,11 @@ GrantLockLocal(LOCALLOCK *locallock, ResourceOwner owner)
Hi Amit,
On 2/25/20 3:42 AM, Amit Langote wrote:
On Tue, Feb 25, 2020 at 4:16 PM Pavel Stehule wrote:
I added this patch to a commitfest
https://commitfest.postgresql.org/27/2467/
It is very interesting speedup and it is in good direction to JIT expressions
Thank you. I was planning to do
On 3/1/20 4:10 PM, David Steele wrote:
The last Commitfest for v13 is now in progress!
Current stats for the Commitfest are:
Needs review: 192
Waiting on Author: 19
Ready for Committer: 4
Total: 215
Halfway through, here's where we stand. Note that a CF entry was added
after the stats above
On Sat, 14 Mar 2020 at 18:45, Tomas Vondra wrote:
>
> I realized there's one more thing that probably needs discussing.
> Essentially, these two clause types are the same:
>
>a IN (1, 2, 3)
>
>(a = 1 OR a = 2 OR a = 3)
>
> but with 8f321bd1 we only recognize the first one as compatible wit
I made some improvements over old implementation WAIT FOR.
Synopsis
==
WAIT FOR [ANY | SOME | ALL] event [, event ...]
and event is:
LSN value options
TIMESTAMP value
and options is:
TIMEOUT delay
UNTIL TIMESTAMP timestamp
ALL - option used by
On Tue, Mar 17, 2020 at 5:14 PM Amit Kapila wrote:
>
> On Mon, Mar 16, 2020 at 3:24 PM Dilip Kumar wrote:
> >
>
> +
> + /*
> + * Indicate that the lock is released for certain types of locks
> + */
> +#ifdef USE_ASSERT_CHECKING
> + CheckAndSetLockHeld(locallock, false);
> +#endif
> }
>
> /*
> @
Hi David,
On Tue, Mar 17, 2020 at 8:53 PM David Steele wrote:
>
> Hi Amit,
>
> On 2/25/20 3:42 AM, Amit Langote wrote:
> > On Tue, Feb 25, 2020 at 4:16 PM Pavel Stehule
> > wrote:
> >> I added this patch to a commitfest
> >>
> >> https://commitfest.postgresql.org/27/2467/
> >>
> >> It is very i
How to install https://github.com/sraoss/pgsql-ivm on postgress running on
Ubuntu and aws postgress
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
> If we support a wrapper we should support it for all pg_ctl usage IMO.
As i understand it - you propose to patch pg_ctl.c & regress.c instead of
PostgresNode.pm & regress.c?
This is a deeper invasion to pg_ctl. There will be a conflict between the
environment variable and the pg_ctl -p parame
> If we support a wrapper we should support it for all pg_ctl usage IMO.
As i understand it - you propose to patch pg_ctl.c & regress.c instead of
PostgresNode.pm & regress.c?
This is a deeper invasion to pg_ctl. There will be a conflict between the
environment variable and the pg_ctl -p parame
Amit Kapila writes:
> On Tue, Mar 17, 2020 at 3:28 PM Michael Paquier wrote:
>> Definitely an oversight. All stable branches down to 9.5 have
>> mistakes in the same area, with nothing extra by grepping around.
>> Amit, I guess that you will take care of it?
> Yes, I will unless I see any objec
On 3/16/20 5:51 PM, ankurthakkar wrote:
> How to install https://github.com/sraoss/pgsql-ivm on postgress running on
> Ubuntu and aws postgress
That project appears to include its own modified version of
PostgreSQL, so to use it you would simply build it. It isn't something
that can just be instal
njhjo
Enviado desde mi Redmi 4AEl Julien Rouhaud , 16 mar. 2020 3:05 p. m. escribió:On Mon, Mar 16, 2020 at 04:57:38PM +0900, Michael Paquier wrote:
> On Thu, Mar 12, 2020 at 03:00:26PM +0100, Julien Rouhaud wrote:
> > And v15 due to conflict with b08dee24a5 (Add pg_dump support for ALTER obj
On Tue, Mar 17, 2020 at 01:14:02AM +0100, Laurenz Albe wrote:
> lazy_check_needs_freeze() is only called for an aggressive vacuum, which
> this isn't.
> --- a/src/backend/access/heap/vacuumlazy.c
> +++ b/src/backend/access/heap/vacuumlazy.c
> @@ -1388,17 +1388,26 @@ lazy_scan_heap(Relation onerel,
On Sun, Mar 15, 2020 at 09:52:18PM +0300, Kirill Bychik wrote:
> > > > On Thu, Mar 5, 2020 at 8:55 PM Kirill Bychik
> > > > wrote:
> After extensive thinking and some code diving, I did not manage to
> come up with a sane idea on how to expose data about autovacuum WAL
> usage. Must be the flu.
>
On Tue, Mar 17, 2020 at 12:42:52PM +, Dean Rasheed wrote:
On Sat, 14 Mar 2020 at 18:45, Tomas Vondra wrote:
I realized there's one more thing that probably needs discussing.
Essentially, these two clause types are the same:
a IN (1, 2, 3)
(a = 1 OR a = 2 OR a = 3)
but with 8f321bd
Daniel Gustafsson writes:
>> On 16 Mar 2020, at 17:12, Tom Lane wrote:
>> So I'm now leaning to "back-patch and make sure to mention this in
>> the next release notes". Barring objections, I'll do that soon.
> None from me.
Done. In the event, it only seemed practical to back-patch as far as
On Tue, 17 Mar 2020 at 15:37, Tomas Vondra wrote:
>
> On Tue, Mar 17, 2020 at 12:42:52PM +, Dean Rasheed wrote:
>
> >The other thing that I'm still concerned about is the possibility of
> >returning estimates with P(a,b) > P(a) or P(b). I think that such a
> >thing becomes much more likely wit
On Tue, Mar 17, 2020 at 02:33:32PM +0900, Michael Paquier wrote:
> > Yeah, in cluster(), mark_index_clustered().
>
> Patch 0002 from Justin does that, I would keep this refactoring as
> HEAD-only material though, and I don't spot any other code paths in
> need of patching.
>
> The commit message
Did we discuss the regcollation type? In the current patch set, it's
only used in two places in a new regression test, where it can easily be
replaced by a join. Do we need it?
I realize we've been adding new reg* types lately; I'm not sure what the
current idea is on that.
--
Peter Eisent
Re: Peter Eisentraut 2020-03-17
> Did we discuss the regcollation type? In the current patch set, it's only
> used in two places in a new regression test, where it can easily be replaced
> by a join. Do we need it?
>
> I realize we've been adding new reg* types lately; I'm not sure what the
>
Hello
Sorry for late replies.
> Yes. In my opinion, patch 0002 should not change the GUC mode of
> wal_receiver_create_temp_slot as the discussion here is about
> primary_conninfo, even if both may share some logic regarding WAL
> receiver shutdown and its restart triggered by the startup process
On Tue, Mar 17, 2020 at 04:14:26PM +, Dean Rasheed wrote:
On Tue, 17 Mar 2020 at 15:37, Tomas Vondra wrote:
On Tue, Mar 17, 2020 at 12:42:52PM +, Dean Rasheed wrote:
>The other thing that I'm still concerned about is the possibility of
>returning estimates with P(a,b) > P(a) or P(b).
On Fri, 13 Mar 2020 at 21:55, Alvaro Herrera
wrote:
> On 2020-Mar-11, Ashutosh Bapat wrote:
>
> > On Thu, Feb 27, 2020 at 10:22 PM Alvaro Herrera
> > wrote:
>
> > > * The new function I added, ReportTriggerPartkeyChange(), contains one
> > > serious bug (namely: it doesn't map attribute numbers
On Tue, Mar 17, 2020 at 05:31:47PM +0100, Christoph Berg wrote:
> Re: Peter Eisentraut 2020-03-17
>
> > Did we discuss the regcollation type? In the current patch set, it's only
> > used in two places in a new regression test, where it can easily be replaced
> > by a join. Do we need it?
I or
On 2020-Mar-17, Sergei Kornilov wrote:
> Well, it seems better to move this patch to next commitfest?
What? You want to make wal_receiver_create_temp_slot unchangeable and
default to off in pg13, and delay the patch that fixes those things to
pg14? That makes no sense to me. Please keep them b
út 17. 3. 2020 v 1:55 odesílatel Nikita Glukhov
napsal:
> Attached 44th version of the patches.
>
>
> On 12.03.2020 16:41, Pavel Stehule wrote:
>
>
> On 12.03.2020 00:09 Nikita Glukhov wrote:
>
>> Attached 43rd version of the patches.
>>
>> The previous patch #4 ("Add function formats") was remov
Hi,
On 2020-03-16 16:03:51 -0700, Mark Dilger wrote:
> While working on object access hooks, I noticed several locations
> where I would expect the hook to be invoked, but no actual invocation.
> I think this just barely qualifies as a bug. It's debatable because
> whether it is a bug depends on
> On 2020/03/15 19:32, Peter Eisentraut wrote:
> > On 2020-03-13 22:24, Peter Eisentraut wrote:
> >> On 2020-03-10 19:07, Alvaro Herrera wrote:
> >>> I like these patches; the first two are nice cleanup.
> >>>
> >>> My only gripe is that pgstat_get_backend_desc() is not really a pgstat
> >>> functi
On Tue, Mar 17, 2020 at 10:21:48AM +0100, Fabien COELHO wrote:
>
> About v13, seens as one patch:
>
> Function "pg_ls_dir_metadata" documentation suggests a variable number of
> arguments with brackets, but parameters are really mandatory.
Fixed, and added tests on 1 and 3 arg versions of both p
Justin Pryzby writes:
> It seems like the only way to make variable number of arguments is is with
> multiple entries in pg_proc.dat, one for each "number of" arguments. Is that
> right ?
Another way to do it is to have one entry, put the full set of arguments
into the initial pg_proc.dat data,
Thanks Arseny and Masahiko, I pushed this patch just now. I changed
some comments while at it, hopefully they are improvements.
On 2020-Mar-09, Masahiko Sawada wrote:
> ctx = CreateInitDecodingContext(plugin, NIL,
> - false, /* do not build snapshot */
> +
> > Please feel free to work on any extension of this patch idea. I lack
> > both time and knowledge to do it all by myself.
>
>
> I'm adding a 3rd patch on top of yours to expose the new WAL counters in
> pg_stat_database, for vacuum and autovacuum. I'm not really enthiusiastic
> with
> this app
On Mon, Mar 16, 2020 at 7:08 AM Michail Nikolaev
wrote:
> -- ABSTRACT --
> There is a race condition between btree_xlog_unlink_page and _bt_walk_left.
> A lot of versions are affected including 12 and new-coming 13.
> Happens only on standby. Seems like could not cause invalid query result
On Mon, Mar 16, 2020 at 10:20 PM Andrey M. Borodin wrote:
> It seems to me that it's exactly the same check that I was trying to verify
> in amcheck patch [0].
> But there it was verified inside amcheck, but here it is verified by index
> scan.
Maybe we can accept your patch after fixing this b
> On Mar 17, 2020, at 11:49 AM, Andres Freund wrote:
>
> On 2020-03-16 16:03:51 -0700, Mark Dilger wrote:
>> While working on object access hooks, I noticed several locations
>> where I would expect the hook to be invoked, but no actual invocation.
>> I think this just barely qualifies as a bu
On Tue, 2020-03-17 at 10:24 -0500, Justin Pryzby wrote:
> > --- a/src/backend/access/heap/vacuumlazy.c
> > +++ b/src/backend/access/heap/vacuumlazy.c
> > @@ -1388,17 +1388,26 @@ lazy_scan_heap(Relation onerel, VacuumParams
> > *params, LVRelStats *vacrelstats,
> >else
> >
On Tue, Mar 17, 2020 at 08:42:07PM +0100, Laurenz Albe wrote:
> Also, since aggressive^H^H^H^H^H^H^H^H^H^Hproactive freezing seems to be a
> performance problem in some cases (pages with UPDATEs and DELETEs in otherwise
> INSERT-mostly tables), I have done away with the whole freezing thing,
> whic
Hello
>> Well, it seems better to move this patch to next commitfest?
>
> What? You want to make wal_receiver_create_temp_slot unchangeable and
> default to off in pg13, and delay the patch that fixes those things to
> pg14? That makes no sense to me.
I want to handle similar things in a similar
On Tue, Mar 17, 2020 at 10:27:05PM +0300, Kirill Bychik wrote:
> > > Please feel free to work on any extension of this patch idea. I lack
> > > both time and knowledge to do it all by myself.
> >
> > I'm adding a 3rd patch on top of yours to expose the new WAL counters in
> > pg_stat_database, for
Hello
> I have reworked that part, adding more comments about the use of GUC
> parameters when establishing the connection to the primary for a WAL
> receiver. And also I have added an extra comment to walreceiver.c
> about the use of GUcs in general, to avoid this stuff again in the
> future. The
On Fri, Mar 6, 2020 at 01:12:10PM -0500, Robert Haas wrote:
> On Fri, Mar 6, 2020 at 11:55 AM Dave Cramer wrote:
> > There have been some arguments that the client can fix this easily.
> >
> > Turns out it is not as easy as one might think.
> >
> > If the client (in this case JDBC) uses conn.comm
On Tue, 2020-03-17 at 14:56 -0500, Justin Pryzby wrote:
> I still suggest scale_factor maximum of 1e10, like
> 4d54543efa5eb074ead4d0fadb2af4161c943044
>
> Which alows more effectively disabling it than a factor of 100, which would
> progress like: ~1, 1e2, 1e4, 1e6, 1e8, 1e10, ..
>
> I don't thi
On Tue, Mar 17, 2020 at 10:01:15PM +0100, Laurenz Albe wrote:
> On Tue, 2020-03-17 at 14:56 -0500, Justin Pryzby wrote:
> > I still suggest scale_factor maximum of 1e10, like
> > 4d54543efa5eb074ead4d0fadb2af4161c943044
> >
> > Which alows more effectively disabling it than a factor of 100, which
Bruce, thanks for taking the time to summarize.
Bruce>Fourth, it is not clear how many applications would break if COMMIT
Bruce>started issuing an error rather than return success
None.
Bruce>applications that issue COMMIT and expect success after a transaction
Bruce>block has failed
An applica
On Tue, 2020-03-17 at 16:07 -0500, Justin Pryzby wrote:
> > Assume a scale factor >= 1, for example 2, and n live tuples.
> > The table has just been vacuumed.
> >
> > Now we insert m number tuples (which are live).
> >
> > Then the condition
> >
> >threshold + scale_factor * live_tuples < n
On 2019-Nov-20, Antonin Houska wrote:
> Alvaro Herrera wrote:
> > What is logical_read_local_xlog_page all about? Seems useless. Let's
> > get rid of it.
>
> It seems so. Should I post a patch for that?
No need .. it was simple enough. Just pushed it.
Thanks
--
Álvaro Herrera
On Tue, Mar 17, 2020 at 10:22:44PM +0100, Laurenz Albe wrote:
> On Tue, 2020-03-17 at 16:07 -0500, Justin Pryzby wrote:
> > > Assume a scale factor >= 1, for example 2, and n live tuples.
> > > The table has just been vacuumed.
> > >
> > > Now we insert m number tuples (which are live).
.. but no
On Tue, Mar 17, 2020 at 02:50:19PM -0400, Mike Palmiotto wrote:
> The patchset is now split out. I've just noticed that Peter Eisentraut
> included some changes for a generic MyBackendType, which I should have
> been aware of. I was unable to rebase due to these changes, but can
> fold these patche
On Tue, 2020-03-17 at 16:34 -0500, Justin Pryzby wrote:
> > > > Now we insert m number tuples (which are live).
>
> .. but not yet counted in reltuples.
Thanks for pointing out my mistake.
Here is another patch, no changes except setting the upper limit
for autovacuum_vacuum_insert_scale_factor
On Thu, Nov 7, 2019 at 9:48 PM Thomas Munro wrote:
>
> On Thu, Nov 7, 2019 at 11:37 PM Rafia Sabih wrote:
> > ...
> > Also, I noticed that the worker details are displayed for sort node even
> > without verbose, but for scans it is only with verbose. Am I missing
> > something or there is somet
On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
> On Fri, Mar 6, 2020 at 01:12:10PM -0500, Robert Haas wrote:
> > On Fri, Mar 6, 2020 at 11:55 AM Dave Cramer
> wrote:
> > > There have been some arguments that the client can fix this easily.
> > >
> > > Turns out it is not as easy as one migh
On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
> On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
> Third, the idea that individual interfaces, e.g. JDBC, should throw an
> error in this case while the server just changes the COMMIT return tag
> to ROLLBACK is confusing
On Tue, 17 Mar 2020 at 19:23, Bruce Momjian wrote:
> On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
> > On Tue, 17 Mar 2020 at 16:47, Bruce Momjian wrote:
> > Third, the idea that individual interfaces, e.g. JDBC, should throw
> an
> > error in this case while the server ju
On Mon, Mar 16, 2020 at 07:47:13AM -0500, Justin Pryzby wrote:
> Normally, when someone complains about bad plan related to no index-onlyscan,
> we tell them to run vacuum, and if that helps, then ALTER TABLE .. SET
> (autovacuum_vacuum_scale_factor=0.005).
>
> If there's two thresholds (4 GUCs an
I wrote:
> Pavel Stehule writes:
>> There was a problem just with anyrange type. This last version looks
>> perfect.
> If you think that "matching polymorphic types" is too vague, I'm
> not sure there's much daylight between there and spelling it out
> in full as this latest patch does. "anyrang
Hi,
On 2020-03-17 01:14:02 +0100, Laurenz Albe wrote:
> lazy_check_needs_freeze() is only called for an aggressive vacuum, which
> this isn't.
Hm? I mean some of these will be aggressive vacuums, because it's older
than vacuum_freeze_table_age? And the lower age limit would make that
potentially
Attached new version of reordered patches.
Questionable patches for AM-specific per-attribute options were moved to
the end, so they can be skipped now.
On 16.03.2020 18:22, Alexander Korotkov wrote:
Hi!
I took a look on this patchset. There is a first set of questions.
* Patchset badly nee
On Tue, Mar 17, 2020 at 06:05:17PM +0100, Tomas Vondra wrote:
On Tue, Mar 17, 2020 at 04:14:26PM +, Dean Rasheed wrote:
On Tue, 17 Mar 2020 at 15:37, Tomas Vondra wrote:
On Tue, Mar 17, 2020 at 12:42:52PM +, Dean Rasheed wrote:
The other thing that I'm still concerned about is the p
On Thu, Feb 13, 2020 at 11:26:45AM -0500, Tom Lane wrote:
> I see where you're coming from, but I do not think that repeating the
> whole from_item syntax in UPDATE and DELETE is the best way forward.
> In the first place, we'd inevitably forget to update those copies,
> and in the second, I'm not
Hi,
On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > I think Andres was thinking this would maybe be an optimization independent
> > of
> > is_insert_only (?)
>
> I wasn't sure.
I'm not sure myself - but I'm doubtful that using a 0 min age by default
will be ok.
I was trying to say (in a l
On 2020-Mar-17, Justin Pryzby wrote:
> +static PgSubprocess process_types[] = {
> + {
> + .desc = "checker",
> + .entrypoint = CheckerModeMain
> + },
> + {
> + .desc = "bootstrap",
> + .entrypoint = BootstrapModeMain
> + },
Maybe thi
Hello,
> > > > + */
> > > > + if (IsAutoVacuumWorkerProcess() &&
> > > > + rel->rd_rel->relispartition &&
> > > > + !(rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE))
> > >
> > > I'm not sure I understand why we do this only on autovac. Why not all
> > > analyze
I wrote:
> The cfbot will be unhappy at this point, but I need to rebase the
> main patch again ...
And rebased. Still not quite happy about some of the details in
enforce_generic_type_consistency, and I've not looked at the test
cases or documentation at all. But this should make the cfbot
happ
On 2020-Mar-17, Thomas Munro wrote:
Hi Thomas
> On Sat, Mar 14, 2020 at 10:15 AM Alvaro Herrera
> wrote:
> > I didn't manage to go over 0005 though, but I agree with Tomas that
> > having this be configurable in terms of bytes of WAL is not very
> > user-friendly.
>
> The primary control is no
On 2020-Mar-18, yuzuko wrote:
> > I think if we analyze partition tree in order from leaf partitions
> > to root table, this problem can be fixed.
> > What do you think about it?
>
> Attach the new patch fixes the above problem.
Thanks for the new version.
I'm confused about some error messages
On Mon, 16 Mar 2020 at 06:01, Andy Fan wrote:
>
> Hi All:
>
> I have re-implemented the patch based on David's suggestion/code, Looks it
> works well. The updated patch mainly includes:
>
> 1. Maintain the not_null_colno in RelOptInfo, which includes the not null from
> catalog and the not
On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > > I think Andres was thinking this would maybe be an optimization
> > > independent of
> > > is_insert_only (?)
> >
> > I wasn't sure.
>
> I'm not sure myself - but I'm doubtful
On Tue, Mar 17, 2020 at 06:43:51PM +0100, Julien Rouhaud wrote:
> On Tue, Mar 17, 2020 at 05:31:47PM +0100, Christoph Berg wrote:
>> Not sure if that's the case there, but reg* typecasts are very handy
>> when used interactively in ad-hoc queries.
>
> +1. I'm obviously biased, but I find it quite
On 2020/03/17 12:53, Thunder wrote:
Sorry.
We are using pg11, and cloned from tag REL_11_BETA2.
In that case you should upgrade to the current version
in the PostgreSQL 11 series (at the time of writing 11.7).
Regards
Ian Barwick
--
Ian Barwick https://www.2ndQuadrant.com/
On Wed, Mar 18, 2020 at 11:19:22AM +0900, Ian Barwick wrote:
> On 2020/03/17 12:53, Thunder wrote:
> > Sorry.
> > We are using pg11, and cloned from tag REL_11_BETA2.
>
> In that case you should upgrade to the current version
> in the PostgreSQL 11 series (at the time of writing 11.7).
Definitely
Hello thanks for the detailed review,
>I think the second argument indicates the bit position, which would be max
>bytea length * 8. If max bytea length covers whole int32, the second argument
>>needs to be wider i.e. int64.
Yes, it makes sence and followed.
> Some more comments on the patch
>
On Tue, Mar 17, 2020 at 11:20:44AM -0500, Justin Pryzby wrote:
> On Tue, Mar 17, 2020 at 02:33:32PM +0900, Michael Paquier wrote:
>> Patch 0002 from Justin does that, I would keep this refactoring as
>> HEAD-only material though, and I don't spot any other code paths in
>> need of patching.
>>
>>
Hi David:
Thanks for your time.
On Wed, Mar 18, 2020 at 9:56 AM David Rowley wrote:
> On Mon, 16 Mar 2020 at 06:01, Andy Fan wrote:
> >
> > Hi All:
> >
> > I have re-implemented the patch based on David's suggestion/code, Looks
> it
> > works well. The updated patch mainly includes:
> >
> >
Bruce Momjian writes:
> I have implemented the ideas above in the attached patch. I have
> synchronized the syntax to match SELECT, and synchronized the paragraphs
> describing the item.
I think that the DELETE synopsis should look like
[ USING from_item [, ...] ]
so that there's not any q
Hi Peter,
On Mon, Mar 16, 2020 at 9:49 PM Peter Eisentraut
wrote:
>
> I was trying to extract some preparatory work from the remaining patches
> and came up with the attached. This is part of your patch 0003, but
> also relevant for part 0004. The problem was that COPY (SELECT *) is
> not suffi
On Tue, Mar 17, 2020 at 6:32 PM Dilip Kumar wrote:
>
> Your changes look fine to me. I have also verified all the test and
> everything works fine.
>
I have pushed the first patch. I will push the others in coming days.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, Mar 17, 2020 at 7:39 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Tue, Mar 17, 2020 at 3:28 PM Michael Paquier wrote:
> >> Definitely an oversight. All stable branches down to 9.5 have
> >> mistakes in the same area, with nothing extra by grepping around.
> >> Amit, I guess that yo
On Tue, Mar 17, 2020 at 09:58:53PM -0400, James Coleman wrote:
> On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
> >
> > On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > > > I think Andres was thinking this would maybe be an optimization
> > > > independent of
> > > > is_insert_only (?)
On Wed, 18 Mar 2020 at 15:57, Andy Fan wrote:
> I'm now writing the code for partition index stuff, which
> is a bit of boring, since every partition may have different unique index.
Why is that case so different?
For a partitioned table to have a valid unique index, a unique index
must exist on
On Mon, Mar 16, 2020 at 09:21:22AM +0100, Julien Rouhaud wrote:
> On Mon, Mar 16, 2020 at 12:29:28PM +0900, Michael Paquier wrote:
>> With a large amount of
>> shared buffer eviction you actually increase the risk of torn page
>> reads. Instead of a logic relying on partition mapping locks, which
Hello,
I found a missing column description in the pg_statistic_ext catalog document
for this new feature.
The attached patch adds a description of the 'stxstattarget' column to
pg_statistic_ext catalog's document.
If there is a better explanation, please correct it.
Regards,
Noriyoshi Shinoda
On Tue, Mar 17, 2020 at 12:39:35PM -0700, Mark Dilger wrote:
> I agree that this does not need to be back-patched. I was debating
> whether it constitutes a bug for the purpose of putting the fix into
> v13 vs. punting the patch forward to the v14 cycle. I don't have a
> strong opinion on that.
Hi David:
On Wed, Mar 18, 2020 at 12:13 PM David Rowley wrote:
> On Wed, 18 Mar 2020 at 15:57, Andy Fan wrote:
> > I'm now writing the code for partition index stuff, which
> > is a bit of boring, since every partition may have different unique
> index.
>
> Why is that case so different?
>
> Fo
On Wed, Mar 18, 2020 at 9:01 AM Amit Kapila wrote:
>
> On Tue, Mar 17, 2020 at 7:39 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > On Tue, Mar 17, 2020 at 3:28 PM Michael Paquier
> > > wrote:
> > >> Definitely an oversight. All stable branches down to 9.5 have
> > >> mistakes in the sam
Hi,
BIND parameter truncation is good to me.
Logs could be very hard to read due to
the very long parameters recorded.
Now, parameter is extracuted from left.
e.g. "----" to "--..."
Is not necessary from right?
e.g. "----" to "...--
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*
*Project goal:*
The goal of the project is to improve the PL/JAV
On Wed, Mar 18, 2020 at 2:47 PM Alvaro Herrera wrote:
> On 2020-Mar-17, Thomas Munro wrote:
> > I didn't want counters that wrap at ~4 billion, but I did want to be
> > able to read and write concurrently without tearing. Instructions
> > like "lock xadd" would provide more guarantees that I don'
1 - 100 of 107 matches
Mail list logo
