On Tue, May 23, 2023 at 06:37:59PM -0700, Andres Freund wrote:
> This feels more like a matter of taste to me than anything.
Yup, it is.
> At least some of
> the files touched in the patch use optarg, opterr etc. - which are declared in
> pg_getopt.h. Making it reasonable to directly include pg_g
On Mon, Apr 24, 2023 at 07:18:54PM -0500, Justin Pryzby wrote:
> On Thu, Mar 30, 2023 at 12:07:58AM -0500, Justin Pryzby wrote:
>> Actually .. I think it'd be a mistake if the relam needed to be
>> interpretted differently for partitioned tables than other relkinds.
>>
>> I updated the patch to all
On Thu, May 25, 2023 at 5:28 AM Tom Lane wrote:
> I tried this and it seems to work all right: it fixes the example
> you showed while not causing any new failures. (Doesn't address
> the broken join-removal logic you showed in the other thread,
> though.)
>
> While at it, I also changed make_re
On Thu, 25 May 2023 at 05:45, Bruce Momjian wrote:
>
> On Wed, May 24, 2023 at 01:43:50PM -0400, Bruce Momjian wrote:
> > > * Reduce palloc() memory overhead for all memory allocations down to 8
> > > bytes on all platforms. (Andres Freund, David Rowley)
> > >
> > > This allows more efficient use
Hi,
On 2023-05-24 23:30:58 -0400, Jonathan S. Katz wrote:
> > Ah, OK, that's why I didn't grok it. I read through the first message
> > in[1] and definitely agree it should be in the announcement. How about:
> >
> > "PostgreSQL 16 also shows up to a 300% improvement when concurrently
> > loading
On 5/24/23 11:30 PM, Jonathan S. Katz wrote:
On 5/24/23 9:20 PM, Jonathan S. Katz wrote:
I currently have it as the below in the release announcement. If it you
send any suggested updates, I can try to put them in before release:
PostgreSQL 16 can also improve the performance of concurrent b
On 5/24/23 9:20 PM, Jonathan S. Katz wrote:
On 5/24/23 8:04 PM, Andres Freund wrote:
Hi,
On 2023-05-24 19:57:39 -0400, Jonathan S. Katz wrote:
On 5/24/23 5:28 PM, Andres Freund wrote:
I think the relation extension improvements ought to be mentioned
here as
well? Up to 3x faster concurrent
On Thu, May 25, 2023 at 12:34 PM Tom Lane wrote:
> Dunno about antique MIPS. I think there's still some interest in
> not-antique 32-bit MIPS; I have some current-production routers
> with such CPUs. (Sadly, they don't have enough storage to do
> anything useful with, or I'd think about repurpos
On Thu, May 25, 2023 at 08:31:29AM +0700, John Naylor wrote:
>
> On Wed, May 24, 2023 at 8:58 PM Bruce Momjian wrote:
> >
> > Okay, items split into sections and several merged. I left the
> > CPU-specific parts in Source Code, and moved the rest into a merged item
> > in General Performance, bu
On Wed, May 24, 2023 at 8:58 PM Bruce Momjian wrote:
>
> Okay, items split into sections and several merged. I left the
> CPU-specific parts in Source Code, and moved the rest into a merged item
> in General Performance, but moved the JSON item to Data Types.
It looks like it got moved to Functi
Hi,
On 2023-05-24 20:34:38 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, May 25, 2023 at 11:51 AM Tom Lane wrote:
> >> You'll no doubt be glad to hear that I'll be retiring chickadee
> >> in the very near future.
>
> > . o O { I guess chickadee might have been OK anyway, along with e
On 5/24/23 8:04 PM, Andres Freund wrote:
Hi,
On 2023-05-24 19:57:39 -0400, Jonathan S. Katz wrote:
On 5/24/23 5:28 PM, Andres Freund wrote:
I think the relation extension improvements ought to be mentioned here as
well? Up to 3x faster concurrent data load with COPY seems practically
relevant
Andres Freund writes:
> On 2023-05-24 19:51:22 -0400, Tom Lane wrote:
>> So dropping PA-RISC altogether should probably happen for v17, maybe even
>> v16.
> Definitely for 17 - not sure if we have much to gain by doing it in 16.
I'm just thinking that we'll have no way to test it. I wouldn't ad
Hi,
On 2023-05-24 19:51:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> >> Hmm, can we really expect atomic 8-byte reads on "relevant" 32-bit
> >> platforms? I'd be on board with this if so, but it sounds a bit
> >> optimistic.
>
> > ...
>
Thomas Munro writes:
> On Thu, May 25, 2023 at 11:51 AM Tom Lane wrote:
>> You'll no doubt be glad to hear that I'll be retiring chickadee
>> in the very near future.
> . o O { I guess chickadee might have been OK anyway, along with e.g.
> antique low-end SGI MIPS gear etc of "workstation"/"desk
On Wed, May 24, 2023 at 02:12:23PM -0400, Dave Cramer wrote:
> The last piece of information is the encryption state. However when an SSL
> connection fails to authenticate the state is not encrypted.
>
> When would it ever be encrypted if authentication fails ?
I am not sure to follow. Under a S
On Thu, May 25, 2023 at 11:51 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> > So it looks like the only certain problem is PA-RISC - which I personally
> > wouldn't include in "relevant" :), with some evaluation needed for 32bit
> > mips
> > and o
Hi,
On 2023-05-24 19:57:39 -0400, Jonathan S. Katz wrote:
> On 5/24/23 5:28 PM, Andres Freund wrote:
> >
> > I think the relation extension improvements ought to be mentioned here as
> > well? Up to 3x faster concurrent data load with COPY seems practically
> > relevant.
>
> I missed that -- not s
On 5/24/23 5:28 PM, Andres Freund wrote:
I think the relation extension improvements ought to be mentioned here as
well? Up to 3x faster concurrent data load with COPY seems practically
relevant.
I missed that -- not sure I'm finding it in the release notes with a
quick grep -- which commit/t
Andres Freund writes:
> On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
>> Hmm, can we really expect atomic 8-byte reads on "relevant" 32-bit
>> platforms? I'd be on board with this if so, but it sounds a bit
>> optimistic.
> ...
> So it looks like the only certain problem is PA-RISC - which I pe
Hi,
On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Dropping CPUs without native atomic operations / without a way to do
> > tear-free
> > 8 byte reads would make several substantial performance improvements easier,
> > while not really dropping any relevant platform.
>
On Wed, May 24, 2023 at 02:49:58PM -0700, Andres Freund wrote:
> I was a bit confused by Michael's comment as well, due to the section of code
> quoted. But he does have a point: pg_atomic_read_u32() does indeed *not* have
> barrier semantics (it'd be way more expensive), and the patch does contain
Hi Andres,
Thanks for your reply. If I understand you correctly, you're saying that
the walsender *waits* for xlogflush, but does not *cause* it. This means
that for a sync_commit=off transaction, the xlog records won't get shipped
out to standbys until the walwriter flushes in-memory xlog content
On Wed, May 24, 2023 at 10:44:11AM -0400, Tom Lane wrote:
> Hans Buschmann writes:
> > This inspired me to propose dropping 32bit support for PostgreSQL starting
> > with PG17.
>
> I don't think this is a great idea. Even if Intel isn't interested,
> there'll be plenty of 32-bit left in the low
On Wed, May 24, 2023 at 01:03:04PM +0200, Daniel Gustafsson wrote:
> When we moved the goalposts to 1.0.1 (commit 7b283d0e1d1) we referred to RHEL6
> using 1.0.1, and RHEL6 goes out of ELS in late June 2024 seems possible to
> drop
> 1.0.1 support during v17. I haven't studied the patch yet but I
Hi,
On 2023-05-24 08:22:08 -0400, Robert Haas wrote:
> On Tue, May 23, 2023 at 6:26 PM Michael Paquier wrote:
> > Spinlocks provide a full memory barrier, which may not the case with
> > add_u64() or read_u64(). Could memory ordering be a problem in these
> > code paths?
>
> It could be a huge
Andres Freund writes:
> Dropping CPUs without native atomic operations / without a way to do tear-free
> 8 byte reads would make several substantial performance improvements easier,
> while not really dropping any relevant platform.
Hmm, can we really expect atomic 8-byte reads on "relevant" 32-b
Hi,
On 2023-05-24 14:33:06 +, Hans Buschmann wrote:
> I recently stumbled over the following Intel proposal for dropping 32bit
> support in x86 processors. [1]
It's a proposal for something in the future. Which, even if implemented as is,
will affect future hardware, several years down the l
Andres Freund writes:
> First thing I noticed that 'make dist' doesn't work in a vpath, failing in a
> somewhat obscure way (likely because in a vpath build the the copy from the
> source dir doesn't include GNUMakefile). Do we expect it to work?
Don't see how it could possibly be useful in a vpa
Hi,
On 2023-05-24 10:53:51 -0400, Tejasvi Kashi wrote:
> I was wondering if waiting for an LSN in SyncRepWaitForLSN ensures that the
> XLOG has been flushed locally up to that location before the record is
> shipped off to standbys?
No, SyncRepWaitForLSN() doesn't directly ensure that. The caller
I wrote:
> ... Another idea is that maybe we need another
> RestrictInfo field that's directly a set of OJ relids that this clause
> can't be applied above. That'd reduce clause_is_computable_at to
> basically a bms_intersect test which would be nice speed-wise. The
> space consumption could be a
Hi,
On 2023-05-24 13:06:30 -0400, Jonathan S. Katz wrote:
> PostgreSQL 16 Feature Highlights
>
>
> ### Performance
>
> PostgreSQL 16 includes performance improvements in query execution. This
> release
> adds more query parallelism, including allowing `FULL` and
Hi,
On 2023-05-23 14:51:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I guess I need to go and check how long the "release" tarball generation
> > takes...
>
> It's quick except for the documentation-generating steps. Maybe
> we could test that part only once?
First thing I noticed tha
I added documentation for the SQL functions in 001.
And updated to say 17
I'm planning to set this patch as ready - it has not changed
significantly in 18 months. Not for the first time, I've implemented a
workaround at a higher layer.
--
Justin
>From 917e5e36d14018b6de457ba9eafe8936c0e88c3
Hi,
On 2023-05-24 05:53:51 +, Zhijie Hou (Fujitsu) wrote:
> On Tuesday, May 23, 2023 1:53 AM Andres Freund wrote:
> > On 2023-05-22 12:15:07 +, Zhijie Hou (Fujitsu) wrote:
> > > About "a backend doing logical decoding", do you mean the case when a
> > user
> > > start a backend and invoke
Hi,
On 2023-05-24 21:56:22 +0200, Tomas Vondra wrote:
> >> The really hard thing was determining what causes the memory leak - the
> >> simple instrumentation doesn't help with that at all. It tells you there
> >> might be a leak, but you don't know where did the allocations came from.
> >>
> >> W
Hi,
On 2023-05-24 21:49:13 +0200, Tomas Vondra wrote:
> >> and then have to pass updatedCols elsewhere. It's tricky to just switch
> >> to the context (e.g. in ExecASUpdateTriggers/ExecARUpdateTriggers), as
> >> AfterTriggerSaveEvent allocates other bits of memory too (in a longer
> >> lived conte
On 5/24/23 20:14, Andres Freund wrote:
> Hi,
>
> On 2023-05-23 23:26:42 +0200, Tomas Vondra wrote:
>> On 5/23/23 19:14, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2023-05-23 18:23:00 +0200, Tomas Vondra wrote:
This means that for an UPDATE with triggers, we may end up calling this
for each
Hi,
On 2023-05-23 18:23:00 +0200, Tomas Vondra wrote:
> While looking for other places allocating stuff in ExecutorState (for
> the UPDATE case) and leaving it there, I found two more cases:
For a bit I thought there was a similar problem in ExecWithCheckOptions() -
but we error out immediately a
On 5/24/23 20:55, Andres Freund wrote:
> Hi,
>
> On 2023-05-24 15:38:41 +0200, Tomas Vondra wrote:
>> I looked at this again, and I think GetPerTupleMemoryContext(estate)
>> might do the trick, see the 0002 part.
>
> Yea, that seems like the right thing here.
>
>
>> Unfortunately it's not mu
Hi,
On 2023-05-24 15:38:41 +0200, Tomas Vondra wrote:
> I looked at this again, and I think GetPerTupleMemoryContext(estate)
> might do the trick, see the 0002 part.
Yea, that seems like the right thing here.
> Unfortunately it's not much
> smaller/simpler than just freeing the chunks, because
Hi,
On 2023-05-23 23:26:42 +0200, Tomas Vondra wrote:
> On 5/23/23 19:14, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-23 18:23:00 +0200, Tomas Vondra wrote:
> >> This means that for an UPDATE with triggers, we may end up calling this
> >> for each row, possibly multiple bitmaps. And those bit
Greetings,
In
https://github.com/postgres/postgres/blob/5c2c59ba0b5f723b067a6fa8bf8452d41fbb2125/src/backend/libpq/auth.c#L463
The last piece of information is the encryption state. However when an SSL
connection fails to authenticate the state is not encrypted.
When would it ever be encrypted i
On 5/24/23 17:37, Tom Lane wrote:
> Tomas Vondra writes:
>> While looking for other places allocating stuff in ExecutorState (for
>> the UPDATE case) and leaving it there, I found two more cases:
>
>> 1) copy_plpgsql_datums
>
>> 2) make_expanded_record_from_tupdesc
>>make_expanded_record_
On Wed, May 24, 2023 at 01:43:50PM -0400, Bruce Momjian wrote:
> > * Reduce palloc() memory overhead for all memory allocations down to 8
> > bytes on all platforms. (Andres Freund, David Rowley)
> >
> > This allows more efficient use of memory and is especially useful in
> > queries which perform
On Wed, May 24, 2023 at 08:48:56AM +1200, David Rowley wrote:
> On Tue, 23 May 2023 at 06:04, Bruce Momjian wrote:
> >
> > On Mon, May 22, 2023 at 10:59:36AM -0700, Andres Freund wrote:
> > > And here it's not just performance, but also memory usage, including
> > > steady
> > > state memory usag
On 5/22/23 3:23 PM, Erik Rijkers wrote:
Op 5/21/23 om 19:07 schreef Jonathan S. Katz:
On 5/19/23 12:17 AM, Jonathan S. Katz wrote:
Hi,
Attached is a draft of the release announcement for PostgreSQL 16
Beta Please provide feedback no later than May 24, 0:00 AoE. This
will give
Thanks everyon
On 5/24/23 12:13 AM, David Rowley wrote:
On Wed, 24 May 2023 at 15:54, Bruce Momjian wrote:
On Wed, May 24, 2023 at 08:37:45AM +1200, David Rowley wrote:
On Mon, 22 May 2023 at 07:05, Jonathan S. Katz wrote:
* Parallel execution of queries that use `FULL` and `OUTER` joins
I think this sh
On 5/24/23 11:39, Jeff Davis wrote:
On Mon, 2023-05-22 at 22:09 +0200, Daniel Verite wrote:
In practice we're probably getting the "und" ICU locale whereas "fr"
would be appropriate.
This is a good point and illustrates that ICU is not a drop-in
replacement for libc in all cases.
I don't see
On Wed, May 24, 2023 at 04:57:59PM +0200, Erik Rijkers wrote:
> Op 5/24/23 om 15:58 schreef Bruce Momjian:
> > On Wed, May 24, 2023 at 12:23:02PM +0700, John Naylor wrote:
> > >
> > > On Wed, May 24, 2023 at 11:19 AM Bruce Momjian wrote:
>
> Typos:
>
> 'from standbys servers' should be
> 'from
Tomas Vondra writes:
> On 5/23/23 23:39, Tom Lane wrote:
>> FWIW, I've had some success localizing palloc memory leaks with valgrind's
>> leak detection mode. The trick is to ask it for a report before the
>> context gets destroyed. Beats writing your own infrastructure ...
> I haven't tried va
On Mon, 2023-05-22 at 22:09 +0200, Daniel Verite wrote:
> While I agree that the LOCALE option in CREATE DATABASE is
> counter-intuitive,
I think it's more than that. As Andreww Gierth pointed out:
$ initdb --locale=fr_FR
...
ICU locale: en-US
...
Is more than just counter-intuiti
Tomas Vondra writes:
> While looking for other places allocating stuff in ExecutorState (for
> the UPDATE case) and leaving it there, I found two more cases:
> 1) copy_plpgsql_datums
> 2) make_expanded_record_from_tupdesc
>make_expanded_record_from_exprecord
> All of this is calls from plpg
Richard Guo writes:
> So the qual 't2.a = t5.a' is missing.
Ugh.
> I looked into it and found that both clones of this joinqual are
> rejected by clause_is_computable_at, because their required_relids do
> not include the outer join of t2/(t3/t4), and meanwhile include nullable
> rels of this ou
Op 5/24/23 om 15:58 schreef Bruce Momjian:
On Wed, May 24, 2023 at 12:23:02PM +0700, John Naylor wrote:
On Wed, May 24, 2023 at 11:19 AM Bruce Momjian wrote:
Typos:
'from standbys servers' should be
'from standby servers'
'reindexedb' should be
'reindexdb'
(2x: the next line mentions,
Hi everyone,
I was wondering if waiting for an LSN in SyncRepWaitForLSN ensures that the
XLOG has been flushed locally up to that location before the record is
shipped off to standbys?
Regards,
Tej
Hans Buschmann writes:
> This inspired me to propose dropping 32bit support for PostgreSQL starting
> with PG17.
I don't think this is a great idea. Even if Intel isn't interested,
there'll be plenty of 32-bit left in the lower end of the market
(think ARM, IoT, and so on).
I recently stumbled over the following Intel proposal for dropping 32bit
support in x86 processors. [1]
This inspired me to propose dropping 32bit support for PostgreSQL starting with
PG17.
It seems obvious that production systems mostly won't use newly installed 32
bit native code in late 2
Daniel Gustafsson writes:
> It would be nice it the OpenSSL project could grant us an LTS license for a
> buildfarm animal to ensure compatibility but I have no idea how realistic that
> is (or how much the LTS version of 1.0.2 has diverged from the last available
> public 1.0.2 version).
Surely
On Tue May 23, 2023 at 7:31 PM CDT, Michael Paquier wrote:
> On Mon, May 22, 2023 at 10:02:02AM -0500, Tristan Partin wrote:
> > The way that pgbench handled SIGINT changed in
> > 1d468b9ad81b9139b4a0b16b416c3597925af4b0. Unfortunately this had a
> > couple of unintended consequences, at least from
On Wed, May 24, 2023 at 12:23:02PM +0700, John Naylor wrote:
>
> On Wed, May 24, 2023 at 11:19 AM Bruce Momjian wrote:
> >
> > Second, you might be correct that the section is wrong. I thought of
> > CPU instructions as something tied to the compiler, so part of the build
> > process or source c
On 5/23/23 22:57, Tomas Vondra wrote:
>
>
> On 5/23/23 18:39, Tom Lane wrote:
>> Tomas Vondra writes:
>>> it seems there's a fairly annoying memory leak in trigger code,
>>> introduced by
>>> ...
>>> Attached is a patch, restoring the pre-12 behavior for me.
>>
>>> While looking for other plac
On 5/24/23 10:19, Jakub Wartak wrote:
> Hi, just two cents:
>
> On Tue, May 23, 2023 at 8:01 PM Andres Freund wrote:
>>
>> Hi,
>>
>> On 2023-05-23 13:28:30 -0400, Tom Lane wrote:
>>> Andres Freund writes:
Could it help to have a mode where the executor shutdown hook checks how
much
On Wed, May 24, 2023 at 2:18 AM Peter Eisentraut
wrote:
> > What I'm hearing is that something simple like this might be more
> > acceptable:
> >
> > * initdb --rel-segsize (cf --wal-segsize), default unchanged
>
> makes sense
+1.
> > * pg_upgrade would convert if source and target don't match
On Tue, May 23, 2023 at 6:26 PM Michael Paquier wrote:
> Spinlocks provide a full memory barrier, which may not the case with
> add_u64() or read_u64(). Could memory ordering be a problem in these
> code paths?
It could be a huge problem if what you say were true, but unless I'm
missing somethin
> On 23 May 2023, at 23:02, Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
>> - low iteration counts accepted by the client make it easier than it
>> probably should be for a MITM to brute-force passwords (note that
>> PG16's scram_iterations GUC, being server-side, does
Hi,
On 5/23/23 5:15 PM, Robert Haas wrote:
On Sat, Apr 8, 2023 at 5:26 AM Andres Freund wrote:
TAP test for logical decoding on standby
Small nitpicks:
1. The test names generated by check_slots_conflicting_status() start
with a capital letter, while most other test names start with a
lower
Testing with SQLancer reports a wrong results issue on master and I
reduced it to the repro query below.
create table t (a int, b int);
explain (costs off)
select * from t t1 left join
(t t2 left join t t3 full join t t4 on false on false)
left join t t5 on t2.a = t5.a
on t2.b = 1;
> On 24 May 2023, at 11:52, Michael Paquier wrote:
>
> On Wed, May 24, 2023 at 11:36:56AM +0200, Daniel Gustafsson wrote:
>> 1.0.2 is also an LTS version available commercially for premium support
>> customers of OpenSSL (1.1.1 will become an LTS version as well), with 1.0.2zh
>> slated for relea
On Wed, May 24, 2023 at 11:36:56AM +0200, Daniel Gustafsson wrote:
> 1.0.2 is also an LTS version available commercially for premium support
> customers of OpenSSL (1.1.1 will become an LTS version as well), with 1.0.2zh
> slated for release next week. This raises the likelyhood of Postgres
> inst
On Tue, 23 May 2023 at 18:34, Robert Haas wrote:
>
> On Thu, May 18, 2023 at 8:06 AM Matthias van de Meent
> wrote:
> > This enum still has many options to go before it exceeds the maximum
> > of the uint8 va_tag field. Therefore, I don't think we have no disk
> > representations left, nor do I t
> On 24 May 2023, at 10:22, Michael Paquier wrote:
> The removal of 1.0.2 would be nice, but the tweaks
> needed for LibreSSL make it less appealing.
1.0.2 is also an LTS version available commercially for premium support
customers of OpenSSL (1.1.1 will become an LTS version as well), with 1.0.
Hi!
I've made a WIP patch that uses 64-bit TOAST value ID instead of 32-bit,
and sent it as a part of discussion, but there was no feedback on such a
solution. There was a link to that discussion at the top of this thread.
Also, I have to note that, based on our work on Pluggable TOAST - extendin
On 5/23/23 23:39, Tom Lane wrote:
> Tomas Vondra writes:
>> The really hard thing was determining what causes the memory leak - the
>> simple instrumentation doesn't help with that at all. It tells you there
>> might be a leak, but you don't know where did the allocations came from.
>
>> What I e
Hi all,
$Subject says it all. Based on an analysis of the code, I can note
the following when it comes to the removal of 1.0.1:
- A lot of code related to channel binding is now simplified as
X509_get_signature_nid() always exists, mostly around its CFLAGS.
- This removes the comments related to
Hi, just two cents:
On Tue, May 23, 2023 at 8:01 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-05-23 13:28:30 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Could it help to have a mode where the executor shutdown hook checks how
> > > much
> > > memory is allocated in ExecutorState and w
76 matches
Mail list logo
