On Thu, Apr 11, 2024 at 6:58 PM Kirill Reshke wrote:
>
> While working on [0] i have noticed this comment in
> TerminateOtherDBBackends function:
>
> /*
> * Check whether we have the necessary rights to terminate other
> * sessions. We don't terminate any session until we ensure that we
> * have
On Mon, 15 Apr 2024 at 14:55, David Rowley wrote:
> If GetNowFloat() somehow was returning a negative number then we could
> end up with a large delay. But if gettimeofday() was so badly broken
> then wouldn't there be some evidence of this in the log timestamps on
> failing runs?
3 things
On Mon, 15 Apr 2024 at 16:10, Robins Tharakan wrote:
> - I now have 2 separate runs stuck on pg_sleep() - HEAD / REL_16_STABLE
> - I'll keep them (stuck) for this week, in case there's more we can get
> from them (and to see how long they take)
> - Attached are 'bt full' outputs for both (b.txt -
On Tue, Apr 09, 2024 at 07:40:57PM -0400, Peter Geoghegan wrote:
> That's probably why it's not finding anything now: most people working
> on something that touches WAL already know that testing their patch
> with wal_consistency_checking early is a good idea. Of course it also
> wouldn't be a
On Fri, Apr 12, 2024 at 02:42:57PM +0200, Daniel Gustafsson wrote:
>> On 10 Apr 2024, at 09:31, Peter Eisentraut wrote:
>> 2. Move to 1.1.1. I understand this has to do with the fork-safety of
>> pg_strong_random(), and it's not an API change but a behavior change. Let's
>> make this
hi.
https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items#Open_Issues
issue: Problems with deparsed SQL/JSON query function
original the bug report link:
https://postgr.es/m/cacjufxeqhqsfrg_p7emyo5zak3d767ifdl8vz_4%3dzbhpotr...@mail.gmail.com
forgive me for putting it in the new email
On Wed, Mar 20, 2024 at 5:40 AM Andrew Dunstan wrote:
>
>
> +many for improving the index.
>
> My own pet docs peeve is a purely editorial one: func.sgml is a 30k line
> beast, and I think there's a good case for splitting out at least the larger
> chunks of it.
>
I think I successfully
On Fri, Apr 12, 2024 at 01:32:42PM +0500, Kirill Reshke wrote:
> +#
> +# Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
> +# Portions Copyright (c) 1994, Regents of the University of California
> +#
> (Like in src/test/signals/Makefile)
>
> at the beginning of each added
On Sun, 14 Apr 2024 at 00:12, Tom Lane wrote:
> If we were only supposed to sleep 0.1 seconds, how is it waiting
> for 60 ms (and, presumably, repeating that)? The logic in
> pg_sleep is pretty simple, and it's hard to think of anything except
> the system clock jumping (far) backwards that
Hackers,
Since incremental backup is using INCREMENTAL as a keyword (rather than
storing incremental info in the manifest) it is vulnerable to any file
in PGDATA with the pattern INCREMENTAL.*.
For example:
$ pg_basebackup -c fast -D test/backup/full -F plain
$ touch
On 4/13/24 21:02, Tomas Vondra wrote:
On 4/13/24 01:23, David Steele wrote:
Even for the summarizer, though, I do worry about the complexity of
maintaining it over time. It seems like it would be very easy to
introduce a bug and have it go unnoticed until it causes problems in the
field. A lot
On Mon, 15 Apr 2024 at 14:09, Michael Paquier wrote:
>
> On Mon, Apr 15, 2024 at 01:31:47PM +1200, David Rowley wrote:
> > I'm unsure if "Rule of thumb" is the correct way to convey that. We
> > can't really write "We endeavour to", as who is "We". Maybe something
> > like "Generally, it can be
On Sun, Apr 14, 2024 at 7:03 PM David Rowley wrote:
> On Mon, 15 Apr 2024 at 13:37, David G. Johnston
> wrote:
> > Seems we can improve things by simply removing the "rule of thumb"
> sentence altogether. The prior paragraph states the things the queryid
> depends upon at the level of detail
On Mon, 15 Apr 2024 at 12:12, Ranier Vilela wrote:
>
> Em dom., 14 de abr. de 2024 às 20:38, David Rowley
> escreveu:
>> You seem to have forgotten to attach it, but my comments above were
>> written with the assumption that the patch is what I've attached here.
>
> Yes, I actually forgot.
>
>
On Mon, Apr 15, 2024 at 01:31:47PM +1200, David Rowley wrote:
> I think a soft guarantee in the docs for it being stable in minor
> versions would be ok then.
>
> I'm unsure if "Rule of thumb" is the correct way to convey that. We
> can't really write "We endeavour to", as who is "We". Maybe
On Mon, 15 Apr 2024 at 13:37, David G. Johnston
wrote:
> Seems we can improve things by simply removing the "rule of thumb" sentence
> altogether. The prior paragraph states the things the queryid depends upon
> at the level of detail the reader needs.
I don't think that addresses the
On Sun, Apr 14, 2024 at 6:32 PM David Rowley wrote:
> On Mon, 15 Apr 2024 at 13:19, Tom Lane wrote:
> >
> > Michael Paquier writes:
> > > On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
> > >> 1. We cannot change Node enums in minor versions
> > >> 2. We're *unlikely* to add
Hello, hackers.
When the checkpointer process is busy, even if we reset
synchronous_standby_names, the resumption of the backend processes waiting in
SyncRep are made to wait until the checkpoint is completed.
This prevents the prompt resumption of application processing when a problem
occurs
On Tue, Apr 02, 2024 at 01:06:06AM -0400, Tom Lane wrote:
> AFAICS, e2395cdbe posits that taking exclusive lock on pg_am in the
> middle of a bunch of concurrent regression scripts couldn't possibly
> cause any problems. Really?
There is no need for a catalog here to trigger the failure, and it
On Sun, Apr 14, 2024 at 4:20 PM David Rowley wrote:
>
> I've drafted a patch which I think improves things, but it probably
> needs more work and opinions.
>
>
Seems we can improve things by simply removing the "rule of thumb" sentence
altogether. The prior paragraph states the things the
On Mon, 15 Apr 2024 at 13:19, Tom Lane wrote:
>
> Michael Paquier writes:
> > On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
> >> 1. We cannot change Node enums in minor versions
> >> 2. We're *unlikely* to add fields to Node types in minor versions, and
> >> if we did we'd likely
On Mon, 15 Apr 2024 at 12:04, Michael Paquier wrote:
> Since 16 these new fields would be added by default unless the node
> attribute query_jumble_ignore is appended to it. I agree that this
> may not be entirely intuitive when it comes to force compatibility
> across the same major version.
Hi,
I was grepping for iovec users and noticed that the shm_mq stuff
defines its own iovec struct. Is there any reason not to use the
standard one, now that we can? Will add to next commitfest.
From 20b44cab0bb9f6218270aa0ae150ac0e560b49fe Mon Sep 17 00:00:00 2001
From: Thomas Munro
Date: Mon,
Michael Paquier writes:
> On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
>> 1. We cannot change Node enums in minor versions
>> 2. We're *unlikely* to add fields to Node types in minor versions, and
>> if we did we'd likely be leaving them out of the jumble calc, plus it
>> seems
David Rowley writes:
> On Mon, 15 Apr 2024 at 11:54, Tom Lane wrote:
>> would this also allow us to get rid of any default:
>> cases in switches on command tags?
> git grep "case CMDTAG_" does not yield any results.
OK. It was worth checking.
regards, tom lane
On Sun, Apr 14, 2024 at 9:01 PM David Rowley wrote:
> On Mon, 15 Apr 2024 at 11:47, Peter Geoghegan wrote:
> > Technically we don't promise that WAL records won't change in minor
> > versions. In fact, the docs specifically state that the format of any
> > WAL record might change, and that users
On Mon, 15 Apr 2024 at 11:54, Tom Lane wrote:
> would this also allow us to get rid of any default:
> cases in switches on command tags?
git grep "case CMDTAG_" does not yield any results.
As far as I understand, we'd only be able to get rid of a default case
if we had a switch that included
On Mon, 15 Apr 2024 at 11:47, Peter Geoghegan wrote:
>
> On Sun, Apr 14, 2024 at 7:20 PM David Rowley wrote:
> > It's the "underlying server version" that I think needs some
> > clarification. It's unclear if the minor version must match or just
> > the major version number. The preceding
On Sat, Apr 13, 2024 at 10:40:35AM -0300, Ranier Vilela wrote:
> This sounds a little confusing to me.
> Is the project policy to *tolerate* dereferencing NULL pointers?
> If this is the case, no problem, using Assert would serve the purpose of
> protecting against these errors well.
In most
On Sun, Apr 14, 2024 at 8:04 PM Michael Paquier wrote:
> Assuming that a query ID will be always stable across major versions
> is overconfident, I think. As Peter said, like for WAL, we may face
> cases where a slight breakage for a subset of queries could be
> justified, and pg_stat_statement
Em dom., 14 de abr. de 2024 às 20:38, David Rowley
escreveu:
> On Mon, 15 Apr 2024 at 11:17, Ranier Vilela wrote:
> > Coverity has reported some out-of-bounds bugs
> > related to the GetCommandTagName function.
> >
> > The size of the array is defined by COMMAND_TAG_NEXTTAG enum,
> > whose
On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
> I was recently asked internally about the stability guarantees we
> offer for queryid. My answer consisted of:
>
> 1. We cannot change Node enums in minor versions
> 2. We're *unlikely* to add fields to Node types in minor versions,
hi.
one minor issue.
within ATPostAlterTypeCleanup, we call ATPostAlterTypeParse:
ATPostAlterTypeParse(oldId, relid, InvalidOid,
(char *) lfirst(def_item),
wqueue, lockmode, tab->rewrite);
function ATPostAlterTypeParse is:
static void
ATPostAlterTypeParse(Oid oldId, Oid oldRelId, Oid refRelId,
On Wed, Apr 3, 2024 at 1:30 PM Paul Jungwirth
wrote:
>
> On 3/24/24 00:38, Peter Eisentraut wrote:> I have committed the patches
> > v33-0001-Add-temporal-FOREIGN-KEYs.patch and
> > v33-0002-Support-multiranges-in-temporal-FKs.patch
> > (together).
>
> Hi Hackers,
>
> I found some problems with
David Rowley writes:
> I think the change makes sense. I don't see any good reason to define
> COMMAND_TAG_NEXTTAG or force the compiler's hand when it comes to
> sizing that array.
> Clearly, Coverity does not understand that we'll never call any of
> those GetCommandTag* functions with
On Sun, Apr 14, 2024 at 7:20 PM David Rowley wrote:
> It's the "underlying server version" that I think needs some
> clarification. It's unclear if the minor version must match or just
> the major version number. The preceding paragraph does mention:
>
> "Furthermore, it is not safe to assume
Hi all,
While bumping on a problem with an extension that relied on pg_config
--libs, I've been recalled about the fact that pg_config produces no
output for --libs/--ldflags_ex when building with meson,
src/include/meson.build including the following on HEAD since meson
has been introduced in
On Mon, 15 Apr 2024 at 11:17, Ranier Vilela wrote:
> Coverity has reported some out-of-bounds bugs
> related to the GetCommandTagName function.
>
> The size of the array is defined by COMMAND_TAG_NEXTTAG enum,
> whose value currently corresponds to 193.
> Since enum items are evaluated starting
I was recently asked internally about the stability guarantees we
offer for queryid. My answer consisted of:
1. We cannot change Node enums in minor versions
2. We're *unlikely* to add fields to Node types in minor versions, and
if we did we'd likely be leaving them out of the jumble calc, plus
Hi,
Per Coverity.
Coverity has reported some out-of-bounds bugs
related to the GetCommandTagName function.
CID 1542964: (#1 of 1): Out-of-bounds access (OVERRUN)
7. overrun-call: Overrunning callee's array of size 193 by passing argument
commandtag (which evaluates to 193) in call to
Hi,
To see how well we're doing testing newly introduced code, I computed the
differential code coverage between REL_16_STABLE and HEAD.
While arguably comparing HEAD to the the merge-base between REL_16_STABLE and
HEAD would be more accurate, I chose REL_16_STABLE because we've backpatched
While working on the "Combine Prune and Freeze records emitted by
vacuum" patch [1], I wished we would have an easier way to test pruning.
There's a lot of logic with following HOT chains etc., and it's very
hard to construct all those scenarios just by INSERT/UPDATE/DELETE
commands. In
On 07.04.2024 02:07, Thomas Munro wrote:
So this is the version I plan to commit.
+bool
+EvictUnpinnedBuffer(Buffer buf)
+{
...
+/* This will return false if it becomes dirty or someone else pins it. */
+result = InvalidateVictimBuffer(desc);
+
+UnpinBuffer(desc);
+
+return
I've pushed this, including backpatching the two fixes. I've reduced the
amount of data needed by the test, and made sure it works on 32-bits too
(I was a bit worried it might be sensitive to that, but that seems not
to be the case).
There's still the question of maybe removing the differences
Here is a first attempt at a proper patch set based on the discussion thus
far. I've split it up into several small patches for ease of review, which
is probably a bit excessive. If this ever makes it to commit, they could
likely be combined.
--
Nathan Bossart
Amazon Web Services:
On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson wrote:
>
> > On 12 Apr 2024, at 23:15, Heikki Linnakangas wrote:
> > Here's a few more. I've accumulate these over the past couple of months,
> > keeping them stashed in a branch, adding to it whenever I've spotted a
> > minor typo while reading
On 12.04.24 19:03, Heikki Linnakangas wrote:
As we accumulate more PG_TEST_EXTRA options, I think we should
categorize the tests by the capabilities they need or the risk
associated, rather than by test names.
This was recently discussed at [0], without success.
[0]:
I think the output need to change, like this:
postgres=# \du+
List of roles
Role name | Login | Attributes | Password | Valid until | Connection limit |
Description
48 matches
Mail list logo
