On Tue, Apr 16, 2024 at 5:06 PM shveta malik wrote:
>
> On Tue, Apr 16, 2024 at 1:45 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Hou,
> >
> > > Kuroda-San reported an issue off-list that:
> > >
> > > If user execute ALTER SUBSCRIPTION SET (failover) command inside a txn
> > > block
> > >
On Tue, Apr 09, 2024 at 09:26:49AM -0700, Jacob Champion wrote:
> On Tue, Apr 9, 2024 at 7:30 AM Andrew Dunstan wrote:
>> I think Michael's point was that if we carry the code we should test we
>> can run it. The other possibility would be just to remove it. I can see
>> arguments for both.
>
>
> 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.
I looked at the patch set. With the help of
On 4/12/24 06:44, Tom Lane wrote:
* It seems like root->processed_groupClause no longer has much to do
with the grouping behavior, which is scary given how much code still
believes that it does. I suspect there are bugs lurking there, and
1. Analysing the code, processed_groupClause is used
While examining pg_upgrade on a cluster with many tables (created with the
command in [0]), I noticed that a huge amount of pg_dump time goes towards
the binary_upgrade_set_pg_class_oids() function. This function executes a
rather expensive query for a single row, and this function appears to be
Jelte Fennema-Nio writes:
> As I expected this problem was indeed fairly easy to address by still
> building "backend/parser" before "interfaces". See attached patch.
I think we should hold off on this. I found a simpler way to address
ecpg's problem than what I sketched upthread. I have a
It was brought to my attention [0] that we probably should be checking for
the OSXSAVE bit instead of the XSAVE bit when determining whether there's
support for the XGETBV instruction. IIUC that should indicate that both
the OS and the processor have XGETBV support (not just the processor).
I've
On Wed, Apr 17, 2024 at 10:31:52AM +0200, Alvaro Herrera wrote:
> On 2024-Apr-17, Michael Paquier wrote:
>> Yeah, that would be easy enough to track but I was wondering about
>> adding the relkind instead. Still, one thing that I found confusing
>> is the dump generated in this case, as it would
On Mon, Apr 15, 2024 at 9:46 PM Amit Langote wrote:
> On Sat, Apr 13, 2024 at 11:12 PM jian he wrote:
> > On Fri, Apr 12, 2024 at 5:44 PM Amit Langote
> > wrote:
> > >
> > > > elog(ERROR, "unrecognized json wrapper %d", wrapper);
> > > > should be
> > > > elog(ERROR, "unrecognized json wrapper
On Sat, Mar 23, 2024 at 3:23 PM Tom Lane wrote:
> Thomas Munro writes:
> > . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago )
>
> Yeah. Now that we require C99 it's probably reasonable to assume
> that those things exist. I wouldn't be in favor of ripping out our
>
On 4/18/24 00:14, Robert Haas wrote:
On Tue, Apr 16, 2024 at 9:25 AM Robert Haas wrote:
On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote:
Anyway, I think it should be fixed or documented as a caveat since it
causes a hard failure on restore.
Alright, I'll look into this.
Here's a
On 4/18/24 01:03, Robert Haas wrote:
On Tue, Apr 16, 2024 at 7:25 PM David Steele wrote:
But it will not go out of its way to perform checks that are unrelated
to its documented purpose. And I don't think it should, especially if
we have another tool that already does that.
I'm not averse to
Hi,
Uh, huh.
On 2024-04-17 15:42:28 +0200, Christoph Berg wrote:
> Re: Andres Freund
> > https://git.postgresql.org/pg/commitdiff/e6927270cd18d535b77cbe79c55c6584351524be
>
> This commit broke VPATH builds when the original source directory
> contains symlinks.
I.e. a symlink to the source
Hi,
On 2024-04-17 16:16:55 -0400, Robert Haas wrote:
> In the "Differential code coverage between 16 and HEAD" thread, Andres
> pointed out that there wasn't test case coverage for
> pg_combinebackup's code to handle files in tablespaces. I looked at
> adding that, and as nobody could possibly
Hi,
We have a fair amount of code that uses non-constant function level static
variables for read-only data. Which makes little sense - it prevents the
compiler from understanding
a) that the data is read only and can thus be put into a segment that's shared
between all invocations of the
In the "Differential code coverage between 16 and HEAD" thread, Andres
pointed out that there wasn't test case coverage for
pg_combinebackup's code to handle files in tablespaces. I looked at
adding that, and as nobody could possibly have predicted, found a bug.
Here's a 2-patch series to (1)
On 2024-04-16 07:32:55 +0900, Michael Paquier wrote:
> On Mon, Apr 15, 2024 at 11:57:20AM -0700, Andres Freund wrote:
> > GlobalVisTestNonRemovableHorizon()/GlobalVisTestNonRemovableFullHorizon()
> > only
> > existed for snapshot_too_old - but that was removed in f691f5b80a8. I'm
> > inclined to
Hi,
On 2024-04-15 15:13:51 -0400, Robert Haas wrote:
> It would of course have been nice to have done this sooner, but I don't
> think waiting for next release cycle will make anything better.
I don't really know how it could have been discovered sooner. We don't have
any infrastructure for
Thomas Munro writes:
> This test suite is passing on pollock because it doesn't have IO::Pty
> installed. Could you try uninstalling that perl package for now, so
> we can see what breaks next?
If that's inconvenient for some reason, you could also skip the
tab-completion test by setting
Andres Freund writes:
> Hi,
>
> On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote:
>> Andres Freund writes:
>> > I think the manual work for writing signatures in sgml is not
>> > insignificant,
>> > nor is the volume of sgml for them. Manually maintaining the signatures
>> > makes
Hackers,
I often use the ctrl-click on the link after getting help in psql. A
great feature.
Challenge, when there is no help, you don't get any link.
My thought process is to add a default response that would take them to
https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F={TOKEN}
On 2024-Apr-16, Justin Pryzby wrote:
> Yes, this fixes the issue I reported.
Excellent, thanks for confirming.
> BTW, that seems to be the same issue Andrew reported in January.
> https://www.postgresql.org/message-id/CAJnzarwkfRu76_yi3dqVF_WL-MpvT54zMwAxFwJceXdHB76bOA%40mail.gmail.com
That's
On Thu, Apr 18, 2024 at 1:40 AM Marcel Hofstetter
wrote:
> Using gnu tar helps to make pg_basebackup work.
Thanks! I guess that'll remain a mystery.
> It fails now at a later step.
Oh, this rings a bell:
[14:54:58] t/010_tab_completion.pl ..
Dubious, test returned 29 (wstat 7424, 0x1d00)
We
Hi,
On 2024-04-17 14:39:14 +0300, Alexander Korotkov wrote:
> On Wed, Apr 17, 2024 at 2:37 PM Alexander Korotkov
> wrote:
> > I've invested more time into polishing this. I'm intended to push
> > this. Could you, please, take a look before?
>
> Just after sending this I spotted a typo
Hi,
On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote:
> Andres Freund writes:
> > I think the manual work for writing signatures in sgml is not insignificant,
> > nor is the volume of sgml for them. Manually maintaining the signatures
> > makes
> > it impractical to significantly
Hi,
On 2024-04-17 02:46:53 -0400, Corey Huinker wrote:
> > > This sounds to me like it would be a painful exercise with not a
> > > lot of benefit in the end.
> >
> > Maybe we could _verify_ the contents of func.sgml against pg_proc.
> >
>
> All of the functions redefined in
>
> And it's very inconsistent. For example, some functions use
> tags for optional parameters, others use square brackets, and some use
> VARIADIC to indicate variadic parameters, others use
> ellipses (sometimes in tags or brackets).
Having just written a couple of those functions, I wasn't
On Thu, Apr 11, 2024 at 03:54:07PM -0400, Corey Huinker wrote:
> At the request of a few people, attached is an attempt to move stats to
> DATA/POST-DATA, and the TAP test failure that results from that.
>
> The relevant errors are confusing, in that they all concern GRANT/REVOKE,
> and the fact
On 4/15/24 20:35, Tomas Vondra wrote:
> ...
>
> Attached is the cleanup I thought about doing earlier in this patch [1]
> to make the code more like btree. The diff might make it seem like a big
> change, but it really just moves the merge code into a separate function
> and makes it use using the
Peter Eisentraut writes:
> I checked the generated ecpg_config.h with make and meson, and the meson
> one is missing
> #define HAVE_LONG_LONG_INT 1
> This is obviously quite uninteresting, since that is required by C99.
> But it would be more satisfactory if we didn't have discrepancies like
I did notice (I meant to point out) that I have concerns about this
> part of the new uniqueness check code:
> "
> if (P_IGNORE(topaque) || !P_ISLEAF(topaque))
> break;
> "
My concern here is with the !P_ISLEAF(topaque) test -- it shouldn't be
> required
I agree. But I didn't see the need
On Tue, Apr 16, 2024 at 7:25 PM David Steele wrote:
> Except that we are running pg_combinebackup on the incremental, which
> the user might reasonably expect to check backup integrity. It actually
> does a bunch of integrity checks -- but not this one.
I think it's a bad idea to duplicate all
On Wed, 17 Apr 2024 at 16:00, Tom Lane wrote:
> Break gram.y (say, misspell some token in a production) and
> see what happens. The behavior's likely to be timing sensitive
> though.
Thanks for clarifying. It took me a little while to break gram.y in
such a way that I was able to consistently
I checked the generated ecpg_config.h with make and meson, and the meson
one is missing
#define HAVE_LONG_LONG_INT 1
This is obviously quite uninteresting, since that is required by C99.
But it would be more satisfactory if we didn't have discrepancies like
that. Note that we also kept
On 4/16/24 22:33, Tomas Vondra wrote:
> On 4/15/24 20:35, Tomas Vondra wrote:
>> On 4/15/24 10:18, Tomas Vondra wrote:
>
> ...
>
> That is, no parallel index builds on temporary tables. Which means the
> test is not actually testing anything :-( Much more stable, but not very
> useful for finding
On Tue, Apr 16, 2024 at 9:25 AM Robert Haas wrote:
> On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote:
> > Anyway, I think it should be fixed or documented as a caveat since it
> > causes a hard failure on restore.
>
> Alright, I'll look into this.
Here's a patch.
--
Robert Haas
EDB:
Jelte Fennema-Nio writes:
> How can I test if this actually happens? Because it sounds like if
> that indeed happens it should be fixable fairly easily.
Break gram.y (say, misspell some token in a production) and
see what happens. The behavior's likely to be timing sensitive
though.
Re: Andres Freund
> https://git.postgresql.org/pg/commitdiff/e6927270cd18d535b77cbe79c55c6584351524be
This commit broke VPATH builds when the original source directory
contains symlinks.
The $PWD is /home/myon/postgresql/pg/master, but the actual directory
is
Hi Thomas
Using gnu tar helps to make pg_basebackup work.
It fails now at a later step.
Best regards,
Marcel
Am 17.04.2024 um 10:52 schrieb Thomas Munro:
On Wed, Apr 17, 2024 at 7:17 PM Marcel Hofstetter
wrote:
Is there a way to configure which tar to use?
gnu tar would be available.
On 13.04.24 10:25, Heikki Linnakangas wrote:
Something like the below would appear to fix that:
diff --git a/meson.build b/meson.build
index 43fad5323c0..cdfd31377d1 100644
--- a/meson.build
+++ b/meson.build
@@ -2301,6 +2301,14 @@ decl_checks += [
['pwritev', 'sys/uio.h'],
]
+# Check
On 29.03.24 02:42, David G. Johnston wrote:
We do use the term "stand-alone composite" in create type so I'm
inclined to use it instead of "composite created with CREATE TYPE";
especially in the error messages; I'm a bit more willing to add the
cross-reference to create type in the user docs.
On Wed, 17 Apr 2024 at 13:41, Peter Eisentraut wrote:
>
> On 10.04.24 17:33, Tom Lane wrote:
> > The immediate question then is do we want to take Jelte's patch
> > as a way to ameliorate the pain meanwhile. I'm kind of down on
> > it, because AFAICS what would happen if you break the core
> >
Peter Eisentraut:
On 29.03.24 19:47, walt...@technowledgy.de wrote:
> - uuid = dependency('ossp-uuid', required: true)
> + # upstream is called "uuid", but many distros change this to
"ossp-uuid"
> + uuid = dependency('ossp-uuid', 'uuid', required: true)
How would this behave if
On 29.03.24 19:47, walt...@technowledgy.de wrote:
> -uuid = dependency('ossp-uuid', required: true)
> +# upstream is called "uuid", but many distros change this to
"ossp-uuid"
> +uuid = dependency('ossp-uuid', 'uuid', required: true)
How would this behave if you have only uuid.pc
On 10.04.24 17:33, Tom Lane wrote:
The immediate question then is do we want to take Jelte's patch
as a way to ameliorate the pain meanwhile. I'm kind of down on
it, because AFAICS what would happen if you break the core
grammar is that (most likely) the failure would be reported
against ecpg
On Wed, Apr 17, 2024 at 2:37 PM Alexander Korotkov wrote:
> On Tue, Apr 16, 2024 at 7:42 PM Alexander Korotkov
> wrote:
> > On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote:
> > > On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote:
> > > > On Tue, Apr 16, 2024 at 1:48 AM Andres Freund
On Tue, Apr 16, 2024 at 7:42 PM Alexander Korotkov wrote:
>
> On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote:
> > On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote:
> > > On Tue, Apr 16, 2024 at 1:48 AM Andres Freund wrote:
> > > > On 2024-03-06 14:17:23 +0200, Alexander Korotkov
Andres Freund writes:
> Definitely shouldn't be the same in all cases, but I think there's a decent
> number of cases where they can be the same. The differences between the two is
> often minimal today.
>
> Entirely randomly chosen example:
>
> { oid => '2825',
> descr => 'slope of the
BTW if nothing else, this thread led me to discover a 18-month-old typo
in the Spanish translation of pg_dump:
-msgstr " --no-tablespaces no volcar métodos de acceso de tablas\n"
+msgstr " --no-table-access-method no volcar métodos de acceso de tablas\n"
Oops.
--
Álvaro
On 2024-Apr-16, Michael Paquier wrote:
there are already too many of them. Perhaps we should begin
tracking all that as a set of bitmasks, then plug in the tracked state
in shmem for consumption in some SQL function.
Yes, it sounds reasonable.
Let me implement some initial draft and come
On 13.04.24 10:25, Heikki Linnakangas wrote:
There's also this in llvmjit.c:
if (llvm_opt3_orc)
{
#if defined(HAVE_DECL_LLVMORCREGISTERPERF) &&
HAVE_DECL_LLVMORCREGISTERPERF
if (jit_profiling_support)
LLVMOrcUnregisterPerf(llvm_opt3_orc);
#endif
On Wed, Apr 17, 2024 at 7:17 PM Marcel Hofstetter
wrote:
> Is there a way to configure which tar to use?
>
> gnu tar would be available.
>
> -bash-5.1$ ls -l /usr/gnu/bin/tar
> -r-xr-xr-x 1 root bin 1226248 Jul 1 2022 /usr/gnu/bin/tar
Cool. I guess you could fix the test either by
On Wed, Apr 17, 2024 at 1:04 PM Sharique Muhammed
wrote:
> Hi,
>
> I was looking for a pattern to destroy a hashtable (dynahash).allocated
> in TopMemoryContext
> I found one pattern : create_seq_hashtable uses TopMemoryContext
> memory context to create hash table. It calls hash_destroy in
>
On 2024-Apr-17, Michael Paquier wrote:
> Yeah, that would be easy enough to track but I was wondering about
> adding the relkind instead. Still, one thing that I found confusing
> is the dump generated in this case, as it would mix the SET and the
> ALTER TABLE commands so one reading the dumps
On Wed, 17 Apr 2024 at 14:10, Michael Paquier wrote:
> On Tue, Apr 16, 2024 at 03:31:49PM +0900, Michael Paquier wrote:
>> Indeed, thanks! Will fix and double-check the surroundings.
>
> And fixed this one.
Thanks for the pushing!
--
Regards,
Japin Li
On Wed, Apr 17, 2024 at 09:50:02AM +0200, Alvaro Herrera wrote:
> I think it's easy enough to add a "bool ispartitioned" to TableInfo and
> use an ALTER TABLE or rely on the GUC depending on that -- seems easy
> enough.
Yeah, that would be easy enough to track but I was wondering about
adding the
On 2024-Apr-17, Alvaro Herrera wrote:
> Hmm, cannot we simply add a USING clause to the CREATE TABLE command for
> partitioned tables? That would override the
> default_table_access_method, so it should give the correct result, no?
Ah, upthread you noted that pg_restore-time
On 2024-Apr-17, Michael Paquier wrote:
> 2) We could limit these extra ALTER TABLE commands to be generated for
> partitioned tables. This is kind of confusing as resulting dumps
> would mix SET commands for default_table_access_method that would
> affect tables with physical storage, while
Hi,
I was looking for a pattern to destroy a hashtable (dynahash).allocated
in TopMemoryContext
I found one pattern : create_seq_hashtable uses TopMemoryContext
memory context to create hash table. It calls hash_destroy in
ResetSequenceCaches. hash_destroy will destroy the memory
On Wed, Apr 17, 2024 at 4:28 PM torikoshia wrote:
>
> On 2024-04-16 13:16, Masahiko Sawada wrote:
> > On Tue, Apr 2, 2024 at 7:34 PM torikoshia
> > wrote:
> >>
> >> On 2024-04-01 11:31, Masahiko Sawada wrote:
> >> > On Fri, Mar 29, 2024 at 11:54 AM torikoshia
> >> > wrote:
> >> >>
> >> >> On
On 2024-04-16 13:16, Masahiko Sawada wrote:
On Tue, Apr 2, 2024 at 7:34 PM torikoshia
wrote:
On 2024-04-01 11:31, Masahiko Sawada wrote:
> On Fri, Mar 29, 2024 at 11:54 AM torikoshia
> wrote:
>>
>> On 2024-03-28 21:54, Masahiko Sawada wrote:
>> > On Thu, Mar 28, 2024 at 9:38 PM torikoshia
Hi
Is there a way to configure which tar to use?
gnu tar would be available.
-bash-5.1$ ls -l /usr/gnu/bin/tar
-r-xr-xr-x 1 root bin 1226248 Jul 1 2022 /usr/gnu/bin/tar
Which tar file is used?
I could try to untar manually to see what happens.
Best regards,
Marcel
Am
Agree +1,From a dba perspective, I would prefer that this parameter can be
dynamically modified, rather than adding a new parameter,What is more
difficult is how to smoothly reach the target value when the setting is
considered to be too large and needs to be lowered.
Regards
On Tue, 16 Apr
>
> > This sounds to me like it would be a painful exercise with not a
> > lot of benefit in the end.
>
> Maybe we could _verify_ the contents of func.sgml against pg_proc.
>
All of the functions redefined in catalog/system_functions.sql complicate
using pg_proc.dat as a doc generator or source
On 24.10.23 22:13, Alexander Korotkov wrote:
On Wed, Sep 28, 2022 at 11:44 AM Aleksander Alekseev
wrote:
I think, this patch was marked as "Waiting on Author", probably, by mistake.
Since recent changes were done without any significant code changes and CF bot how happy
again.
I'm going to
On Tue, Apr 16, 2024 at 03:31:49PM +0900, Michael Paquier wrote:
> Indeed, thanks! Will fix and double-check the surroundings.
And fixed this one.
--
Michael
signature.asc
Description: PGP signature
66 matches
Mail list logo
