David Rowley writes:
> Let's bash it into shape a bit more before going any further on actual
> wording.
FWIW, I want to push back on the idea of making it a tutorial section.
I too considered that, but in the end I think it's a better idea to
put it into the "main" docs, for two reasons:
1. I
On Thu, 2 May 2024 at 03:12, David G. Johnston
wrote:
> Attached is a very rough draft attempting this, based on my own thoughts and
> those expressed by Tom in [1], which largely align with mine.
Thanks for picking this up. I agree that we should have something to
improve this.
It would be
On Wed, May 1, 2024 at 8:12 PM David G. Johnston
wrote:
> Hi,
>
> Over in [1] it was rediscovered that our documentation assumes the reader
> is familiar with NULL. It seems worthwhile to provide both an introduction
> to the topic and an overview of how this special value gets handled
>
On Thu, May 02, 2024 at 11:23:13AM +0900, Michael Paquier wrote:
> About the fact that we may finish by printing unfinished UTF-8
> sequences, I'd be curious to hear your thoughts. Now, the information
> provided about the partial byte sequences can be also useful for
> debugging on top of having
On Wed, May 01, 2024 at 04:22:24PM -0700, Jacob Champion wrote:
> On Tue, Apr 30, 2024 at 11:09 PM Michael Paquier wrote:
>> Not sure to like much the fact that this advances token_terminator
>> first. Wouldn't it be better to calculate pg_encoding_mblen() first,
>> then save token_terminator?
On Sat, 27 Apr 2024 at 02:13, Robert Haas wrote:
> Let's compare the current situation to the situation post-patch with a
> cap of 500k. Consider a table 1024 times larger than the one I
> mentioned above, so pgbench scale factor 25600, size on disk 320GB.
> Currently, that table will be vacuumed
On Tue, Apr 30, 2024 at 11:09 PM Michael Paquier wrote:
> Not sure to like much the fact that this advances token_terminator
> first. Wouldn't it be better to calculate pg_encoding_mblen() first,
> then save token_terminator? I feel a bit uneasy about saving a value
> in token_terminator past
While writing an injection point test, I encountered a variant of the race
condition that f4083c4 fixed. It had three sessions and this sequence of
events:
s1: local-attach to POINT
s2: enter InjectionPointRun(POINT), yield CPU just before injection_callback()
s3: detach POINT, deleting the
Hi!
30.04.2024 23:15, Justin Pryzby пишет:
Is this issue already fixed ?
I wasn't able to reproduce it. Maybe it only happened with earlier
patch versions applied ?
I think this was fixed in commit [1].
[1]
On Wed, May 1, 2024 at 11:57 AM Thomas Spear wrote:
> It does fail to validate for case 4 after all. I must have had a copy/paste
> error during past tests.
Okay, good. Glad it's behaving as expected!
> So then it sounds like putting the MS root in root.crt (as we have done to
> fix this) is
On Wed, May 1, 2024 at 1:10 PM Ayush Vatsa wrote:
> I'm currently delving into Postgres HLL (HyperLogLog) functionality and have
> encountered an unexpected behavior while executing queries from the
> "cumulative_add_sparse_edge.sql" regress test. This particular test data file
> involves
On Wed, May 1, 2024 at 12:31 PM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Wed, May 1, 2024 at 8:17 AM Thomas Spear wrote:
> > Circling back to my original question, why is there a difference in
> behavior?
> >
> > What I believe should be happening isn't what's happening:
> >
On Wed, May 1, 2024 at 2:19 PM Imseih (AWS), Sami wrote:
> > Unless I'm missing something major, that's completely bonkers. It
> > might be true that it would be a good idea to vacuum such a table more
> > often than we do at present, but there's no shot that we want to do it
> > that much more
I've been following this discussion and would like to add my
2 cents.
> Unless I'm missing something major, that's completely bonkers. It
> might be true that it would be a good idea to vacuum such a table more
> often than we do at present, but there's no shot that we want to do it
> that much
On 2024-Apr-25, Alvaro Herrera wrote:
> > Also, I've found a weird behaviour with a non-inherited NOT NULL
> > constraint for a partitioned table:
> > CREATE TABLE pt(a int NOT NULL NO INHERIT) PARTITION BY LIST (a);
> Ugh. Maybe a way to handle this is to disallow NO INHERIT in
> constraints
On Wed, May 1, 2024 at 8:17 AM Thomas Spear wrote:
> Circling back to my original question, why is there a difference in behavior?
>
> What I believe should be happening isn't what's happening:
> 1. If ~/.postgresql/root.crt contains the MS root, and I don't specify
> sslrootcert= -- successful
Hi PostgreSQL Community,
I'm currently delving into Postgres HLL (HyperLogLog) functionality and
have encountered an unexpected behavior while executing queries from the "
cumulative_add_sparse_edge.sql
Thank you for taking the time to review this. I've attached a new rebased
version, which has no significant changes.
> There is a comment in the patch that states:
>
> /* We do not need clean_ipv6_addr here: just report verbatim */
>
> I am not quite sure what it means, but I am guessing it
> This isn't a complete review. It's just that this seems enough to keep
> you busy for a while. I can look a bit harder when the patch is
> working correctly. I think you should have enough feedback to allow
> that now.
Thanks for the test, review and feedback. They are greatly appreciated!
Hi,
Comparing the current SSE4.2 implementation of the CRC32C algorithm in
Postgres, to an optimized AVX-512 algorithm [0] we observed significant gains.
The result was a ~6.6X average multiplier of increased performance measured on
3 different Intel products. Details below. The AVX-512
On Wed, May 1, 2024, 16:13 David G. Johnston
wrote:
> Hi,
>
> Over in [1] it was rediscovered that our documentation assumes the reader
> is familiar with NULL. It seems worthwhile to provide both an introduction
> to the topic and an overview of how this special value gets handled
> throughout
On Wed, May 1, 2024 at 9:23 AM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Wed, May 1, 2024 at 6:48 AM Thomas Spear wrote:
> > I dumped out the certificates presented by the server using openssl, and
> the chain that gets output includes "Microsoft Azure RSA TLS Issuing CA 08".
Hi,
Over in [1] it was rediscovered that our documentation assumes the reader
is familiar with NULL. It seems worthwhile to provide both an introduction
to the topic and an overview of how this special value gets handled
throughout the system.
Attached is a very rough draft attempting this,
On Wed, May 1, 2024 at 6:48 AM Thomas Spear wrote:
> I dumped out the certificates presented by the server using openssl, and the
> chain that gets output includes "Microsoft Azure RSA TLS Issuing CA 08".
> On https://www.microsoft.com/pkiops/docs/repository.htm the page says that
> that cert
On Tue, Apr 30, 2024 at 5:19 PM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
On Tue, Apr 30, 2024 at 2:41 PM Thomas Spear wrote:
> The full details can be found at github.com/pgjdbc/pgjdbc/discussions/3236 -
in summary, both jdbc-postgres and the psql cli seem to be affected by an
On 28.04.2024 22:36, Heikki Linnakangas wrote:
Peter E noticed and Michael fixed them in commit 768ceeeaa1 already.
Didn't check that is already fixed in the current master. Sorry!
Thanks for pointing this out!
With the best wishes,
--
Anton A. Melnikov
Postgres Professional:
On Wed, May 1, 2024 at 2:00 PM Alexander Lakhin wrote:
> 30.04.2024 13:20, Alexander Korotkov wrote:
> > On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin
> > wrote:
> >> I've discovered another failure, introduced by d3d55ce57.
> >> Please try the following:
> >> CREATE TABLE t (a int unique, b
On Wed, May 1, 2024 at 12:39 AM Paul Jungwirth
wrote:
>
> On 4/30/24 09:24, Robert Haas wrote:
> > Peter, could you have a look at
> > http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com
> > and express an opinion about whether each of those proposals are (a)
> > good
30.04.2024 13:20, Alexander Korotkov wrote:
On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin wrote:
I've discovered another failure, introduced by d3d55ce57.
Please try the following:
CREATE TABLE t (a int unique, b float);
SELECT * FROM t NATURAL JOIN LATERAL
(SELECT * FROM t t2
On Tue, Apr 30, 2024 at 11:28 PM Christophe Pettus wrote:
>
> Hi,
>
> I wanted to check my understanding of how control flows in a walsender
> doing logical replication. My understanding is that the (single) thread in
> each walsender process, in the simplest case, loops on:
>
> 1. Pull a
On Wed, 1 May 2024 at 07:10, Cary Huang wrote:
> Yes of course. These numbers were obtained earlier this year on master with
> the patch applied most likely without the read stream code you mentioned. The
> patch attached here is rebased to commit
> dd0183469bb779247c96e86c2272dca7ff4ec9e7 on
On Thu, Apr 25, 2024 at 8:36 AM Masahiko Sawada wrote:
>
> On Mon, Apr 15, 2024 at 6:12 PM John Naylor wrote:
> > - RT_KEY_GET_SHIFT is not covered for key=0:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L803
> >
> > That should be fairly
On Tue, Apr 30, 2024 at 10:39:04AM -0700, Jacob Champion wrote:
> When json_lex_string() hits certain types of invalid input, it calls
> pg_encoding_mblen_bounded(), which assumes that its input is
> null-terminated and calls strnlen(). But the JSON lexer is constructed
> with an explicit string
33 matches
Mail list logo
