On Thu, Jun 13, 2024 at 6:14 PM Masahiko Sawada wrote:
>
> On Thu, Jun 13, 2024 at 7:06 PM Amit Kapila wrote:
> >
> > On Thu, Jun 13, 2024 at 1:09 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jun 12, 2024 at 6:59 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Yeah, starting with a s
> On 13 Jun 2024, at 02:04, Nathan Bossart wrote:
>
> I adjusted 0001 based on my upthread feedback.
This patch looks good to me. Spellchecker is complaining about “signaling”
instead of “signalling”, but ISTM it’s OK.
I’ve tried to dig into the test.
The problem is CV is allocated in
inj_
On Thu, Jun 13, 2024 at 9:18 PM Tom Lane wrote:
> Ranier Vilela writes:
> > +1 for push.
>
> Done. [...]
Thanks a lot Tom (and reviewers)! --DD
Hi hackers,
I am using gcc version 11.3.0 to compile postgres source code. Gcc complains
about the following line:
```c
strncpy(sqlca->sqlstate, "YE001", sizeof(sqlca->sqlstate));
```
with error as:
misc.c:529:17: error: ‘strncpy’ output truncated before terminating nul copying
5 bytes fr
Hello!
The src/backend/access/heap/README.tuplock says about HEAP_XMAX_INVALID bit
that "Any tuple with this bit set does not have a valid value stored in XMAX."
Found that FreezeMultiXactId() tries to process such an invalid multi xmax
and may looks for an update xid in the pg_multixact for it.
Hi,
On Thu, Jun 13, 2024 at 02:27:45PM -0400, Robert Haas wrote:
> On Thu, Jun 13, 2024 at 12:52 PM Bertrand Drouvot
> wrote:
> > > > table_open(childRelId, ...) would lock any "ALTER TABLE
> > > > DROP CONSTRAINT"
> > > > already. Not sure I understand your concern here.
> > >
> > > I believe
> On 14 Jun 2024, at 09:38, Winter Loo wrote:
> I find the definition of `sqlca->sqlstate` and it has only 5 bytes. When the
> statement
>
> ```c
> strncpy(sqlca->sqlstate, "YE001", sizeof(sqlca->sqlstate));
> ```
>
> get executed, `sqlca->sqlstate` will have no '\0' byte which makes me anxiou
On Fri, 2024-06-14 at 15:38 +0800, Winter Loo wrote:
> I am using gcc version 11.3.0 to compile postgres source code. Gcc complains
> about the following line:
>
> strncpy(sqlca->sqlstate, "YE001", sizeof(sqlca->sqlstate));
>
> with error as:
>
> misc.c:529:17: error: ‘strncpy’ output truncat
On Fri, 2024-06-14 at 09:55 +0200, Daniel Gustafsson wrote:
> > On 14 Jun 2024, at 09:38, Winter Loo wrote:
>
> > I find the definition of `sqlca->sqlstate` and it has only 5 bytes. When
> > the statement
> >
> > ```c
> > strncpy(sqlca->sqlstate, "YE001", sizeof(sqlca->sqlstate));
> > ```
> >
> On 14 Jun 2024, at 10:06, Laurenz Albe wrote:
> So you think we should ignore that compiler warning?
We already do using this in meson.build:
# Similarly disable useless truncation warnings from gcc 8+
'format-truncation',
'stringop-truncation',
--
Daniel Gustafsson
On Fri, 2024-06-14 at 10:10 +0200, Daniel Gustafsson wrote:
> > On 14 Jun 2024, at 10:06, Laurenz Albe wrote:
>
> > So you think we should ignore that compiler warning?
>
> We already do using this in meson.build:
>
> # Similarly disable useless truncation warnings from gcc 8+
> 'format-tru
> On 14 Jun 2024, at 10:29, Laurenz Albe wrote:
>
> On Fri, 2024-06-14 at 10:10 +0200, Daniel Gustafsson wrote:
>>> On 14 Jun 2024, at 10:06, Laurenz Albe wrote:
>>
>>> So you think we should ignore that compiler warning?
>>
>> We already do using this in meson.build:
>>
>> # Similarly disa
> On Thu, Jun 13, 2024 at 10:30:24AM GMT, Andres Freund wrote:
> > > To investigate a report of both postgres and pgbouncer having issues when
> > > a
> > > lot of new connections aree established, I used pgbench -C. Oddly, on an
> > > early attempt, the bottleneck wasn't postgres+pgbouncer, it w
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This applies cleanly to master, builds and passes regression tests in my
Win
On Fri, Jun 14, 2024 at 5:16 AM Michael Paquier wrote:
>
> On Thu, Jun 13, 2024 at 03:36:05PM +0530, Amit Kapila wrote:
> > Fair enough. However, this raises the question Dilip and Vignesh are
> > discussing whether we need a new relfilenode for sequence update even
> > during initial sync? As per
Hello, Michael.
> Isn't the issue that we may select as arbiter indexes stuff that's
!indisvalid?
As far as I can see (1) !indisvalid indexes are filtered out.
But... It looks like this choice is not locked in any way (2), so
index_concurrently_swap or index_concurrently_set_dead can change this
> On 14 Jun 2024, at 10:46, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
>> On Thu, Jun 13, 2024 at 10:30:24AM GMT, Andres Freund wrote:
To investigate a report of both postgres and pgbouncer having issues when a
lot of new connections aree established, I used pgbench -C. Oddly, on an
> Thanks for the updated patch, few comments:
> 1) The option name seems wrong here:
> In one place include_generated_column is specified and other place
> include_generated_columns is specified:
>
> + else if (IsSet(supported_opts,
> SUBOPT_INCLUDE_GENERATED_COLUMN) &&
> +
On Thu, Jun 13, 2024 at 7:00 PM Alvaro Herrera wrote:
>
> On 2024-Jun-07, Tomas Vondra wrote:
>
> > On 6/3/24 09:30, Amit Kapila wrote:
> > > On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> > > wrote:
>
> > >> How is this going to deal with the fact that commit LSN and timestamps
> > >> may not c
On Tue, Jun 4, 2024 at 8:12 AM Peter Smith wrote:
>
> Hi,
>
> Here are some review comments for patch v5-0001.
>
> ==
> GENERAL G.1
>
> The patch changes HEAD behaviour for PUBLICATION col-lists right? e.g.
> maybe before they were always ignored, but now they are not?
>
> OTOH, when 'include_
>Thanks for looking! I will apply it backpatched all the way down as this has
>been wrong since 2006.
>
>> I wonder how Winter Loo got to see that warning...
>
I was compiling source code of postgres version 13 and the building flags is
changed in my development environment.
>And it would be int
On Thu, Jun 13, 2024 at 11:18 PM Jonathan S. Katz wrote:
>
> On 6/13/24 7:28 AM, Amit Kapila wrote:
> >>
> >> I feel that we should log all types of conflict in an uniform way. For
> >> example, with detect_conflict being true, the update_differ conflict
> >> is reported as "conflict %s detected o
hi Tomas,
So many thanks for your kind response and detailed report. I am working
on locating issues based on your report/script and optimizing code, and
will update later.
Could you please also send me the script to generate report pdf
from the test results (explain*.log)? I can try to make one
On Fri, Jun 14, 2024 at 12:10 AM Robert Haas wrote:
>
> On Thu, May 23, 2024 at 2:37 AM shveta malik wrote:
> > c) update_deleted: The row with the same value as that incoming
> > update's key does not exist. The row is already deleted. This conflict
> > type is generated only if the deleted row
I was performing tests around multixid wraparound, when I ran into this
assertion:
TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File:
"../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981
postgres: autovacuum worker template0(ExceptionalCondition+0x6e)[0
On Thursday, June 13, 2024 8:46 PM Peter Eisentraut
wrote:
>
> On 23.05.24 08:36, shveta malik wrote:
> > Conflict Resolution
> >
> > a) latest_timestamp_wins:The change with later commit timestamp
> wins.
> > b) earliest_timestamp_wins: The change with earlier commit time
14.06.2024 05:48, Joseph Koshakow wrote:
v4-0001-Remove-dependence-on-integer-wrapping.patch is unchanged, I
just incremented the version number.
> Also there are several trap-producing cases with date types:
> SELECT to_date('1', 'CC');
> SELECT to_timestamp('10,999',
On Mon, Apr 8, 2024 at 1:34 AM Alexander Korotkov wrote:
>
> I've revised the patch. Did some beautification, improvements for
> documentation, commit messages etc.
>
> I've pushed the 0001 patch without 0002. I think 0001 is good by
> itself given that there is the or_to_any_transform_limit GUC
On Thu, Jun 13, 2024 at 8:12 PM Jacob Champion
wrote:
> But also: do you have opinions on what to fill in as steps 2
> (something we have no ability to test today) and 3 (something we do
> test today, but hate)?
>
> My vote for step 2 is "client and server separation", perhaps by
> testing libpq f
On 6/14/24 13:20, Yao Wang wrote:
> hi Tomas,
>
> So many thanks for your kind response and detailed report. I am working
> on locating issues based on your report/script and optimizing code, and
> will update later.
>
> Could you please also send me the script to generate report pdf
> from th
Hi, Ivan!
On Wed, Jun 12, 2024 at 11:36 AM Kartyshov Ivan
wrote:
>
> Hi, Alexander, Here, I made some improvements according to your
> discussion with Heikki.
>
> On 2024-04-11 18:09, Alexander Korotkov wrote:
> > On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas
> > wrote:
> >> In a nutshell,
Hello,
I met an assertion failure, and identified the root of the problem, but no
idea how to fix it.
The location of the problematic Assert() is at cost_memoize_rescan() to
check 'hit_ratio' is between 0.0 and 1.0.
The 'calls' is provided by the caller, and 'ndistinct' is the result
of estimate_
Hello.
> But I was unable to reproduce that using some random usleep(), however -
maybe it is a wrong assumption.
It seems like the assumption is correct - we may use an invalid index as
arbiter due to race condition.
The attached patch adds a check for that case, and now the test fails like
this
Hi!
While working on a making multix xact offsets 64-bit [0] I've discovered a
minor issue. The
thing is that type 'xid' is used in all macro, but it doesn't correct.
Appropriate MultiXactId or
MultiXactOffset should be used, actually.
And the second thing, as Heikki Linnakangas points out, args
On Jun 13, 2024, at 22:31, Chapman Flack wrote:
> It's baked right into the standard grammar: || can only have a
> on its right and a
> on its left.
>
> && can only have a on its right and a
> on its left.
Wow.
> The case for ! is even more limiting: it can't be applied to anything
> but
On Jun 13, 2024, at 21:55, Chapman Flack wrote:
> My opinion is yes, that should be done. 9.46, umm, General
> Rule 11 g ii 6) A) says just "if MODE is lax and is not
> type or size, then let BASE be Unwrap(BASE)." No special exemption
> there for string(), nor further below at C) XV) for the op
Daniel Gustafsson writes:
> This is indeed buggy and need to take the length into account, as per the
> attached. This only happens when in the undocumented regression test debug
> mode which may be why it's gone unnoticed.
Seeing that this code is exercised thousands of times a day in the
regre
Hi,
On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
>
> ccache should be installed in the image rather than re-installed on each
> invocation.
ccache is installed in the Windows VM images now [1]. It can be used
as 'set CC=ccache.exe cl.exe' in the Windows CI task.
[1]
https://github.com/an
On 2024-06-14 Fr 08:10, Robert Haas wrote:
We've talked about a libpq FFI interface, but it hasn't been done;
Hold my beer :-)
I just posted a POC for that.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
I wrote:
> Seeing that this code is exercised thousands of times a day in the
> regression tests and has had a failure rate of exactly zero (and
> yes, the tests do check the output), there must be some reason
> why it's okay.
After looking a little closer, I think the reason why it works in
pract
On Fri, Jun 14, 2024 at 05:36:54PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
> >
> > ccache should be installed in the image rather than re-installed on each
> > invocation.
>
> ccache is installed in the Windows VM images now [1]. It can be use
Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
LibPQ directly via FFI, and there was some support from others as well.
Attached is a very rough POC for just that.There are two perl modules,
one which wraps libpq (or almost all of it) in perl, and another which
uses that
On 2024-06-14 Fr 11:09, Andrew Dunstan wrote:
Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
LibPQ directly via FFI, and there was some support from others as
well. Attached is a very rough POC for just that.There are two perl
modules, one which wraps libpq (or almost a
On 06/14/24 10:39, David E. Wheeler wrote:
> Cited that bit in the commit message in the attached patch (also available as
> a GitHub PR[1]).
>
> [1]: https://github.com/theory/postgres/pull/5
I would s/extepsions/exceptions/ in the added documentation. :)
Offhand (as GitHub PRs aren't really T
Hi,
On June 14, 2024 8:22:01 AM PDT, Justin Pryzby wrote:
>On Fri, Jun 14, 2024 at 05:36:54PM +0300, Nazir Bilal Yavuz wrote:
>> Hi,
>>
>> On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
>> >
>> > ccache should be installed in the image rather than re-installed on each
>> > invocation.
>>
On Fri, Jun 14, 2024 at 11:11 AM Andrew Dunstan wrote:
> And here's the patch
I haven't reviewed the patch, but a big +1 for the idea. Not only this
might cut down on the resource costs of running the tests in CI, as
Andres has pointed out a few times, but it also could lead to much
nicer user in
Hi,
On June 14, 2024 8:09:43 AM PDT, Andrew Dunstan wrote:
>Over at [1] Andres expressed enthusiasm for enabling TAP tests to call LibPQ
>directly via FFI, and there was some support from others as well. Attached is
>a very rough POC for just that.There are two perl modules, one which wraps
>
Robert Haas writes:
> I mean, both Perl and Python are Turing-complete. Anything you can do
> in one, you can do in the other, especially when you consider that
> we're not likely to accept too many dependencies on external Perl or
> Python modules. That's why I see this as nothing more or less th
> On Fri, Jun 14, 2024 at 12:12:55PM GMT, Daniel Gustafsson wrote:
> > I've been experimenting with both:
> >
> > * The server is built without gssapi, but the client does support it.
> > This produces exactly the contention you're talking about.
> >
> > * The server is built with gssapi, but do n
Hi,
On 2024-06-14 10:46:04 +0200, Dmitry Dolgov wrote:
> At the same time after quick look I don't see an easy way to avoid that.
> Current implementation tries to initialize gss before getting any
> confirmation from the server whether it's supported. Doing this other
> way around would probably
> On Jun 14, 2024, at 11:25, Chapman Flack wrote:
>
> I would s/extepsions/exceptions/ in the added documentation. :)
Bah, fixed and attached, thanks.
> Offhand (as GitHub PRs aren't really The PG Way), if they were The Way,
> I would find this one a little hard to follow, being based at a po
Hi,
On 2024-06-14 11:49:29 -0400, Tom Lane wrote:
> I also wonder about integration of python-based testing with what
> we already have. A significant part of what you called the meson
> work had to do with persuading pg_regress, isolationtester, etc
> to output test results in the common format
On 2024-06-14 09:11:11 -0700, Andres Freund wrote:
> On 2024-06-14 11:49:29 -0400, Tom Lane wrote:
> > Am I right in guessing that pytest will have nothing to do with that?
>
> Looks like there's a plugin for pytest to support tap as output:
> https://pypi.org/project/pytest-tap/
>
> However, it'
Hackers,
I noticed that neither `regex_like` nor `starts with`, the jsonpath operators,
raise an error when the operand is not a string (or array of strings):
david=# select jsonb_path_query('true', '$ like_regex "^hi"');
jsonb_path_query
--
null
(1 row)
david=# select jsonb_
Hi,
On 2024-06-14 11:11:38 -0400, Andrew Dunstan wrote:
> On 2024-06-14 Fr 11:09, Andrew Dunstan wrote:
> > Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
> > LibPQ directly via FFI, and there was some support from others as well.
> > Attached is a very rough POC for just t
Andres Freund writes:
> Initializing the gss cache at all isn't so much the problem. It's that we do
> it for every connection. And that doing so requires locking inside gss. So
> maybe we could just globally cache that gss isn't available, instead of
> rediscovering it over and over for every new
Hi,
On 2024-06-14 12:27:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Initializing the gss cache at all isn't so much the problem. It's that we do
> > it for every connection. And that doing so requires locking inside gss. So
> > maybe we could just globally cache that gss isn't available
On 14/06/2024 16:56, Maxim Orlov wrote:
Hi!
While working on a making multix xact offsets 64-bit [0] I've
discovered a minor issue. The thing is that type 'xid' is used in
all macro, but it doesn't correct. Appropriate MultiXactId or
MultiXactOffset should be used, actually.
And the second t
On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
> This patch looks good to me.
Thanks for looking.
> Spellchecker is complaining about "signaling" instead of "signalling",
> but ISTM it´s OK.
I think this is an en-US versus en-GB thing. We've standardized on en-US
for "cancel
On Thu, Jun 13, 2024 at 1:08 PM Jelte Fennema-Nio
wrote:
> But Perl is at the next level of unmaintained infrastructure. It is
> actually clear how you can contribute to it, but still no new
> community members actually want to contribute to it. Also, it's not
> only unmaintained by us but it's a
On Fri, 14 Jun 2024 at 22:33, Greg Sabino Mullane wrote:
> I am not happy with the state of Perl, as it has made some MAJOR missteps
> along the way, particularly in the last 5 years. But can we dispel this
> strawman? There is a difference between "unpopular" and "unmaintained". The
> latest v
On Fri, Jun 14, 2024 at 9:24 AM Robert Haas wrote:
> For example, the fact that
> nobody's helping Thomas maintain this cfbot that we all have come to
> rely on, or helping him get that integrated into
> commitfest.postgresql.org, is a problem.
I've been talking to Magnus and Jelte about cfbot an
On Wed, Jun 12, 2024 at 09:41:01AM -0500, Nathan Bossart wrote:
> Actually, I think you are right that we need a manual checkpoint, except I
> think we need it to be after prepare_new_globals(). set_frozenxids()
> connects to each database (including template0) and updates a bunch of
> pg_class ro
On Fri, 14 Jun 2024 at 17:49, Tom Lane wrote:
> But what I'd really like to see is some comparison of the
> language-provided testing facilities that we're proposing
> to depend on. Why is pytest (or whatever) better than Test::More?
Some advantages of pytest over Test::More:
1. It's much easie
On Thu, 2024-06-06 at 11:37 -0700, Jeff Davis wrote:
>
> I think this patch series is a nice cleanup, as well, making libc
> more
> like the other providers and not dependent on global state.
New rebased series attached with additional cleanup. Now that
pg_locale_t is never NULL, we can simplify
On Sat, Jun 15, 2024 at 3:33 AM Robert Haas wrote:
> I haven't reviewed the patch, but a big +1 for the idea. Not only this
> might cut down on the resource costs of running the tests in CI, as
It would be good to keep some context between the threads here. For
the archives' sake, here is where
Robert Haas writes:
> I think the only thing we absolutely have to fix here is the dangling
> ACL references.
Here's a draft patch that takes care of Hannu's example, and I think
it fixes other potential dangling-reference scenarios too.
I'm not sure whether I like the direction this is going, b
The blog post here (thank you depesz!):
https://www.depesz.com/2024/06/11/how-much-speed-youre-leaving-at-the-table-if-you-use-default-locale/
showed an interesting result where the builtin provider is not quite as
fast as "C" for queries like:
SELECT * FROM a WHERE t = '...';
The reason is
On 06/14/24 12:21, David E. Wheeler wrote:
> I noticed that neither `regex_like` nor `starts with`, the jsonpath
> operators, raise an error when the operand is not a string (or array of
> strings):
>
> david=# select jsonb_path_query('true', '$ like_regex "^hi"');
> jsonb_path_query
> ---
On 06/14/24 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we add documentation abou
70 matches
Mail list logo
