On Thu, 2 Apr 2020 at 15:34, Fujii Masao wrote:
>
>
>
> On 2020/04/02 14:25, Masahiko Sawada wrote:
> > On Wed, 1 Apr 2020 at 22:32, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/30 20:10, Masahiko Sawada wrote:
> >>> On Fri, 27 Mar 2020 at 17:54, Fujii Masao
> >>> wrote:
>
>
On 2020/04/02 15:01, Julien Rouhaud wrote:
On Thu, Apr 02, 2020 at 01:05:56PM +0900, Fujii Masao wrote:
On 2020/04/02 3:47, Julien Rouhaud wrote:
On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote:
On 2020/03/31 10:31, Justin Pryzby wrote:
On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julie
On Thu, Apr 02, 2020 at 03:14:21PM +0900, Michael Paquier wrote:
> Now, regarding patch 0002, note that you have a problem for this part:
> -tuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexOid));
> -if (!HeapTupleIsValid(tuple))/* probably can't happen */
> -
Hi Justin,
There are no assumption about backslash escaping, quotes and such, which
seems reasonable given the lexing structure of the files, i.e. records of
space-separated words, and # line comments.
Quoting does allow words containing spaces:
Ok.
I meant that the continuation handling
Hello David,
Attached is an attempt at improving things. I have added a explicit note
and hijacked an existing example to better illustrate the purpose of the
function.
This patch does not build on Linux due to some unused functions and
variables: http://cfbot.cputube.org/patch_27_1712.log
On Thu, Apr 02, 2020 at 11:32:16AM +0530, Amit Kapila wrote:
> On Thu, Apr 2, 2020 at 11:28 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby
> > wrote in
> > > Regarding v10-0004-Add-option-to-report-WAL-usage-in-EXPLAIN-and-au.patch:
> > > I think there sh
On Wed, Apr 1, 2020 at 8:00 PM Julien Rouhaud wrote:
>
> Hi,
>
> I'm replying here to all reviews that have been sent, thanks a lot!
>
> On Wed, Apr 01, 2020 at 04:29:16PM +0530, Amit Kapila wrote:
> > On Wed, Apr 1, 2020 at 1:32 PM Julien Rouhaud wrote:
> > >
> > > So here's a v9, rebased on top
On 2020/04/02 14:25, Masahiko Sawada wrote:
On Wed, 1 Apr 2020 at 22:32, Fujii Masao wrote:
On 2020/03/30 20:10, Masahiko Sawada wrote:
On Fri, 27 Mar 2020 at 17:54, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 13:48, Fujii Masao wrote:
Thanks all for the feedback.
On Thu, Apr 2, 2020 at 8:02 AM Amit Kapila wrote:
>
> On Thu, Apr 2, 2020 at 11:28 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby
> > wrote in
> > > On Thu, Apr 02, 2020 at 10:13:18AM +0530, Amit Kapila wrote:
> > > > In thre
>I don't think this has really solved the overflow hazards. For example,
>in binary_encode we've got
>resultlen = enc->encode_len(VARDATA_ANY(data), datalen);
>result = palloc(VARHDRSZ + resultlen);
>and all you've done about that is changed resultlen from int to int64.
>On a 64-bit machine,
On Wed, Apr 01, 2020 at 04:26:25PM +0200, Peter Eisentraut wrote:
> Good catch. How about the attached patch?
WFM. Another trick would be to call LWLockRelease() after generating
the log, but I find your patch more consistent with the surroundings.
--
Michael
signature.asc
Description: PGP sig
On Wed, Mar 18, 2020 at 11:48:37AM +0900, Michael Paquier wrote:
> Anyway, Tom, Alvaro, are you planning to look at what is proposed on
> this thread? I don't want to step on your toes if that's the case and
> it seems to me that the approach taken by the patch is sound, using as
> basic fix the a
On Thu, 2 Apr 2020 at 16:13, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Yeah, that makes sense. I still can't see what might be causing those
> > failures. The tests that were doing an ALTER COLUMN and then expecting
> > to see the results of a non-analysed table ought to be fixed by
> > 0936d1
Bonjour Michaël,
Except for the addition of a test case to skip empty results when
\aset is used, I think that we are pretty good here.
While hacking on the patch more by myself, I found that mixing tests
for \gset and \aset was rather messy. A test for an empty result
leads also to a failur
On Thu, Apr 2, 2020 at 11:28 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby wrote
> in
> > On Thu, Apr 02, 2020 at 10:13:18AM +0530, Amit Kapila wrote:
> > > In thread [1], we are discussing to expose WAL usage data for each
> > > statement in a way quite simila
On Thu, Apr 02, 2020 at 01:05:56PM +0900, Fujii Masao wrote:
>
>
> On 2020/04/02 3:47, Julien Rouhaud wrote:
> > On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao
> > wrote:
> > >
> > >
> > > On 2020/03/31 10:31, Justin Pryzby wrote:
> > > > On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud w
At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby wrote
in
> On Thu, Apr 02, 2020 at 10:13:18AM +0530, Amit Kapila wrote:
> > In thread [1], we are discussing to expose WAL usage data for each
> > statement in a way quite similar to how we expose BufferUsage data.
> > The way it exposes seems rea
On Thu, Apr 02, 2020 at 07:25:36AM +0200, Fabien COELHO wrote:
>
> Hello,
>
> > FWIW, I don't think so. Generally a trailing backspace is an escape
> > character for the following newline. And '\ ' is a escaped space,
> > which is usualy menas a space itself.
> >
> > In this case escape charact
On Thu, Apr 2, 2020 at 11:07 AM Amit Kapila wrote:
>
> On Wed, Apr 1, 2020 at 8:00 PM Julien Rouhaud wrote:
>
Also, I forgot to mention that let's not base this on buffer usage
patch for create index
(v10-0002-Allow-parallel-index-creation-to-accumulate-buff) because as
per recent discussion I a
On Thu, Apr 02, 2020 at 10:13:18AM +0530, Amit Kapila wrote:
> In thread [1], we are discussing to expose WAL usage data for each
> statement in a way quite similar to how we expose BufferUsage data.
> The way it exposes seems reasonable to me and no one else raises any
> objection. It could be th
On Wed, Apr 1, 2020 at 8:00 PM Julien Rouhaud wrote:
>
> On Wed, Apr 01, 2020 at 04:29:16PM +0530, Amit Kapila wrote:
> > 3. Doing some testing with and without parallelism to ensure WAL usage
> > data is correct would be great and if possible, share the results?
>
>
> I just saw that Dilip did so
Hello,
FWIW, I don't think so. Generally a trailing backspace is an escape
character for the following newline. And '\ ' is a escaped space,
which is usualy menas a space itself.
In this case escape character doesn't work generally and I think it is
natural that a backslash in the middle of
On Wed, 1 Apr 2020 at 22:32, Fujii Masao wrote:
>
>
>
> On 2020/03/30 20:10, Masahiko Sawada wrote:
> > On Fri, 27 Mar 2020 at 17:54, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/04 14:31, Masahiko Sawada wrote:
> >>> On Wed, 4 Mar 2020 at 13:48, Fujii Masao
> >>> wrote:
>
>
On Mon, Mar 23, 2020 at 04:50:36PM -0700, Andres Freund wrote:
> I think there's also another (even larger?) race in
> vac_update_datfrozenxid(): Unless I miss something, two backends can
> concurrently run through the scan in vac_update_datfrozenxid() for two
> different tables in the same databas
You should do small rebase (conflict with 911e7020770) and pgindent of
the patch to repair problems with long lines and backspaces.
I am reviewing your patch in small steps. Questions:
1. In the find_innerjoined_rels() routine you stop descending on
JOIN_FULL node type. I think it is wrong beca
Hi,
In thread [1], we are discussing to expose WAL usage data for each
statement in a way quite similar to how we expose BufferUsage data.
The way it exposes seems reasonable to me and no one else raises any
objection. It could be that it appears fine to others who have
reviewed the patch but I t
On Thu, Apr 2, 2020 at 9:13 AM Dilip Kumar wrote:
>
> On Thu, Apr 2, 2020 at 8:34 AM Peter Geoghegan wrote:
> >
> > On Wed, Apr 1, 2020 at 7:52 PM Amit Kapila wrote:
> > > Peter, Is this behavior expected?
> > >
> > > Let me summarize the situation so that it would be easier for Peter to
> > > c
At Thu, 02 Apr 2020 00:20:12 +, David Zhang wrote
in
> Hi Fabien,
> Should we consider the case "\ ", i.e. one or more spaces after the backslash?
> For example, if I replace a user map
> "mymap /^(.*)@mydomain\.com$ \1" with
> "mymap /^(.*)@mydomain\.com$ \ "
> "\1"
> by add
On Thu, 2 Apr 2020 at 07:57, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Apr-01, Tom Lane wrote:
> >> The fact that I had to use max(age(...)) in that sample query
> >> hints at one reason: it's really hard to do arithmetic correctly
> >> on raw XIDs. Dealing with wraparound is a probl
On 2020/04/02 3:47, Julien Rouhaud wrote:
On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote:
On 2020/03/31 10:31, Justin Pryzby wrote:
On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud wrote:
Rebase due to conflict with 3ec20c7091e97.
This is failing to apply probably since
4a539
On Mon, Mar 30, 2020 at 11:37:57PM -0700, Andres Freund wrote:
> On 2020-03-30 23:28:54 -0700, Noah Misch wrote:
> > On Mon, Mar 30, 2020 at 04:43:00PM +0900, Michael Paquier wrote:
> > > On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote:
> > > > I think attached v41nm is ready for commit.
>
> I propose we define "planner" and make "optimizer" a entry.
>
I have no objection to more entries, or edits to entries, but am concerned
that the process leads to someone having to manually merge several
start-from-scratch patches, with no clear sense of when we'll be done. I
may make sense t
On Thu, Apr 2, 2020 at 8:34 AM Peter Geoghegan wrote:
>
> On Wed, Apr 1, 2020 at 7:52 PM Amit Kapila wrote:
> > Peter, Is this behavior expected?
> >
> > Let me summarize the situation so that it would be easier for Peter to
> > comment. Julien has noticed that parallel vacuum and parallel creat
>
> 2. I found out that "see xyz" and "see also" have bespoke markup in
> Docbook -- and . I changed some glossentries
> to use those, removing some glossdefs and changing a couple of paras to
> glossseealsos. I also removed all "id" properties from glossentries
> that are just , because I think
On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro wrote:
> * updated OIDs to avoid collisions
> * added btequalimage to btree/xid8_ops
Here's the version I'm planning to commit tomorrow, if no one objects. Changes:
* txid.c renamed to xid8funcs.c
* remaining traces of "txid" replaced various intern
Dean Rasheed writes:
> Yeah, that makes sense. I still can't see what might be causing those
> failures. The tests that were doing an ALTER COLUMN and then expecting
> to see the results of a non-analysed table ought to be fixed by
> 0936d1b6f, but that doesn't match the buildfarm failures. Possib
Hi Tomas and Ashutosh,
On Thu, Apr 2, 2020 at 1:51 AM Ashutosh Bapat
wrote:
> On Thu, 26 Mar 2020 at 05:47, Tomas Vondra
> wrote:
>> three more comments after eye-balling the code for a bit longer.
>>
>> 1) The patch probably needs to tweak config.sgml which says this about
>> the enable_parti
On Wed, Apr 1, 2020 at 7:52 PM Amit Kapila wrote:
> Peter, Is this behavior expected?
>
> Let me summarize the situation so that it would be easier for Peter to
> comment. Julien has noticed that parallel vacuum and parallel create
> index doesn't seem to report correct values for buffer usage st
Adding Peter G.
On Wed, Apr 1, 2020 at 12:41 PM Dilip Kumar wrote:
>
> I have done some testing for the parallel "create index".
>
> postgres[99536]=# show maintenance_work_mem ;
> maintenance_work_mem
> --
> 1MB
> (1 row)
>
> CREATE TABLE test (a int, b int);
> INSERT INTO
On Wed, Apr 01, 2020 at 10:09:20PM -0400, James Coleman wrote:
On Wed, Apr 1, 2020 at 5:42 PM Tomas Vondra
wrote:
...
I've realized the way get_useful_pathkeys_for_relation() is coded kinda
works against the fastpath we added when comparing pathkeys. That
depends on comparing pointers to the li
On 2020/04/01 18:19, Fujii Masao wrote:
On 2020/04/01 3:42, Julien Rouhaud wrote:
On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote:
On 2020/03/31 16:33, Julien Rouhaud wrote:
v12 attached!
Thanks for updating the patch! The patch looks good to me.
I applied minor and cosm
Hi,
Thank you for developing great features.
The attached patch is a small fix to the committed documentation for the data
type name of blks_hit column.
Best regards,
Noriyoshi Shinoda
-Original Message-
From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
Sent: Thursday, April 2,
Hi,
On 2020-04-01 17:54:06 -0700, Andres Freund wrote:
> * Check whether the given snapshot is too old to have safely read the given
> * page from the given table. If so, throw a "snapshot too old" error.
> *
> * This test generally needs to be performed after every BufferGetPage() call
> *
>So I'd like to propose the attached patch. The patch changes the message
>logged when a promotion is requested, based on whether the recovery is
>in paused state or not.
It is a compromise, we should notice it in document I think.
Regards,
Highgo Software (Canada/China/Pakistan)
URL : www.hi
On 2020-Apr-01, Justin Pryzby wrote:
> planner/optimizer: ...
I propose we define "planner" and make "optimizer" a entry.
I further propose not to define the term "normalized", at least not for
now. That seems a very deep rabbit hole.
--
Álvaro Herrerahttps://www.2ndQuadrant.
Thanks for updating the patch.
On Thu, Apr 02, 2020 at 01:29:04AM +0100, Alexey Bashtanov wrote:
> +If greater than zero, bind parameter values reported in non-error
> +statement-logging messages are trimmed to no more than this many
> bytes.
> +If this value is specified
On Tue, Mar 31, 2020 at 03:26:02PM -0400, Corey Huinker wrote:
> Just so I can prioritize my work, which of these things, along with your
> suggestions in previous emails, would you say is a barrier to considering
> this ready for a committer?
To answer your off-list inquiry, I'm not likely to mar
On Wed, Apr 1, 2020 at 5:54 PM Andres Freund wrote:
> As far as I can tell there's not sufficient in-tree explanation of when
> code needs to test for an old snapshot. There's just the following
> comment above TestForOldSnapshot():
> * Check whether the given snapshot is too old to have safely r
Hi,
On 2020-04-01 16:59:51 -0700, Andres Freund wrote:
> The primary issue here is that there is no TestForOldSnapshot() in
> heap_hot_search_buffer(). Therefore index fetches will never even try to
> detect that tuples it needs actually have already been pruned away.
bitmap heap scan doesn't hav
Hi,
I've pushed this after some minor cleanup and improvements.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/1/20 6:29 PM, Tom Lane wrote:
> I'd modify my first proposal so far as to make it
>
> \g ( pset-option pset-value ... ) filename-or-pipe
>
> That is, require spaces around the parens
I think requiring spaces inside the parentheses is a severe POLA
violation and I vote strongly against
Hi,
The privilege argument seems irrelevant to me. We already decided
that the plan is (a) SUSET for non-error statement logging purposes and
(b) USERSET for logging caused by errors, and that would have to apply
to length limits as well as enable/disable ability. Otherwise a user
could pretty
On Wed, Apr 1, 2020 at 4:59 PM Andres Freund wrote:
> Thanks, that's super helpful.
Glad I could help.
> I got a bit confused here - you seemed to have switched session 1 and 2
> around? Doesn't seem to matter much though, I was able to reproduce this.
Yeah, I switched the session numbers becau
Hi Fabien,
Should we consider the case "\ ", i.e. one or more spaces after the backslash?
For example, if I replace a user map
"mymap /^(.*)@mydomain\.com$ \1" with
"mymap /^(.*)@mydomain\.com$ \ "
"\1"
by adding one extra space after the backslash, then I got the pg_role="\\"
but I
Hi,
On 2020-04-01 16:59:51 -0700, Andres Freund wrote:
> The primary issue here is that there is no TestForOldSnapshot() in
> heap_hot_search_buffer(). Therefore index fetches will never even try to
> detect that tuples it needs actually have already been pruned away.
FWIW, with autovacuum=off th
On 2020-Apr-01, Jürgen Purtz wrote:
>
> On 31.03.20 19:58, Justin Pryzby wrote:
> > On Tue, Mar 31, 2020 at 04:13:00PM +0200, Jürgen Purtz wrote:
> > > Please find some minor suggestions in the attachment. They are based on
> > > Corey's last patch 0001-glossary-v4.patch.
> > > @@ -220,7 +220,7 @
Hi,
On 2020-04-01 15:30:39 -0700, Peter Geoghegan wrote:
> On Wed, Apr 1, 2020 at 3:00 PM Peter Geoghegan wrote:
> > I like that idea. I think that I've spotted what may be an independent
> > bug, but I have to wait around for a minute or two to reproduce it
> > each time. Makes it hard to get to
Alvaro Herrera writes:
> On 2020-Apr-01, Tom Lane wrote:
>> The fact that I had to use max(age(...)) in that sample query
>> hints at one reason: it's really hard to do arithmetic correctly
>> on raw XIDs. Dealing with wraparound is a problem, and knowing
>> what's past or future is even harder.
Nikita Glukhov writes:
> [ latest version of ltree syntax extension ]
This is going to need another rebase after all the other ltree hacking
that just got done. However, I did include 0001 (use a switch) in
the commit I just pushed, so you don't need to worry about that.
Hi,
On 2020-04-01 14:11:11 -0700, Andres Freund wrote:
> As far as I can tell, with a large old_snapshot_threshold, it can take a
> very long time to get to a head_timestamp that's old enough for
> TransactionIdLimitedForOldSnapshots() to do anything. Look at this
> trace of a pgbench run with ol
On Wed, Apr 1, 2020 at 5:58 PM Alvaro Herrera wrote:
>
> On 2020-Apr-01, Tom Lane wrote:
>
> > James Coleman writes:
> > > To my knowledge the current oldest xmin (GetOldestXmin() if I'm not
> > > mistaken) isn't exposed directly in any view or function by Postgres.
> >
> > You could do something
On Wed, Apr 1, 2020 at 3:00 PM Peter Geoghegan wrote:
> I like that idea. I think that I've spotted what may be an independent
> bug, but I have to wait around for a minute or two to reproduce it
> each time. Makes it hard to get to a minimal test case.
I now have simple steps to reproduce a bug
On Wed, Apr 1, 2020 at 1:25 PM Robert Haas wrote:
> Maybe that contrib module could even have some functions to simulate
> aging without the passage of any real time. Like, say you have a
> function or procedure old_snapshot_pretend_time_has_passed(integer),
> and it moves oldSnapshotControl->head
On 2020-Apr-01, Tom Lane wrote:
> James Coleman writes:
> > To my knowledge the current oldest xmin (GetOldestXmin() if I'm not
> > mistaken) isn't exposed directly in any view or function by Postgres.
>
> You could do something like
>
> select max(age(backend_xmin)) from pg_stat_activity;
>
>
Hi Tom,
Thanks a lot for pushing this through.
In complete agreement on fixing mbstrlen, it would clearly have lead to cut
off string sends, or worse (does the binary protocol use null terminated
strings, or are they length prefixed?). Apologies anyways, it's been a
while so I don't know how it m
James Coleman writes:
> To my knowledge the current oldest xmin (GetOldestXmin() if I'm not
> mistaken) isn't exposed directly in any view or function by Postgres.
You could do something like
select max(age(backend_xmin)) from pg_stat_activity;
though I'm not sure whether that accounts for abso
On Wed, Apr 01, 2020 at 09:05:27AM -0400, James Coleman wrote:
On Tue, Mar 31, 2020 at 11:07 PM James Coleman wrote:
On Tue, Mar 31, 2020 at 10:44 PM Tomas Vondra
wrote:
>
> On Tue, Mar 31, 2020 at 10:12:29PM -0400, James Coleman wrote:
> >On Tue, Mar 31, 2020 at 9:59 PM Tomas Vondra
> > wrot
I wrote:
> Fortunately for the odds of getting this patch accepted, we just
> pushed an ALTER TYPE improvement that will solve your problem [1].
> Please replace ltree--1.2.sql with an upgrade script that uses
> that, and resubmit.
I decided it would be a shame for this to miss v13, seeing that
(a
On 3/31/20 7:57 AM, Robert Haas wrote:
On Mon, Mar 30, 2020 at 7:24 PM David Steele wrote:
I'm confused as to why you're not seeing that. What's the exact
sequence of steps?
$ pg_basebackup -D test/backup5 --manifest-checksums=SHA256
$ vi test/backup5/backup_manifest
* Add 'X' to the c
Currently there's no good way that I'm aware of for monitoring
software to check what the xmin horizon is being blocked at. You can
check pg_stat_replication and pg_replication_slots and
txid_snapshot_xmin(txid_current_snapshot()) and so on, but that list
can grow, and it means monitoring setups ne
Hi,
On 2020-04-01 15:11:52 -0500, Kevin Grittner wrote:
> On Wed, Apr 1, 2020 at 2:43 PM Andres Freund wrote:
>
> > The thing that makes me really worried is that the contents of the time
> > mapping seem very wrong. I've reproduced query results in a REPEATABLE
> > READ transaction changing (pru
Hi,
On 2020-03-31 14:56:07 +0530, Amit Kapila wrote:
> On Tue, Mar 31, 2020 at 11:10 AM Noah Misch wrote:
> > On Mon, Mar 30, 2020 at 12:16:31PM -0700, Andres Freund wrote:
> > > On 2020-03-30 15:04:55 -0400, Robert Haas wrote:
> > > I'm mildly inclined to name it pg_validate, pg_validate_dbdir o
Hi,
On 2020-03-31 22:15:04 -0700, Noah Misch wrote:
> On Tue, Mar 31, 2020 at 03:50:34PM -0700, Andres Freund wrote:
> > On 2020-03-31 14:10:34 -0400, Robert Haas wrote:
> > > +/*
> > > + * Attempt to parse the WAL files required to restore from backup using
> > > + * pg_waldump.
> > > + */
> > >
On Wed, Apr 1, 2020 at 3:43 PM Andres Freund wrote:
> The thing that makes me really worried is that the contents of the time
> mapping seem very wrong. I've reproduced query results in a REPEATABLE
> READ transaction changing (pruned without triggering an error). And I've
> reproduced rows not ge
On Wed, Apr 1, 2020 at 2:43 PM Andres Freund wrote:
> The thing that makes me really worried is that the contents of the time
> mapping seem very wrong. I've reproduced query results in a REPEATABLE
> READ transaction changing (pruned without triggering an error).
That is a very big problem. O
Hi,
Nice to have you back for a bit! Even if the circumstances aren't
great...
It's very understandable that the lists are past your limits, I barely
keep up these days. Without any health issues.
On 2020-04-01 14:10:09 -0500, Kevin Grittner wrote:
> Perhaps the lack of evidence for usage in th
On 2020-Apr-01, Andres Freund wrote:
> On 2020-04-01 07:54:45 +0530, Amit Kapila wrote:
> > Pushed. I think we are done here. The patch is marked as committed in
> > CF. Thank you!
>
> Awesome! Thanks for all your work on this, all. This'll make it a lot
> easier to debug errors during autovacu
On 2020-04-01 07:54:45 +0530, Amit Kapila wrote:
> Pushed. I think we are done here. The patch is marked as committed in
> CF. Thank you!
Awesome! Thanks for all your work on this, all. This'll make it a lot
easier to debug errors during autovacuum.
On Wed, Apr 1, 2020 at 10:09 AM Andres Freund wrote:
First off, many thanks to Andres for investigating this, and apologies for
the bugs. Also thanks to Michael for making sure I saw the thread. I must
also apologize that for not being able to track the community lists
consistently due to healt
On Wed, Apr 1, 2020 at 2:37 PM Andres Freund wrote:
> Just continuing is easier said than done. Especially with the background
> of knowing that several users had hit the bug that allowed all of the
> above to be hit, and that advancing relfrozenxid further would make it
> worse.
Fair point, but
On Tue, Mar 31, 2020 at 4:05 PM John Naylor wrote:
>
> On Tue, Mar 31, 2020 at 2:31 AM Andres Freund wrote:
> > I think the form of lea generated here is among the ones that can only
> > be executed on port 1. Whereas e.g. an register+register/immediate add
> > can be executed on four different p
Guancheng Luo writes:
> On Mar 26, 2020, at 01:00, Tom Lane wrote:
>> This would reject, for example, a hash index associated with a btree-based
>> partition constraint, but I'm not sure we're losing anything much thereby.
> There is cases when a BTREE index associated with a HASH partition key,
On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote:
>
>
> On 2020/03/31 10:31, Justin Pryzby wrote:
> > On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud wrote:
> >> Rebase due to conflict with 3ec20c7091e97.
> >
> > This is failing to apply probably since
> > 4a539a25ebfc48329fd656a95f3c1eb
Hi,
On 2020-04-01 13:27:56 -0400, Robert Haas wrote:
> Perhaps "irresponsible" is the wrong word, but it's certainly caused
> problems for multiple EnterpriseDB customers, and in my view, those
> problems weren't necessary. Either a WARNING or an ERROR would have
> shown up in the log, but an ERRO
Hi,
On 2020-04-01 11:04:43 -0700, Peter Geoghegan wrote:
> On Wed, Apr 1, 2020 at 10:28 AM Robert Haas wrote:
> > Is there any chance that you're planning to look into the details?
> > That would certainly be welcome from my perspective.
+1
This definitely needs more eyes. I am not even close t
On 2020-Apr-01, Pavel Stehule wrote:
> It can work, but it is not user friendly - my proposal was motivated by
> using some quick csv exports to gplot's pipe.
Can we fix that by adding some syntax to allow command aliases?
So you could add to your .psqlrc something like
\alias \gcsv \pset push a
On Wed, Apr 1, 2020 at 10:28 AM Robert Haas wrote:
> Sure, but not all levels of risk are equal. Jumping out of a plane
> carries some risk of death whether or not you have a parachute, but
> that does not mean that we shouldn't worry about whether you have one
> or not before you jump.
>
> In thi
Hi,
On 2020-04-01 12:02:18 -0400, Robert Haas wrote:
> On Wed, Apr 1, 2020 at 11:09 AM Andres Freund wrote:
> > There's really no reason at all to have bins of one minute. As it's a
> > PGC_POSTMASTER GUC, it should just have didided time into bins of
> > (old_snapshot_threshold * USEC_PER_SEC) /
On 2020/03/31 10:31, Justin Pryzby wrote:
On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud wrote:
Rebase due to conflict with 3ec20c7091e97.
This is failing to apply probably since
4a539a25ebfc48329fd656a95f3c1eb2cda38af3.
Could you rebase? (Also, not sure if this can be set as RF
On Wed, Apr 1, 2020 at 1:03 PM Peter Geoghegan wrote:
> I don't think that it's fair to characterize Andres' actions in that
> situation as in any way irresponsible. We had an extremely complicated
> data corruption bug that he went to great lengths to fix, following
> two other incorrect fixes. H
On Thu, 26 Mar 2020 at 00:35, Tomas Vondra
wrote:
> Hi,
>
> I've started reviewing the patch a couple days ago. I haven't done any
> extensive testing, but I do have a bunch of initial comments that I can
> share now.
>
> 1) I wonder if this needs to update src/backend/optimizer/README, which
> d
On Wed, Apr 1, 2020 at 9:02 AM Robert Haas wrote:
> I complained
> when you added those error checks to vacuum in back-branches, and
> since that release went out people are regularly tripping those checks
> and taking prolonged outages for a problem that wasn't making them
> unhappy before. I kno
Pavel Stehule writes:
> It can work, but it is not user friendly - my proposal was motivated by
> using some quick csv exports to gplot's pipe.
I kind of liked the stack idea, myself. It's simpler than what I was
suggesting and it covers probably 90% of the use-case.
However, if we prefer somet
Hi,
On 2020-03-31 21:53:04 -0700, Andres Freund wrote:
> I am trying to change the snapshot too old infrastructure so it
> cooperates with my snapshot scalability patch. While trying to
> understand the code sufficiently, I think I found a fairly serious
> issue:
I accidentally sent this email, I
"movead...@highgo.ca" writes:
> [ long_bytea_string_bug_fix_ver5.patch ]
I don't think this has really solved the overflow hazards. For example,
in binary_encode we've got
resultlen = enc->encode_len(VARDATA_ANY(data), datalen);
result = palloc(VARHDRSZ + resultlen);
and all yo
st 1. 4. 2020 v 17:52 odesílatel Daniel Verite
napsal:
> Tom Lane wrote:
>
> > I could see having a command to copy the current primary formatting
> > parameters to the alternate area, too.
>
> We could have a stack to store parameters before temporary
> changes, for instance if you want
Hi Fabien,
On 2/1/20 5:12 AM, Fabien COELHO wrote:
Attached is an attempt at improving things. I have added a explicit note
and hijacked an existing example to better illustrate the purpose of the
function.
This patch does not build on Linux due to some unused functions and
variables: http
On Wed, Apr 1, 2020 at 11:09 AM Andres Freund wrote:
> That doesn't exist in all the back branches. Think it'd be easier to add
> code to explicitly prune it during MaintainOldSnapshotTimeMapping().
That's reasonable.
> There's really no reason at all to have bins of one minute. As it's a
> PGC_
On Wed, 1 Apr 2020 at 11:52, Daniel Verite wrote:
> Tom Lane wrote:
>
> > I could see having a command to copy the current primary formatting
> > parameters to the alternate area, too.
>
> We could have a stack to store parameters before temporary
> changes, for instance if you want to d
Tom Lane wrote:
> I could see having a command to copy the current primary formatting
> parameters to the alternate area, too.
We could have a stack to store parameters before temporary
changes, for instance if you want to do one csv export and
come back to normal without assuming what "
1 - 100 of 151 matches
Mail list logo
