The function GetSubscriptionRelations was declaring ScanKeyData
skey[2]; but actually
only uses 1 scan key. It seems like the code was cut/paste from other
nearby functions
which really are using 2 keys.
PSA a trivial patch to declare the correct number of keys for this function.
--
Kind Rega
On Mon, May 10, 2021 at 06:36:19AM +, tanghy.f...@fujitsu.com wrote:
> On Monday, May 10, 2021 2:48 PM, Julien Rouhaud worte
> >I think the behavior now is correct. The goal of autocompletion is to save
> >keystrokes and time. As the only valid keyword after a DELETE (at least in a
> >Delet
On Mon, May 10, 2021 at 6:59 PM Fabien COELHO wrote:
> > Is gdb installed, and are core files being dumped by that SIGABRT, and
> > are they using the default name (/proc/sys/kernel/core_pattern = core),
> > which the BF can find with the value it's using, namely 'core_file_glob'
> > => 'core*'?
>
On Mon, May 10, 2021 at 12:36 PM Peter Smith wrote:
>
> The function GetSubscriptionRelations was declaring ScanKeyData
> skey[2]; but actually
> only uses 1 scan key. It seems like the code was cut/paste from other
> nearby functions
> which really are using 2 keys.
>
> PSA a trivial patch to dec
On Wed, Mar 31, 2021 at 12:47 PM Euler Taveira wrote:
>
> Good question. IIRC the issue is that AlterPublicationStmt->tables has a list
> element that was a relation_expr_list and was converted to
> publication_table_list. If we share 'tables' with relation_expr_list (for
> ALTER
> PUBLICAT
On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
>
> https://momjian.us/pgsql_docs/release-14.html
Thank you!
> Add system view pg_stat_replication_slots to report re
At Fri, 7 May 2021 15:16:03 +0530, Dilip Kumar wrote in
> Okay, I got your point, now, consider the scenario that we are trying
> to get the checkpoint record in XLogFileReadAnyTLI, you are right that
> it returns history file 0002.history. I think I did not mention
> one point, basically, t
On Mon, May 10, 2021 at 12:00 PM Tom Lane wrote:
>
> Fujii Masao writes:
> > +1 for the change of the error messages.
>
> Yeah, this error message seems outright buggy. However, it's a minor
> matter. Also, some people think "positive" is the same thing as
> "non-negative", so maybe we need les
On Mon, 10 May 2021 at 18:03, Bruce Momjian wrote:
> I need clarification on many items, and the document still needs its
> items properly ordered, and markup added. I also expect a lot of
> feedback.
Thanks for drafting that up.
> Add executor method to cache results from the inner-side of joi
On Mon, May 10, 2021 at 01:39:31PM +0530, Bharath Rupireddy wrote:
> On Mon, May 10, 2021 at 12:36 PM Peter Smith wrote:
> >
> > The function GetSubscriptionRelations was declaring ScanKeyData
> > skey[2]; but actually
> > only uses 1 scan key. It seems like the code was cut/paste from other
> > n
On Mon, May 10, 2021 at 2:05 PM Kyotaro Horiguchi
wrote:
> I thought that the reason using receiveTLI instead of
> recoveryTargetTLI here is that there's a case where receiveTLI is the
> future of recoveryTarrgetTLI but I haven't successfully had such a
> situation. If I set recovoryTargetTLI to
On Mon, May 10, 2021 at 6:09 PM Bharath Rupireddy
wrote:
>
> On Mon, May 10, 2021 at 12:36 PM Peter Smith wrote:
> >
> > The function GetSubscriptionRelations was declaring ScanKeyData
> > skey[2]; but actually
> > only uses 1 scan key. It seems like the code was cut/paste from other
> > nearby f
Hi,
During debugging I noticed some code in ExecResult() where a WHILE
loop is being used with an unconditional RETURN at the end of the
block (which is intentional, looking at the history of changes), but
now there's no actual use of the loop in any way. The code should
probably be changed to jus
On Mon, May 10, 2021 at 07:09:29PM +1000, Peter Smith wrote:
> On Mon, May 10, 2021 at 6:09 PM Bharath Rupireddy
> wrote:
> >
> > On Mon, May 10, 2021 at 12:36 PM Peter Smith wrote:
> > >
> > > The function GetSubscriptionRelations was declaring ScanKeyData
> > > skey[2]; but actually
> > > only
If you don't care about Ubuntu "apport" on this system (something for
sending crash/bug reports to developers with a GUI), you could
uninstall it (otherwise it overwrites the core_pattern every time it
restarts, no matter what you write in your sysctl.conf, apparently),
and then sudo sysctl -w
On Mon, May 10, 2021 at 2:46 PM Julien Rouhaud wrote:
>
> On Mon, May 10, 2021 at 07:09:29PM +1000, Peter Smith wrote:
> > On Mon, May 10, 2021 at 6:09 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Mon, May 10, 2021 at 12:36 PM Peter Smith
> > > wrote:
> > > >
> > > > The function GetSubscript
On 07.05.21 20:31, Andrew Dunstan wrote:
On 5/7/21 1:20 PM, Andres Freund wrote:
On 2021-05-07 11:19:02 -0400, Andrew Dunstan wrote:
Here's a patch that adds the README and also adds a Makefile recipe for
regenerating Gen_dummy_probes.pl after the sed script is changed. On my
system at least th
Hi,
The file path mentioned in the file comments of
'src/backend/utils/activity/backend_status.c'
was incorrect. Modified it to the correct path. Please find the patch
attached.
Thanks & Regards,
Nitin Jadhav
v1_0001-fix_file_path_in_comments.patch
Description: Binary data
On Thu, Apr 22, 2021 at 1:11 PM wenjing wrote:
>
I have briefly looked into the design comments added by the patch. I
have a few questions.
+Feature description
+
+
+Previously, temporary tables are defined once and automatically
+created (starting with empty con
On Mon, May 10, 2021 at 9:30 PM Fabien COELHO wrote:
> I forced-removed apport (which meant removing xserver-xorg). Let's see
> whether the reports are better or whether I break something.
And of course this time it succeeded :-)
Just by the way, I noticed it takes ~40 minutes to compile. Is th
Peter Eisentraut writes:
> On 07.05.21 20:31, Andrew Dunstan wrote:
>> On 5/7/21 1:20 PM, Andres Freund wrote:
>>> On 2021-05-07 11:19:02 -0400, Andrew Dunstan wrote:
Here's a patch that adds the README and also adds a Makefile recipe for
regenerating Gen_dummy_probes.pl after the sed s
And of course this time it succeeded :-)
Hmmm. ISTM that failures are on and off every few attempts.
Just by the way, I noticed it takes ~40 minutes to compile. Is there
a reason you don't install ccache and set eg CC="ccache
/path/to/clang", CXX="ccache /path/to/clang++", CLANG="ccache
/p
On Mon, 10 May 2021 at 08:03, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
> https://momjian.us/pgsql_docs/release-14.html
>
> I need clarification on many items, and the document still needs its
Michail Nikolaev wrote:
> Hello, Antonin.
>
> > I'm trying to review the patch, but not sure if I understand this problem,
> > please see my comment below.
>
> Thanks a lot for your attention. It is strongly recommended to look at
> version N3 (1) because it is a much more elegant, easy, and re
On Mon, 10 May 2021 at 21:16, Greg Nancarrow wrote:
> During debugging I noticed some code in ExecResult() where a WHILE
> loop is being used with an unconditional RETURN at the end of the
> block (which is intentional, looking at the history of changes), but
> now there's no actual use of the loo
On 5/10/21 2:03 AM, Bruce Momjian wrote:
I have committed the first draft of the PG 14 release notes. You can
see the most current build of them here:
https://momjian.us/pgsql_docs/release-14.html
I need clarification on many items, and the document still needs its
items properly orde
On 05.05.21 06:20, Craig Ringer wrote:
On Wed, 5 May 2021 at 09:15, Craig Ringer wrote:
warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
1322 |TRACE_POSTGRESQL_LWLOCK_WAIT_START(T_NAME(lock), mode);
|
Fujita-san,
On Sat, May 8, 2021 at 1:21 AM Etsuro Fujita wrote:
> I noticed this while working on the
> EXPLAIN-ANALYZE-for-async-capable-nodes issue:
>
> EXPLAIN (VERBOSE, COSTS OFF)
> DELETE FROM async_pt;
>QUERY PLAN
> ---
On Monday, May 10, 2021 4:15 PM, Julien Rouhaud wrote
>We should change all to DELETE FROM (apart from \help of course), and same for
>INSERT, change to INSERT INTO everywhere it makes sense.
Thanks for the reply. Your advice sounds reasonable to me.
So I tried to change all "DELETE" to "DELETE F
On 5/10/21 7:16 AM, Dagfinn Ilmari Mannsåker wrote:
> Peter Eisentraut writes:
>
>> On 07.05.21 20:31, Andrew Dunstan wrote:
>>> On 5/7/21 1:20 PM, Andres Freund wrote:
On 2021-05-07 11:19:02 -0400, Andrew Dunstan wrote:
> Here's a patch that adds the README and also adds a Makefile rec
Hi,
While working on [1], I got to know that there is a new GUC
debug_invalidate_system_caches_always that has been introduced in v14.
It can be used to switch off cache invalidation in
CLOBBER_CACHE_ALWAYS builds which makes cache sensitive tests stable.
Using this GUC, it is quite possible to ma
Hi
my customer reported an issue related to unsupported TABLESPACE pg_default
for partitioned table:
postgres=# CREATE TABLE IF NOT EXISTS foo2
(
data bytea,
guid character varying(255) COLLATE pg_catalog."default" NOT NULL,
part date NOT NULL,
retention_period
Hi, Bruce!
On Mon, May 10, 2021 at 9:03 AM Bruce Momjian wrote:
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
>
> https://momjian.us/pgsql_docs/release-14.html
>
> I need clarification on many items, and the document st
Hello,
Antonin.
> Sorry, I missed the fact that your example can be executed inside BEGIN - END
> block, in which case minRecoveryPoint won't advance after each command.
No, the block is not executed as a single transaction, all commands
are separated transactions (see below)
> Actually I think
On Mon, May 10, 2021 at 6:00 AM houzj.f...@fujitsu.com
wrote:
>
> > > > > > > > Thanks! The v5 patch looks good to me. Let's see if all
> > > > > > > > agree on the goto duplicate_error approach which could reduce
> > the LOC by ~80.
> > > > > > >
> > > > > > > I think the "goto duplicate_error" a
On Mon, May 10, 2021, at 5:19 AM, Peter Smith wrote:
> AFAIK this is the latest patch available, but FYI it no longer applies
> cleanly on HEAD.
Peter, the last patch is broken since f3b141c4825. I'm still working on it for
the next CF. I already addressed the points suggested by Amit in his last
r
On Mon, May 10, 2021 at 5:57 PM tanghy.f...@fujitsu.com
wrote:
>
> On Monday, May 10, 2021 4:15 PM, Julien Rouhaud wrote
> >We should change all to DELETE FROM (apart from \help of course), and same
> >for
> >INSERT, change to INSERT INTO everywhere it makes sense.
>
> Thanks for the reply. Your
On Sun, May 9, 2021 at 6:54 PM Euler Taveira wrote:
>
> On Sun, May 9, 2021, at 9:37 AM, vignesh C wrote:
>
> For some of the logical replication messages the data type documented
> was not correct, especially for lsn and xid. For lsn actual datatype
> used is uint64 but is documented as int64, si
On Sun, May 9, 2021 at 6:44 PM Peter Smith wrote:
>
> On Sun, May 9, 2021 at 10:38 PM vignesh C wrote:
> >
> > Hi,
> >
> > For some of the logical replication messages the data type documented
> > was not correct, especially for lsn and xid. For lsn actual datatype
> > used is uint64 but is docum
2021年5月10日(月) 15:03 Bruce Momjian :
>
> I have committed the first draft of the PG 14 release notes. You can
> see the most current build of them here:
>
> https://momjian.us/pgsql_docs/release-14.html
>
> I need clarification on many items, and the document still needs its
> items proper
Michail Nikolaev wrote:
> > Sorry, I missed the fact that your example can be executed inside BEGIN -
> > END
> > block, in which case minRecoveryPoint won't advance after each command.
>
> No, the block is not executed as a single transaction, all commands
> are separated transactions (see bel
Thanks for putting it together.
I think these two should be merged:
| Remove containment operators @ and ~ from contrib modules cube, hstore,
intarray, and seg (Justin Pryzby)
| Remove deprecated containment operators for built-in geometry data types
(Justin Pryzby)
| Improve autovacuum's ana
Bharath Rupireddy writes:
> On Mon, May 10, 2021 at 12:00 PM Tom Lane wrote:
>> Yeah, this error message seems outright buggy. However, it's a minor
>> matter. Also, some people think "positive" is the same thing as
>> "non-negative", so maybe we need less ambiguous wording?
> Since value 0 ca
Julien Rouhaud writes:
> On Mon, May 10, 2021 at 07:09:29PM +1000, Peter Smith wrote:
>> Please search PG source code for "ScanData skey[1];" - there are
>> dozens of precedents where other people felt the same as me for
>> declaring single keys.
> AFAICT there are 73 occurences vs 62 of the "Sca
Hi
I tested features of Postgres 14. The extension pg_stat_statements didn't
work to me until I enabled compute_query_id. Is it expected behaviour?
I expected just an empty column query_id and workable extension. This
doesn't look well.
More, it increases the (little bit) complexity of migration
Same as the last couple years, I checked for missing items in the release
notes, running something like this.
git log --cherry-pick --oneline origin/REL_13_STABLE...origin/master
Should any of these be included?
f82de5c46b Do COPY FROM encoding conversion/verification in larger chunks.
9e596b65f
On 27.04.21 18:16, Tom Lane wrote:
That's kind of a lot of complication, and inefficiency, for a corner case
that may never arise in practice. We've ignored the risk for default
expressions, and AFAIR have yet to receive any field complaints about it.
So maybe it's okay to do the same for SQL-st
Hi Pavel,
On Mon, May 10, 2021 at 04:36:16PM +0200, Pavel Stehule wrote:
>
> I tested features of Postgres 14. The extension pg_stat_statements didn't
> work to me until I enabled compute_query_id. Is it expected behaviour?
Yes.
> I expected just an empty column query_id and workable extension.
On Sun, May 9, 2021 at 11:03 PM Bruce Momjian wrote:
> I have committed the first draft of the PG 14 release notes.
This definitely isn't necessary, since the commit in question was a
totally mechanical thing that cleaned up a minor inconsistency:
Initialize work_mem and maintenance_work_mem usi
On Mon, May 10, 2021 at 4:44 AM Matthias van de Meent
wrote:
> I noticed that the improvement in bloat control in the HeapAM that I
> know of (3c3b8a4b, 0ff8bbde) weren't documented here. Although each
> can be considered minor, they together can decrease the bloating
> behaviour of certain worklo
On Mon, May 10, 2021 at 7:00 AM Justin Pryzby wrote:
> | Allow VACUUM VERBOSE to report page deletion counts for each scan of an
> index (Peter Geoghegan)
>
> I think "Allow" is wrong - should just say that VACUUM VERBOSE reports..
It's also not accurate, since the count of deleted pages was alw
Peter Eisentraut writes:
> On 27.04.21 18:16, Tom Lane wrote:
>> That's kind of a lot of complication, and inefficiency, for a corner case
>> that may never arise in practice. We've ignored the risk for default
>> expressions, and AFAIR have yet to receive any field complaints about it.
>> So may
Michail Nikolaev wrote:
> After some correspondence with Peter Geoghegan (1) and his ideas, I
> have reworked the patch a lot and now it is much more simple with even
> better performance (no new WAL or conflict resolution, hot standby
> feedback is unrelated).
My review that started in [1] cont
On Sun, May 9, 2021 at 1:26 AM Amul Sul wrote:
> The state in the control file also gets cleared. Though, after
> clearing in memory the state patch doesn't really do the immediate
> change to the control file, it relies on the next UpdateControlFile()
> to do that.
But when will that happen? If
Andrew Dunstan writes:
> On 5/10/21 7:16 AM, Dagfinn Ilmari Mannsåker wrote:
>> Peter Eisentraut writes:
>>> This recipe doesn't produce a Gen_dummy_probes.pl that matches exactly
>>> the one that is there now. If this is going to be the preferred method,
>>> then we should generate it once so t
On 2021-05-09 19:51:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-05-08 13:13:47 -0400, Tom Lane wrote:
> >> (I wonder why flaviventris and serinus are still using an "experimental"
> >> compiler version that is now behind mainstream.)
>
> > The upgrade script didn't install the n
Andres Freund writes:
> Looks like it did, but turned out to have some unintended side-effects
> :(.
> The snapshot builds are now new:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=flaviventris&dt=2021-05-10%2015%3A43%3A56&stg=configure
> configure:3966: ccache /usr/lib/gcc-snap
On Mon, May 10, 2021 at 08:16:16AM +0200, Laurenz Albe wrote:
> On Mon, 2021-05-10 at 02:03 -0400, Bruce Momjian wrote:
> > When using \e in psql, if the buffer is not modified by the editor, ignore
> > the editor contents and leave the buffer unchanged (Laurenz Albe)
> > The \ef and \ev commands
Hi,
On 2021-05-10 12:14:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Looks like it did, but turned out to have some unintended side-effects
> > :(.
> > The snapshot builds are now new:
> > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=flaviventris&dt=2021-05-10%2015%3A43%
On Mon, May 10, 2021 at 02:51:28PM +0800, Julien Rouhaud wrote:
> On Mon, May 10, 2021 at 02:03:08AM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 14 release notes. You can
> > see the most current build of them here:
> >
> > https://momjian.us/pgsql_docs/release
On Mon, May 10, 2021 at 9:21 PM Robert Haas wrote:
>
> On Sun, May 9, 2021 at 1:26 AM Amul Sul wrote:
> > The state in the control file also gets cleared. Though, after
> > clearing in memory the state patch doesn't really do the immediate
> > change to the control file, it relies on the next Upd
On Mon, May 10, 2021 at 05:28:24PM +0900, Masahiko Sawada wrote:
> On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 14 release notes. You can
> > see the most current build of them here:
> >
> > https://momjian.us/pgsql_docs/release-
On Mon, May 10, 2021 at 7:43 AM Julien Rouhaud wrote:
> On Mon, May 10, 2021 at 04:36:16PM +0200, Pavel Stehule wrote:
> > I expected just an empty column query_id and workable extension. This
> > doesn't look well.
> >
> > More, it increases the (little bit) complexity of migration to Postgres 14
On Mon, May 10, 2021 at 08:52:44PM +1200, David Rowley wrote:
> On Mon, 10 May 2021 at 18:03, Bruce Momjian wrote:
> > I need clarification on many items, and the document still needs its
> > items properly ordered, and markup added. I also expect a lot of
> > feedback.
>
> Thanks for drafting t
po 10. 5. 2021 v 19:03 odesílatel Maciek Sakrejda
napsal:
> On Mon, May 10, 2021 at 7:43 AM Julien Rouhaud wrote:
> > On Mon, May 10, 2021 at 04:36:16PM +0200, Pavel Stehule wrote:
> > > I expected just an empty column query_id and workable extension. This
> > > doesn't look well.
> > >
> > > Mo
On Mon, May 10, 2021 at 01:44:12PM +0200, Matthias van de Meent wrote:
> On Mon, 10 May 2021 at 08:03, Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 14 release notes. You can
> > see the most current build of them here:
> > https://momjian.us/pgsql_docs/release-
On Mon, 2021-05-10 at 12:38 -0400, Bruce Momjian wrote:
> I came up with this release note text:
>
>
>
>
>
> When editing the previous query or a file with psql's \e, ignore the
> contents if the editor exits without saving (Laurenz Albe)
>
>
>
Hi,
On 2021-05-08 15:44:57 -0400, Tom Lane wrote:
> In a nearby thread I bemoaned the fact that the core regression tests
> seem to have gotten significantly slower in the last couple of months,
> at least with CCA enabled: hyrax reports completing them in 12:52:44
> on 18 March, while its most re
On Mon, May 10, 2021 at 07:39:17PM +0200, Laurenz Albe wrote:
> On Mon, 2021-05-10 at 12:38 -0400, Bruce Momjian wrote:
> > I came up with this release note text:
> >
> >
> >
> >
> >
> > When editing the previous query or a file with psql's \e, ignore the
> > contents i
Andres Freund writes:
> On 2021-05-08 15:44:57 -0400, Tom Lane wrote:
>> I was able to complete a bisection using just that test, and
>> got an unexpected result: most of the slowdown appeared at
>> ab596105b (BRIN minmax-multi indexes). Apparently the additional
>> time is simply from having to
On 2021-May-10, Peter Smith wrote:
> PSA v5 of the patch. It is the same as v4 but with the v4-0001 part
> omitted because that was already pushed.
I made a few whitespace adjustments on Friday that I didn't get time to
push, so I left the whole set to after the minors are finalized this
week. I
Hi,
On 2021-05-10 14:06:16 -0400, Tom Lane wrote:
> Hm. But constantly flushing the caches should mean that they're never
> populated with very many entries at one time, which ought to forestall
> that, at least to some extent.
That's probably true...
> I wonder if there's anything we could do
The test program libpq_pipeline produced by the test suite in
src/test/modules/libpq_pipeline/ is installed into tmp_install as part
of make check. This isn't a real problem by itself, but I think it
creates a bit of an asymmetric situation that might be worth cleaning up.
Before, the content
David Rowley writes:
> On Mon, 10 May 2021 at 18:04, Tom Lane wrote:
>> real293m31.054s
>> to
>> real1m47.807s
>> Yes, really.
> That's quite impressive.
> I've very much in favour of this change. Making it more realistic to
> run the regression tests on a CLOBBER_CACHE_ALWAYS builds be
Andres Freund writes:
> On 2021-05-10 14:06:16 -0400, Tom Lane wrote:
>> I wonder if there's anything we could do to make ResetCatalogCache
>> faster? It wouldn't help much for normal execution of course,
>> but it might do something to bring CCA testing time down out of
>> the stratosphere.
> W
Hi Bruce,
Thanks for doing this work again!
> Add date_bin function (John Naylor)
>
> WHAT DOES THIS DO?
Hard to describe in a one-liner, but it lines up timestamps into regular
intervals as specified by the user. It is more clear after seeing examples:
https://www.postgresql.org/docs/devel/fun
Andres Freund writes:
> On 2021-05-10 14:06:16 -0400, Tom Lane wrote:
>> I wonder if there's anything we could do to make ResetCatalogCache
>> faster? It wouldn't help much for normal execution of course,
>> but it might do something to bring CCA testing time down out of
>> the stratosphere.
> W
On Mon, 10 May 2021 at 19:34, Bruce Momjian wrote:
>
> On Mon, May 10, 2021 at 01:44:12PM +0200, Matthias van de Meent wrote:
> > On Mon, 10 May 2021 at 08:03, Bruce Momjian wrote:
> > >
> > > I have committed the first draft of the PG 14 release notes. You can
> > > see the most current build
Hi,
On 2021-05-10 16:17:18 -0400, Tom Lane wrote:
> I noticed that we already have counters that can tell whether a
> catcache or dynahash table is empty, so I experimented with the
> attached patch. Testing one of the slow queries from privileges.sql
> (which might not be very representative of
On 2021-May-10, vignesh C wrote:
> That sounds fine to me, Attached v6 patch which has the changes for the same.
What about defining a function (maybe a static inline function in
defrem.h) that is marked noreturn and receives the DefElem and
optionally pstate, and throws the error? I think that
On Tue, May 11, 2021 at 8:52 AM Andres Freund wrote:
> ... If we did make the check support shared memory *and*
> partitioned tables, I could easily see it be a win for things like
> LockReleaseAll().
For that case, has the idea of maintaining a dlist of local locks been
considered?
On Mon, May 10, 2021 at 07:54:24AM -0700, Peter Geoghegan wrote:
> On Mon, May 10, 2021 at 4:44 AM Matthias van de Meent
> wrote:
> > I noticed that the improvement in bloat control in the HeapAM that I
> > know of (3c3b8a4b, 0ff8bbde) weren't documented here. Although each
> > can be considered m
On Mon, May 10, 2021 at 3:58 PM Bruce Momjian wrote:
> OK, you are confirming what Matthias suggested. I added these two
> items, which both seem to apply only to heap pages, not index pages:
That's right -- these two relate to heap pages only.
I think that Matthias compared these two to bottom
Hi,
On 2021-05-11 10:57:03 +1200, Thomas Munro wrote:
> On Tue, May 11, 2021 at 8:52 AM Andres Freund wrote:
> > ... If we did make the check support shared memory *and*
> > partitioned tables, I could easily see it be a win for things like
> > LockReleaseAll().
Errr, that's not even a shared ha
Hi,
After hearing from a couple of directions about systems spending too
much time scanning the local lock hash table, I wrote the trivial
patch to put them in a linked list, before learning that people have
considered that before, so I should probably go and read some history
on that and find out
Thomas Munro writes:
> However, I noticed in passing that RemoveLocalLock() accesses
> *locallock after removing it from the hash table (in assertion builds
> only). So one question I have is whether it's actually a programming
> rule that you can't do that (at most you can compare the pointer
>
I wrote:
> ... Can we get rid of the unsafe
> access easily?
Oh, shoulda read your second patch first. Looking at that,
I fear it might not be quite that simple, because the
comment on CheckAndSetLockHeld says very clearly
* It is callers responsibility that this function is called after
* ac
On Mon, May 10, 2021 at 11:21 PM Fabien COELHO wrote:
> > And of course this time it succeeded :-)
>
> Hmmm. ISTM that failures are on and off every few attempts.
OK we got the SIGABRT this time, but still no backtrace. If the
kernel's core_pattern is "core", gdb is installed, then considering
t
Thanks for making the updates.
On Tue, 11 May 2021 at 05:07, Bruce Momjian wrote:
>
> On Mon, May 10, 2021 at 08:52:44PM +1200, David Rowley wrote:
> > > Improve the performance of parallel sequential scans (Thomas Munro, David
> > > Rowley)
> >
> > I think it is worth mentioning "I/O" before "p
Hi,
In
https://www.postgresql.org/message-id/20210505010835.umylslxgq4a6rbwg%40alap3.anarazel.de
I commented that we have a number of hacky workarounds to deal with the fact
that walreceiver writes partial WAL pages into reycled segments.
The problem with that practice is that within a page we c
On 2021-05-11 12:16:44 +1200, Thomas Munro wrote:
> OK we got the SIGABRT this time, but still no backtrace. If the
> kernel's core_pattern is "core", gdb is installed, then considering
> that the buildfarm core_file_glob is "core*" and the script version is
> recent (REL_12), then I'm out of idea
Hi Andres,
Reproduce steps.
1, Modify and adjust NUM_SUBTRANS_BUFFERS to 128 from 32 in the file
"src/include/access/subtrans.h" line number 15.
2, configure with enable assert and build it.
3, init a new database cluster.
4, modify postgres.conf and add some parameters as below. As the cor
Hi Andres,
Reproduce steps.
1, Modify and adjust NUM_SUBTRANS_BUFFERS to 128 from 32 in the file
"src/include/access/subtrans.h" line number 15.
2, configure with enable assert and build it.
3, init a new database cluster.
4, modify postgres.conf and add some parameters as below. As the cor
Hi,
On 2021-05-10 20:15:41 -0400, Tom Lane wrote:
> I wrote:
> > ... Can we get rid of the unsafe
> > access easily?
>
> Oh, shoulda read your second patch first. Looking at that,
> I fear it might not be quite that simple, because the
> comment on CheckAndSetLockHeld says very clearly
>
> * It
On Mon, May 10, 2021 at 12:17:19PM +0530, Dilip Kumar wrote:
> Even I was confused about that's the reason I used liblz4_static.lib,
> but I see you have changed to liblz4.lib to make it consistent I
> guess?
That's the name the upstream code is using, yes.
> Patch looks good to me, I can not ver
On Mon, May 10, 2021 at 07:50:14AM -0400, Joe Conway wrote:
> On 5/10/21 2:03 AM, Bruce Momjian wrote:
> > I have committed the first draft of the PG 14 release notes. You can
> > see the most current build of them here:
> >
> > https://momjian.us/pgsql_docs/release-14.html
> >
> > I need c
On Tue, May 11, 2021 at 12:35:28PM +1200, David Rowley wrote:
> Thanks for making the updates.
>
> On Tue, 11 May 2021 at 05:07, Bruce Momjian wrote:
> >
> > On Mon, May 10, 2021 at 08:52:44PM +1200, David Rowley wrote:
> > > > Improve the performance of parallel sequential scans (Thomas Munro,
On Fri, May 7, 2021 at 8:03 AM Amit Kapila wrote:
>
> Thanks for the summarization. I don't find anything that is left
> unaddressed. I think we can wait for a day or two to see if Andres or
> anyone else sees anything that is left unaddressed and then we can
> close the open item.
>
I have close
On Mon, May 10, 2021 at 04:14:56PM -0700, Peter Geoghegan wrote:
> On Mon, May 10, 2021 at 3:58 PM Bruce Momjian wrote:
> > OK, you are confirming what Matthias suggested. I added these two
> > items, which both seem to apply only to heap pages, not index pages:
>
> That's right -- these two rel
Hi,
There are no interrupt checks in the WalReceiverMain() sub-loop for
receiving WAL. There's one above
/* See if we can read data immediately */
len = walrcv_receive(wrconn, &buf, &wait_fd);
but none in the loop below:
1 - 100 of 125 matches
Mail list logo
