On Mon, May 11, 2020 at 02:22:36PM +0900, Michael Paquier wrote:
> Looks right to me, so will fix if there are no objections.
> read_local_xlog_page() uses the replay location when in recovery.
Done this part now.
--
Michael
signature.asc
Description: PGP signature
Hi Robert,
Please see my comments inline below.
On Tue, May 12, 2020 at 12:33 AM Robert Haas wrote:
> Yeah, that needs to be tested. Right now the chunk size is 32kB but it
> might be a good idea to go larger. Another thing is that right now the
> chunk size is tied to the protocol message
On Mon, May 11, 2020 at 11:52 PM Robert Haas wrote:
>
> > Case-3:
> > In copy command, for performing foreign key checks, we take KEY SHARE
> > lock on primary key table rows which inturn will increment the command
> > counter and updates the snapshot. Now, as we share the snapshots at
> > the
On 2020/05/12 12:05, Fujii Masao wrote:
On 2020/05/12 8:03, Michail Nikolaev wrote:
Hello.
There is a recent commit about changes in way read-only commands are
prevented to be executed [1].
It seems like hs_standby_disallowed test is broken now.
So, a simple patch to fix the test is
Hi,
When we run prepared statements, as far as I know, running
EXPLAIN is the only way to know whether executed plans are
generic or custom.
There seems no way to know how many times a prepared
statement was executed as generic and custom.
I think it may be useful to record the number of generic
On Mon, May 11, 2020 at 11:52 PM Robert Haas wrote:
>
> I wonder why you're still looking at this instead of looking at just
> speeding up the current code, especially the line splitting,
>
Because the line splitting is just 1-2% of overall work in common
cases. See the data shared by Vignesh
At Mon, 11 May 2020 20:12:04 -0400, Bruce Momjian wrote in
> On Thu, May 7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> > On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > > - Crash recovery was losing tuples written via COPY TO. This fixes
> > > > > > the bug.
> > >
On 2020/05/12 9:42, Paul Guo wrote:
Hello hackers,
1. StartupXLOG() does fsync on the whole data directory early in the crash
recovery. I'm wondering if we could skip some directories (at least the
pg_log/, table directories) since wal, etc could ensure consistency.
I agree that we can
Bruce Momjian writes:
> On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
>> 'specify' ?
> I like that word if Tom prefers it.
'specify' works for me.
regards, tom lane
On Mon, May 11, 2020 at 11:08:35PM -0400, Chapman Flack wrote:
> On 05/11/20 22:48, Bruce Momjian wrote:
> > On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
> >>> character available
On 05/11/20 22:48, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
>>> character available in the database encoding, even when the database
>>> encoding is
On Tue, May 12, 2020 at 6:11 AM Justin Pryzby wrote:
>
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > 1. We have allowed an (auto)vacuum to display additional information
> > > about heap or index in case of an error in commit b61d161c14 [1].
> > > Now, in general, it might
On 2020/05/12 8:03, Michail Nikolaev wrote:
Hello.
There is a recent commit about changes in way read-only commands are
prevented to be executed [1].
It seems like hs_standby_disallowed test is broken now.
So, a simple patch to fix the test is attached.
Thanks for the report and patch!
On 2020/05/12 9:34, Bruce Momjian wrote:
Could you add "Vinayak Pokale" as a co-author of the following feature since
I sometimes read his old patch to create a patch [1] ?
===
E.1.3.1.6. System Views
- Add system view pg_stat_progress_analyze to report analyze progress
On Mon, May 11, 2020 at 10:23:53PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, are you suggesting a new section because the glossary shouldn't be
> > listed under source code, or because you want the function reformatting
> > added? We just need to understand what the purpose is.
On Tue, May 12, 2020 at 6:36 AM Bruce Momjian wrote:
>
> On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
> > On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > One more observation:
> > >
> > > Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> >
Robert Haas writes:
> On Mon, May 11, 2020 at 4:24 PM Antonin Houska wrote:
>> Could "sysctl kernel.core_pattern" be the problem? I discovered this setting
>> sometime when I also couldn't find the core dump on linux.
> Well, I'm running on macOS and the core files normally show up in
> /cores,
On Mon, May 11, 2020 at 10:07:23PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I like your wording, but the "that encoding" wasn't clear enough for me,
> > so I reworded it to:
>
> > Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
> > character available in the
On Tue, May 12, 2020 at 10:54:52AM +0900, Michael Paquier wrote:
> On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
> > On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
> >> Should e2e02191 be added to the notes? This commit means that we
> >> actually dropped
On Mon, May 11, 2020 at 4:24 PM Antonin Houska wrote:
> Could "sysctl kernel.core_pattern" be the problem? I discovered this setting
> sometime when I also couldn't find the core dump on linux.
Well, I'm running on macOS and the core files normally show up in
/cores, but in this case they
Bruce Momjian writes:
> Well, are you suggesting a new section because the glossary shouldn't be
> listed under source code, or because you want the function reformatting
> added? We just need to understand what the purpose is. We already have
> the glossary listed, since that is new and
On 2020-May-11, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
> > Yes, we had to touch the source code in order to add documentation; but
> > so what? Everything touches the source code, but that doesn't mean it
> > should be listed there. I don't see
Bruce Momjian writes:
> I like your wording, but the "that encoding" wasn't clear enough for me,
> so I reworded it to:
> Allow Unicode escapes, e.g., E'\u', U&'\', to represent any
> character available in the database encoding, even when the database
> encoding is not
At Mon, 11 May 2020 16:33:36 -0400, Alvaro Herrera
wrote in
> Hello
>
> Per discussion in thread [1], I propose the following patch to give
> another adjustment to the xlogreader API. This results in a small but
> not insignificat net reduction of lines of code. What this patch does
> is
On Mon, May 11, 2020 at 07:18:56PM -0400, Bruce Momjian wrote:
> On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
>> Should e2e02191 be added to the notes? This commit means that we
>> actually dropped support for Windows 2000 (finally) at run-time.
>
> Oh, yes. This is much
On Mon, May 11, 2020 at 04:43:11PM +0800, movead...@highgo.ca wrote:
> But I can not fond any code to get 'origin' from commit_ts, just like it is
> producing data which nobody cares about. Can I know what's the purpose
> of the 'origin' in commit_ts? Do you think we should add some support
> to
On Mon, May 11, 2020 at 6:23 PM Bruce Momjian wrote:
> OK, I was able to add some of it cleanly:
>
> This allows efficient btree indexing of low cardinality columns by
> storing duplicate keys only once. Users upgrading with pg_upgrade
> will need to use REINDEX to make
On Tue, May 12, 2020 at 8:51 AM Bruce Momjian wrote:
> On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > I have attached a patch with my suggestions above.
>
> OK, I slightly modified the wording of your first change, patch
> attached.
Thanks. I checked that what you committed
On Mon, May 11, 2020 at 09:15:43PM -0400, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> > On Mon, May 11, 2020 at 5:14 PM Bruce Momjian wrote:
> > > Agreed. How is this?
> > >
> > > This allows efficient btree indexing of low cardinality
On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2020 at 5:14 PM Bruce Momjian wrote:
> > Agreed. How is this?
> >
> > This allows efficient btree indexing of low cardinality columns.
> > Users upgrading with pg_upgrade will need to use REINDEX
On Mon, May 11, 2020 at 07:41:01PM -0500, Justin Pryzby wrote:
> |Allow function call backtraces of errors to be logged (Peter Eisentraut,
> Álvaro Herrera)
> |Server variable backtrace_functions specifies which C functions should
> generate backtraces on error.
>
> I think the details in the
On Mon, May 11, 2020 at 05:09:54PM -0400, Alvaro Herrera wrote:
> On 2020-May-11, Alvaro Herrera wrote:
>
> > Hello
> >
> > > +
> > > +
> > > +
> > > +Add psql commands to report operator classes and operator families
> > > (Sergey Cherkashin, Nikita Glukhov, Alexander Korotkov)
> > > +
> >
>
On Mon, May 11, 2020 at 07:41:55PM -0500, Justin Pryzby wrote:
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > One more observation:
> >
> > Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> > Praliaskouski)
> > This new behavior allows pages to be set as
On Mon, May 11, 2020 at 08:34:56PM -0400, Alvaro Herrera wrote:
> On 2020-May-11, Bruce Momjian wrote:
>
> > We have long discussed how much of the release notes is to reward
> > behavior, and we have settled on having the names on the items, and the
> > Acknowledgments section at the bottom.
>
On Mon, May 11, 2020 at 04:50:50PM -0400, Alvaro Herrera wrote:
> Hello
>
> > +
> > +
> > +
> > +Add psql commands to report operator classes and operator families (Sergey
> > Cherkashin, Nikita Glukhov, Alexander Korotkov)
> > +
>
> I think this item should list the commands in question:
>
Hello hackers,
1. StartupXLOG() does fsync on the whole data directory early in the crash
recovery. I'm wondering if we could skip some directories (at least the
pg_log/, table directories) since wal, etc could ensure consistency. Here
is the related code.
if (ControlFile->state !=
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > 1. We have allowed an (auto)vacuum to display additional information
> > about heap or index in case of an error in commit b61d161c14 [1].
> > Now, in general, it might not be worth saying much about error
> > information but I
|Allow function call backtraces of errors to be logged (Peter Eisentraut,
Álvaro Herrera)
|Server variable backtrace_functions specifies which C functions should
generate backtraces on error.
I think the details in the description are eclipsing the most important thing:
backtraces on Assert().
On 2020-May-11, Bruce Momjian wrote:
> We have long discussed how much of the release notes is to reward
> behavior, and we have settled on having the names on the items, and the
> Acknowledgments section at the bottom.
Yes, we had to touch the source code in order to add documentation; but
so
On Mon, May 11, 2020 at 03:19:50PM +0900, Tatsuro Yamada wrote:
> Hi Bruce,
>
> On 2020/05/05 12:16, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs
On Mon, May 11, 2020 at 5:14 PM Bruce Momjian wrote:
> Agreed. How is this?
>
> This allows efficient btree indexing of low cardinality columns.
> Users upgrading with pg_upgrade will need to use REINDEX to make use
> of
> this feature.
I still think that the release
On Sun, May 10, 2020 at 03:09:47PM -0500, Justin Pryzby wrote:
> > In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}",
> > properly interpret that as "*{5}" (Nikita Glukhov)
>
> I think that should say ".*" not "*", as in:
>
> > In ltree, when using adjacent asterisks with
On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> One more observation:
>
> Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei
> Praliaskouski)
> This new behavior allows pages to be set as all-visible, which then
> allows index-only scans, ...
>
> The above
On Sat, May 9, 2020 at 11:16:27AM +0530, Amit Kapila wrote:
> On Tue, May 5, 2020 at 8:46 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
>
> Thanks for the
On Fri, May 8, 2020 at 09:14:01AM +0200, Fabien COELHO wrote:
> > It seems (a) pointless
>
> I disagree, on the very principle of free software values as a social
> movement.
>
> Documentation improvements should be encouraged, and recognizing these in
> the release notes contributes to do that
On Mon, May 11, 2020 at 05:05:29PM -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2020 at 4:10 PM Bruce Momjian wrote:
> > > think that you should point out that deduplication works by storing
> > > the duplicates in the obvious way: Only storing the key once per
> > > distinct value (or once
Skimming through the code in event_trigger.c and noticed that while most of
the stanzas that reference IsUnderPostmaster refer back to the code comment
beginning on line 675 the block for table rewrite copied it in
verbatim starting at line 842. The currentEventTriggerState comment at
lines 730
On Thu, May 7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > - Crash recovery was losing tuples written via COPY TO. This fixes
> > > > > the bug.
> > > >
> > > > This was not backpatched?
> > >
> > > Right.
> >
> > Oh.
On Mon, May 11, 2020 at 4:10 PM Bruce Momjian wrote:
> > think that you should point out that deduplication works by storing
> > the duplicates in the obvious way: Only storing the key once per
> > distinct value (or once per distinct combination of values in the case
> > of multi-column
On Fri, May 8, 2020 at 12:07:09PM +0900, Amit Langote wrote:
> > OK, I used this wording:
> >
> > Allow logical replication into partitioned tables on subscribers
> > (Amit
> > Langote)
> >
> > Previously, subscribers could only receive rows into non-partitioned
> >
On Fri, May 8, 2020 at 11:55:33AM +0900, Michael Paquier wrote:
> On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
> > It
On Thu, May 7, 2020 at 11:54:12AM -0700, Peter Geoghegan wrote:
> Hi Bruce,
>
> On Mon, May 4, 2020 at 8:16 PM Bruce Momjian wrote:
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
>
> I
Hello.
There is a recent commit about changes in way read-only commands are
prevented to be executed [1].
It seems like hs_standby_disallowed test is broken now.
So, a simple patch to fix the test is attached.
Thanks,
Michail.
[1]
On Thu, May 7, 2020 at 02:08:58PM -0400, Chapman Flack wrote:
> On 05/07/20 09:46, Bruce Momjian wrote:
> > Ah, very good point. New text is:
> >
> > Allow Unicode escapes, e.g., E'\u', in databases that do not
> > use UTF-8 encoding (Tom Lane)
> >
> > The Unicode characters
On Mon, May 11, 2020 at 08:41:00PM +0300, Alexander Korotkov wrote:
> On Mon, May 11, 2020 at 4:20 PM Bruce Momjian wrote:
> > Sorry for the delay in replying. Yes, I agree we should list all of
> > those operator class cases where we now take arguments. I looked at the
> > patch but got
There are a couple of things left to do yet:
* Collapse temporary OID assignments down to the permanent range.
AFAICS there's no reason to delay this step any longer, since there
aren't any open issues that seem likely to touch the catalog data.
* In recent years we've usually done a preliminary
On 2020-May-11, Alvaro Herrera wrote:
> Hello
>
> > +
> > +
> > +
> > +Add psql commands to report operator classes and operator families (Sergey
> > Cherkashin, Nikita Glukhov, Alexander Korotkov)
> > +
>
> I think this item should list the commands in question:
> \dA, \dAc, \dAf, \dAo, \dAp
On 2020-Mar-08, Alexander Korotkov wrote:
> Show opclass and opfamily related information in psql
>
> This commit provides psql commands for listing operator classes, operator
> families and its contents in psql. New commands will be useful for exploring
> capabilities of both builtin
Hello
> +
> +
> +
> +Add psql commands to report operator classes and operator families (Sergey
> Cherkashin, Nikita Glukhov, Alexander Korotkov)
> +
I think this item should list the commands in question:
\dA, \dAc, \dAf, \dAo, \dAp
(All the other psql entries in the relnotes do that).
Thanks
On Mon, May 11, 2020 at 1:24 PM Robert Haas wrote:
> On Fri, May 8, 2020 at 7:32 PM Gurjeet Singh wrote:
> > There's no standard format that comes to mind, but perhaps an output
> format similar to that of (array of row_to_json()) would be desirable. For
> example, `select relname, relnamespace
Hello
Per discussion in thread [1], I propose the following patch to give
another adjustment to the xlogreader API. This results in a small but
not insignificat net reduction of lines of code. What this patch does
is adjust the signature of these new xlogreader callbacks, making the
API
On Mon, May 11, 2020 at 4:22 PM Tom Lane wrote:
> Robert Haas writes:
> > If the parent is RTI 1, and the children are RTIs 2..6, what
> > varno/varattno will we use in RTI 1's tlist to represent a column that
> > exists in both RTI 2 and RTI 3 but not in RTI 1, 4, 5, or 6?
>
> Fair question.
Robert Haas wrote:
> On Sun, May 10, 2020 at 11:21 PM Andy Fan wrote:
> > Looks this doesn't mean a crash. If the test
> > case(subscription/t/013_partition.pl)
> > failed, test framework kill some process, which leads the above message.
> > So you can
> > ignore this issue now. Thanks
>
On Fri, May 8, 2020 at 7:32 PM Gurjeet Singh wrote:
> There's no standard format that comes to mind, but perhaps an output format
> similar to that of (array of row_to_json()) would be desirable. For example,
> `select relname, relnamespace from pg_class;` would emit the following:
>
> [
>
Robert Haas writes:
> If the parent is RTI 1, and the children are RTIs 2..6, what
> varno/varattno will we use in RTI 1's tlist to represent a column that
> exists in both RTI 2 and RTI 3 but not in RTI 1, 4, 5, or 6?
Fair question. We don't have any problem representing the column
as it
On Mon, May 11, 2020 at 4:04 PM Tom Lane wrote:
> This is the wrong thread to be debating that in, though.
True.
> Also I wonder if this is really RMT turf?
I think it is, but the RMT is permitted -- even encouraged -- to
consider the views of non-RMT members when making its decision.
--
Robert Haas writes:
> I agree, but also, we should start thinking about when to branch. I,
> too, have patches that aren't critical enough to justify pushing them
> post-freeze, but which are still good improvements that I'd like to
> get into the tree. I'm queueing them right now to avoid the
On Mon, May 11, 2020 at 4:40 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
> >> Why? It uses "fallthrough" which is a legal spelling per level 4.
>
> > GCC documentation mentions [ \t]*FALLTHR(OUGH|U)[ \t]* for level 4
> > (out of the view
On Fri, May 8, 2020 at 4:58 AM Laurenz Albe wrote:
> I happened to notice that COPY TO releases the ACCESS SHARE lock
> on the table right when the command ends rather than holding it
> until the end of the transaction:
That seems inconsistent with what an INSERT statement would do, and thus
On Sun, May 10, 2020 at 11:21 PM Andy Fan wrote:
> Looks this doesn't mean a crash. If the test
> case(subscription/t/013_partition.pl)
> failed, test framework kill some process, which leads the above message. So
> you can
> ignore this issue now. Thanks
I think there might be a real
On Mon, May 11, 2020 at 12:56 AM Tom Lane wrote:
> > I think we should definitely get this fixed for pg13 ...
>
> -1 for shoving in such a thing so late in the cycle. We've survived
> without it for years, we can do so for a few months more.
I agree, but also, we should start thinking about
On Mon, May 11, 2020 at 2:48 PM Tom Lane wrote:
> > There doesn't seem to be any execution-time
> > problem with such a representation, but there might be a planning-time
> > problem with building it,
>
> Possibly. We manage to cope with not-all-alike children now, of course,
> but I think it
On Fri, May 8, 2020 at 5:27 PM Andres Freund wrote:
> I wonder if there's cases where recursively forwarding like this will
> cause noticable performance effects. The only operation that seems
> frequent enough to potentially be noticable would be "chunks" of the
> file. So perhaps it'd be good
Robert Haas writes:
> I believe that you'd want to have happen here is for each child to
> emit the row identity columns that it knows about, and emit NULL for
> the others. Then when you do the Append you end up with a row format
> that includes all the individual identity columns, but for any
>
On Mon, May 11, 2020 at 8:58 AM Ashutosh Bapat
wrote:
> What happens if there's a mixture of foreign and local partitions or
> mixture of FDWs? Injecting junk columns from all FDWs in the top level
> target list will cause error because those attributes won't be
> available everywhere.
I think
I wonder why you're still looking at this instead of looking at just
speeding up the current code, especially the line splitting, per
previous discussion. And then coming back to study this issue more
after that's done.
On Mon, May 11, 2020 at 8:12 AM Amit Kapila wrote:
> Apart from this, we
On Sun, May 10, 2020 at 10:08:46PM -0400, Jonathan S. Katz wrote:
> * Ensure that a detatched partition has triggers that come from its former
> parent removed.
I would have said: "fix for issue which prevented/precluded detaching
partitions which have inherited ROW triggers"
> * Several fixes
On Mon, May 11, 2020 at 4:20 PM Bruce Momjian wrote:
> Sorry for the delay in replying. Yes, I agree we should list all of
> those operator class cases where we now take arguments. I looked at the
> patch but got confused and missed the doc changes that clearly need to
> be in the release
Hi Antonin, thanks for the review.
On 2020-May-11, Antonin Houska wrote:
> While looking at the changes, I've noticed a small comment issue in the
> XLogReaderRoutine structure definition:
>
> * "tli_p" is an input/output argument. XLogRead() uses it to pass the
>
> The XLogRead()
Hi Ashutosh,
Thanks for chiming in.
On Mon, May 11, 2020 at 9:58 PM Ashutosh Bapat
wrote:
> On Fri, May 8, 2020 at 7:03 PM Amit Langote wrote:
> > I do think that doing this would be worthwhile even if we may be
> > increasing ModifyTable's per-row overhead slightly, because planning
> >
Julien Rouhaud writes:
> On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
>> Why? It uses "fallthrough" which is a legal spelling per level 4.
> GCC documentation mentions [ \t]*FALLTHR(OUGH|U)[ \t]* for level 4
> (out of the view other alternatives), which AFAICT is case sensitive
> (level 3
On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > Note that timezone/zic.c would also have to be changed.
>
> Why? It uses "fallthrough" which is a legal spelling per level 4.
GCC documentation mentions [ \t]*FALLTHR(OUGH|U)[ \t]* for level 4
(out of the view other
Julien Rouhaud writes:
> Note that timezone/zic.c would also have to be changed.
Why? It uses "fallthrough" which is a legal spelling per level 4.
regards, tom lane
On Thu, May 7, 2020 at 08:12:30PM +0300, Alexander Korotkov wrote:
> On Thu, May 7, 2020 at 2:46 AM Bruce Momjian wrote:
> >
> > Allow CREATE INDEX to specify the GiST signature length and maximum
> > number of integer ranges (Nikita Glukhov)
> >
>
> Should we specify
On Fri, May 8, 2020 at 7:03 PM Amit Langote wrote:
>
> Here is a sketch for implementing the design that Tom described here:
> https://www.postgresql.org/message-id/flat/357.1550612935%40sss.pgh.pa.us
>
> In short, we would like to have only one plan for ModifyTable to get
> tuples out of to
On Tue, Apr 28, 2020 at 4:05 AM Peter Geoghegan wrote:
> On Mon, Apr 27, 2020 at 4:17 AM Alexander Korotkov
> wrote:
> > > Assuming it doesn't seem we actually need any items on deleted pages,
> > > I can propose to delete them on primary as well. That would make
> > > contents of primary and
On Mon, May 11, 2020 at 2:07 PM Andrew Dunstan
wrote:
>
>
> On 5/11/20 7:29 AM, Julien Rouhaud wrote:
> > On Mon, May 11, 2020 at 6:47 AM Tom Lane wrote:
> >> Alvaro Herrera writes:
> >>> On 2020-May-06, Alvaro Herrera wrote:
> This doesn't allow whitespace between "fall" and "through",
On Mon, May 11, 2020 at 2:30 PM Alexander Lakhin wrote:
>
> But I can confirm that calling __gcov_flush() in SignalHandlerForCrashExit()
> really improves a code coverage report.
>
> Finally I've managed to get an expected coverage when I performed
> $node_standby->stop() (but __gcov_flush()
On Wed, Apr 15, 2020 at 11:49 PM Andres Freund wrote:
>
> To be clear, I was only thinking of using a ringbuffer to indicate split
> boundaries. And that workers would just pop entries from it before they
> actually process the data (stored outside of the ringbuffer). Since the
> split boundaries
On 5/11/20 7:29 AM, Julien Rouhaud wrote:
> On Mon, May 11, 2020 at 6:47 AM Tom Lane wrote:
>> Alvaro Herrera writes:
>>> On 2020-May-06, Alvaro Herrera wrote:
This doesn't allow whitespace between "fall" and "through", which means
we generate 217 such warnings currently. Or we can
On Mon, May 11, 2020 at 6:47 AM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2020-May-06, Alvaro Herrera wrote:
> >> This doesn't allow whitespace between "fall" and "through", which means
> >> we generate 217 such warnings currently. Or we can just use
> >> -Wimplicit-fallthrough=3, which
> On Mon, May 11, 2020 at 04:04:00PM +0530, Dilip Kumar wrote:
>
> > > +static inline bool
> > > +_bt_scankey_within_page(IndexScanDesc scan, BTScanInsert key,
> > > + Buffer buf, ScanDirection dir)
> > > +{
> > > + OffsetNumber low, high;
> > > + Page page = BufferGetPage(buf);
> > > +
> 8 мая 2020 г., в 21:36, Andrey M. Borodin написал(а):
>
> *** The problem ***
> I'm investigating some cases of reduced database performance due to
> MultiXactOffsetLock contention (80% MultiXactOffsetLock, 20% IO DataFileRead).
> The problem manifested itself during index repack and
On Sun, May 10, 2020 at 11:17 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Apr 11, 2020 at 03:17:25PM +0530, Dilip Kumar wrote:
> >
> > Some more comments...
>
> Thanks for reviewing. Since this patch took much longer than I expected,
> it's useful to have someone to look at it
On Mon, 11 May 2020 at 14:09, Jonathan S. Katz wrote:
> Attached is a draft of the press release for the 2020-05-14 cumulative
> update. Please let me know your feedback by 2020-05-13 :)
Hi,
Thanks for drafting those up.
For:
* Several fixes for GENERATED columns, including an issue where it
Hello Alvaro,
11.05.2020 06:42, Alvaro Herrera wrote:
> (Strangely, I was just thinking about these branches of mine as I
> closed my week last Friday...)
>
> On 2020-May-10, Alexander Lakhin wrote:
>
>> So if we want to make the coverage reports more precise, I see the three
>> ways:
>> 1. Change
Hello hackers,
I am researching about 'origin' in PostgreSQL, mainly it used in logical
decoding to filter transaction from non-local source. I notice that the
'origin' is stored in commit_ts so that I think we are possible to get 'origin'
of a transaction from commit_ts.
But I can not fond any
Alvaro Herrera wrote:
> On 2020-May-08, Kyotaro Horiguchi wrote:
>
> > I agree to the direction of this patch. Thanks for the explanation.
> > The patch looks good to me except the two points below.
>
> Thanks! I pushed the patch.
I tried to follow the discussion but haven't had better idea.
At Fri, 21 Feb 2020 17:05:07 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 20 Feb 2020 14:23:22 +0900, Michael Paquier
> wrote in
> > Removing this code from pg_regress.c makes also sense to me. Now, the
> > patch breaks "vcregress installcheck" as this is missing to patch
> >
On Sun, May 10, 2020 at 07:08:03PM -0300, Euler Taveira wrote:
> I attached a patch with the described solution. I also included a test that
> covers this scenario.
- Assert(RelationGetReplicaIndex(rel) == RelationGetRelid(idxrel));
+ Assert(GetRelationIdentityOrPK(rel) ==
1 - 100 of 105 matches
Mail list logo
