On Thu, 18 Apr 2024 at 10:50, Peter Eisentraut wrote:
> Why exactly is this an open item? Is there anything wrong with the
> existing feature?
The name of the GUC backtrace_on_internal_error is so specific that
it's impossible to extend our backtrace behaviour in future releases
without adding
On 16.04.24 10:17, Daniel Gustafsson wrote:
I forgot (and didn't check) that we backpatched 01e6f1a842f4, with that in mind
I agree that we should backpatch 0003 as well to put LibreSSL on par as much as
we can. 0004 is a fix for the LibreSSL support, not adding anything new, so
pushing that to
On 18 April 2024 14:15:43 GMT+03:00, Sriram RK wrote:
>Thanks Noah and Team,
>
>We (IBM-AIX team) looked into this issue
>
>https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
>
>This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
>have issues. But we
On 10.04.24 16:14, Jelte Fennema-Nio wrote:
(The CEK can't be rotated easily, since
that would require reading out all the data from a table/column and
reencrypting it. We could/should add some custom tooling for that,
but it wouldn't be a routine operation.)
This seems like something that
On 2024-Apr-15, Justin Pryzby wrote:
> Here's a couple more issues affecting upgrades from v16 to v17.
>
> postgres=# CREATE TABLE a(i int NOT NULL); CREATE TABLE b(i int PRIMARY KEY)
> INHERITS (a);
> pg_restore: error: could not execute query: ERROR: constraint
>
On Thu, 18 Apr 2024 at 09:02, Michael Paquier wrote:
>
> On Fri, Apr 12, 2024 at 09:36:36AM +0900, Michael Paquier wrote:
> > log_backtrace speaks a bit more to me as a name for this stuff because
> > it logs a backtrace. Now, there is consistency on HEAD as well
> > because these GUCs are all
Thanks Noah and Team,
We (IBM-AIX team) looked into this issue
https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
have issues. But we verified that this issue is resolved with the newer
compiler
Hi,
> I guess the argument against inserting an enum element at the end is
> that a switch statement on the enum value might generate a compiler
> warning if it didn't have a default clause.
Fair point. PFA the alternative version of the patch.
--
Best regards,
Aleksander Alekseev
On 4/18/24 09:10, Michael Paquier wrote:
> On Sun, Apr 07, 2024 at 10:54:56AM -0400, Melanie Plageman wrote:
>> I've added an open item [1], because what's one open item when you can
>> have two? (me)
>
> And this is still an open item as of today. What's the plan to move
> forward here?
AFAIK
On 16.04.24 17:17, Anton Voloshin wrote:
On 10/03/2024 12:03, Peter Eisentraut wrote:
Committed, thanks.
This commit (7b8e2ae2f) have turned cpluspluscheck script into a
--cplusplus option for headerscheck. I propose to update the
src/tools/pginclude/README correspondingly, please see the
> Let's start by setting up a new AIX buildfarm member. Regardless of what we
> do with v17, we continue to support AIX on the stable branches, and we really
> need a buildfarm member to keep the stable branches working anyway.
Thanks Heikki. We had already build the source code(v17+
On 18/04/2024 00:39, Andres Freund wrote:
>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
Hi,
> Laurenz Albe writes:
> > Patch v3 is attached.
>
> I agree with documenting this hazard, but I think it'd be better
> to do so in the "Triggers" chapter. There is no hazard unless
> you are writing user-defined triggers, which is surely far fewer
> people than use foreign keys. So I
On Thu, Apr 18, 2024 at 2:37 AM Dagfinn Ilmari Mannsåker
wrote:
>
> 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,
> >> >
On Thu, Apr 18, 2024 at 11:40 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shveta,
>
> Sorry for delay response. I missed your post.
>
> > +1.
> >
> > Similar to ALTER SUB, CREATE SUB also needs to be fixed. This is
> > because we call alter_replication_slot in CREATE SUB as well, for the
> > case
On 4/18/24 09:07, Michael Paquier wrote:
> On Thu, Feb 29, 2024 at 01:20:39PM +0100, Alvaro Herrera wrote:
>> I think it's not an issue, or rather that we should not try to guess.
>> Instead make it a simple rule: if aminsert is called, then
>> aminsertcleanup must be called afterwards, period.
>>
Hi, Dmitry!
On Mon, Apr 15, 2024 at 6:26 PM Dmitry Koval wrote:
>
> Hi!
>
> > Please, find a my version of this fix attached.
>
> Is it possible to make a small addition to the file v6-0001 ... .patch
> (see attachment)?
>
> Most important:
> 1) Line 19:
>
> + mergePartName =
Hi, Andrei!
On Thu, Apr 18, 2024 at 11:54 AM Andrei Lepikhov
wrote:
> On 4/12/24 06:44, Tom Lane wrote:
> > * Speaking of pathnodes.h, PathKeyInfo is a pretty uninformative node
> > type name, and the comments provided for it are not going to educate
> > anybody. What is the "association"
On 2024-04-18 Th 02:04, Michael Paquier wrote:
On Wed, Apr 10, 2024 at 07:47:38AM -0400, Andrew Dunstan wrote:
Here's v2 of the cleanup patch 4, that fixes some more typos kindly pointed
out to me by Alexander Lakhin.
I can see that this has been applied as of 42fa4b660143 with some
extra
On Thu, Apr 18, 2024 at 12:35 PM shveta malik wrote:
>
> To fix above issues, these changes have been made in v7:
Please find v8 attached. Changes are:
1) It fixes ShutDownSlotSync() issue, where we perform
kill(SlotSyncCtx->pid). There are chances that after we release
spin-lock and before we
Thank you tom.
SKIP_READLINE_TESTS works. margay is now green again.
Best regards,
Marcel
Am 17.04.2024 um 21:12 schrieb Tom Lane:
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,
On Wed, Apr 17, 2024 at 5:50 PM Andres Freund wrote:
> > +If there are tablespace present in the backup, include tablespace_map as
> > +a keyword parameter whose values is a hash. When tar_program is used, the
> > +hash keys are tablespace OIDs; otherwise, they are the tablespace pathnames
> >
On 2024-Jan-25, Andrew Bille wrote:
> Starting from b0e96f31, pg_upgrade fails with inherited NOT NULL constraint:
> For example upgrade from 9c13b6814a (or REL_12_STABLE .. REL_16_STABLE) to
> b0e96f31 (or master) with following two tables (excerpt from
> src/test/regress/sql/rules.sql)
>
>
On Wed, Apr 10, 2024 at 6:13 AM Peter Eisentraut wrote:
> Obviously, it's early days, so there will be plenty of time to have
> discussions on various other aspects of this patch. I'm keeping a keen
> eye on the discussion of protocol extensions, for example.
I think the way that you handled
Em qui., 18 de abr. de 2024 às 14:16, Andres Freund
escreveu:
> Hi,
>
> On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote:
> > On 18/04/2024 00:39, Andres Freund wrote:
> > >There are lots of places that could benefit from adding 'static
> > >const'.
> >
> > I found a few more places.
>
> Good
> 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
On Tue, Apr 9, 2024 at 4:00 AM Martín Marqués wrote:
> I've attached two patches, the first one is just neat-picking things I
> found when I first read the docs.
I pushed a commit to remove the spurious "the" that you found, but I
don't really agree with the other changes. They all seem
Hi,
On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote:
> On 18/04/2024 00:39, Andres Freund wrote:
> >There are lots of places that could benefit from adding 'static
> >const'.
>
> I found a few more places.
Good catches.
> Patch 004
>
> The opposite would also help, adding static.
> In
Hi,
On 2024-04-18 09:03:21 -0400, Robert Haas wrote:
> On Wed, Apr 17, 2024 at 5:50 PM Andres Freund wrote:
> > > +If there are tablespace present in the backup, include tablespace_map as
> > > +a keyword parameter whose values is a hash. When tar_program is used, the
> > > +hash keys are
>
> I havent dealt with variadic yet, since the two styles are visually
> different, not just markup (... renders as [...]).
>
> The two styles for variadic are the what I call caller-style:
>
>concat ( val1 "any" [, val2 "any" [, ...] ] )
>format(formatstr text [, formatarg "any" [, ...]
On Tue, Apr 9, 2024 at 5:46 AM Tomas Vondra
wrote:
> What we could do is detect this in pg_combinebackup, and either just
> disable checksums with a warning and hint to maybe enable them again. Or
> maybe just print that the user needs to disable them.
>
> I was thinking maybe we could detect
On 2024-Apr-18, Justin Pryzby wrote:
> That seems like it could be important. I considered but never actually
> test your patch by pg_upgrading across major versions.
It would be a welcome contribution for sure. I've been doing it rather
haphazardly, which is not great.
> BTW, this works up
On 18.04.24 19:11, Andres Freund wrote:
Thoughts about when to apply these? Arguably they're fixing mildly broken
code, making it appropriate to fix in 17, but it's also something that we
could end up fixing for a while...
Yeah, let's keep these for later. They are not regressions, and there
On 2024-04-18 Th 11:39, Alvaro Herrera wrote:
On 2024-Apr-18, Alvaro Herrera wrote:
On 2024-Apr-18, Alvaro Herrera wrote:
Lastly, make two changes to pg_dump: 1) do not try to drop a not-null
constraint that's marked as inherited; this allows a dump to restore
with no errors if a table with
> On 18 Apr 2024, at 20:11, Robert Haas wrote:
> 2. As (1), but make check_control_files() emit a warning message when
> the problem case is detected.
Being in the post-freeze part of the cycle, this seems like the best option.
> 3. As (2), but also add a command-line option to
On Thu, 18 Apr 2024 at 13:25, Peter Eisentraut wrote:
> Hopefully, the reason for key rotation is mainly that policies require
> key rotation, not that keys get compromised all the time.
These key rotation policies are generally in place to reduce the
impact of a key compromise by limiting the
On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote:
>> On 18 Apr 2024, at 06:17, Nathan Bossart wrote:
>
>> The attached work-in-progress patch speeds up 'pg_dump --binary-upgrade'
>> for this case. Instead of executing the query in every call to the
>> function, we can execute
Aleksander Alekseev writes:
>> I agree with documenting this hazard, but I think it'd be better
>> to do so in the "Triggers" chapter. There is no hazard unless
>> you are writing user-defined triggers, which is surely far fewer
>> people than use foreign keys. So I suggest something like the
On Thu, Apr 18, 2024 at 2:13 AM Donghang Lin wrote:
> It's triggered when a scankey's strategy is set to invalid. While for a
> descending ordered column,
> the strategy needs to get fixed to its commute strategy. That doesn't work if
> the strategy is invalid.
The problem is that
Hi,
PostgreSQL 17 Beta 1 is planned to be release on May 23, 2024. Please
continue your hard work on closing out open items[1] ahead of the
release and have the fixes targeted for the release committed by May 18,
2024.
Thanks - it's very exciting that we're at this point in the release
Hi,
On 2024-04-18 10:33:30 +0200, Peter Eisentraut wrote:
> > Attached are fixes for struct option and a few more occurrences I've found
> > with a bit of grepping.
>
> These look good to me.
Thoughts about when to apply these? Arguably they're fixing mildly broken
code, making it appropriate to
On Thu, Apr 18, 2024 at 1:45 PM Andres Freund wrote:
> I was really just remarking on this from the angle of a test writer. I know
> that our interfaces around this suck...
>
> For tests, do we really need to set anything on a per-tablespace basis? Can't
> we instead just reparent all of them to
On 2024-Apr-18, Alvaro Herrera wrote:
> On 2024-Apr-18, Alvaro Herrera wrote:
>
> > Lastly, make two changes to pg_dump: 1) do not try to drop a not-null
> > constraint that's marked as inherited; this allows a dump to restore
> > with no errors if a table with a PK inherits from another which
On 2024-04-17 23:10:53 -0400, Tom Lane wrote:
> 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
>
Hi,
On 2024-04-18 11:15:43 +, Sriram RK wrote:
> We (IBM-AIX team) looked into this issue
>
> https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
>
> This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
> have issues. But we verified that this issue
On Thu, Feb 22, 2024 at 4:49 PM Michael Banck wrote:
> Hi,
>
> On Wed, Jan 24, 2024 at 02:50:52PM -0500, Kirk Wolak wrote:
> > On Mon, Jan 22, 2024 at 1:30 AM Kirk Wolak wrote:
> > > On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson
> wrote:
> > >> > On 19 Jan 2024, at 23:09, Kirk Wolak
On Wed, Apr 17, 2024 at 7:09 PM David Steele wrote:
> I think here:
>
> + pg_basebackup only attempts to verify
>
> you mean:
>
> + pg_combinebackup only attempts to verify
>
> Otherwise this looks good to me.
Good catch, thanks. Committed with that change.
> Fair enough. I accept that your
Hello hackers,
When using a server built with clang (15, 18) with sanitizers enabled,
the last query in the following script:
SET parallel_setup_cost = 0;
SET min_parallel_table_scan_size = 0;
SELECT a::text INTO t FROM generate_series(1, 1000) a;
\timing on
SELECT string_agg(a, ',') FROM t
On 2024-Apr-18, Michael Paquier wrote:
> On Wed, Apr 17, 2024 at 10:31:52AM +0200, Alvaro Herrera wrote:
> > Hmm, maybe we should do a RESET of default_table_access_method before
> > printing the CREATE TABLE to avoid the confusion.
>
> A hard reset would make the business around currTableAM
On 17.04.24 19:47, Kirk Wolak wrote:
*Example:*
\h current_setting
No help available for "current_setting".
Try \h with no arguments to see available help.
https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F=current_setting
On 16.04.24 01:40, Jeff Davis wrote:
I'm not sure I understand all of the history behind pg_wchar, but it
seems to be some blend of:
(a) Postgres's own internal representation of a decoded character
(b) libc's wchar_t
(c) Unicode code point
For example, Postgres has its own
On Tue, Apr 16, 2024 at 08:11:49PM +0200, Alvaro Herrera wrote:
> This is still missing some cleanup and additional tests, of course.
> Speaking of which, I wonder if I should modify pg16's tests so that they
> leave behind tables set up in this way, to immortalize pg_upgrade
> testing.
That
On Thu, 18 Apr 2024 at 18:46, Robert Haas wrote:
> With regard to the Bind message, I suggest that we regard the protocol
> change as reserving a currently-unused bit in the message to indicate
> whether the value is pre-encrypted, without reference to the protocol
> extension. It could be legal
On 2024-Apr-13, jian he wrote:
> I wonder is there any incompatibility issue, or do we need to say something
> about the new behavior when dropping a key column?
Umm, yeah, maybe we should document it in ALTER TABLE DROP PRIMARY KEY
and in the release notes to note the different behavior.
>
On Mon, 15 Apr 2024 at 21:47, Dave Cramer wrote:
>> On Mon, 15 Apr 2024 at 19:52, Robert Haas wrote:
>> > surely it can't be right to use protocol
>> > version 3.0 to refer to a bunch of different things. But at the same
>> > time, surely we don't want clients to start panicking and bailing out
On Thu, Apr 18, 2024 at 02:08:28AM -0400, Corey Huinker wrote:
> Bar-napkin math tells me in a worst-case architecture and braindead byte
> alignment, we'd burn 64 bytes per struct, so the 100K tables cited would be
> about 6.25MB of memory.
That doesn't seem too terrible.
> The obvious
On Wed, Apr 17, 2024 at 7:56 PM David Steele wrote:
> Thanks! I've tested this and it works as advertised.
>
> Ideally I'd want an error on backup if there is a similar file in any
> data directories that would cause an error on combine, but I admit that
> it is vanishingly rare for users to put
Hi Alexander,
18.04.2024 13:35, Alexander Korotkov wrote:
The revised patchset is attached.
1) I've split the fix for the CommandCounterIncrement() issue and the
fix for relation persistence issue into a separate patch.
2) I've validated that the lock on the new partition is held in
On Thu, Apr 18, 2024 at 06:23:30PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-18, Justin Pryzby wrote:
>
> > BTW, this works up to v16 (although maybe it should not):
> >
> > | CREATE TABLE ip(id int PRIMARY KEY); CREATE TABLE ic(id int) INHERITS
> > (ip); ALTER TABLE ic ALTER id DROP NOT NULL;
Alexander Lakhin writes:
> Hi Alexander,
>
> 18.04.2024 13:35, Alexander Korotkov wrote:
>>
>> The revised patchset is attached.
>> 1) I've split the fix for the CommandCounterIncrement() issue and the
>> fix for relation persistence issue into a separate patch.
>> 2) I've validated that the
On 2024-Apr-18, Alexander Lakhin wrote:
> I think the feature implementation should also provide tab completion
> for SPLIT/MERGE.
I don't think that we should be imposing on feature authors or
committers the task of filling in tab-completion for whatever features
they contribute. I mean, if
On Thu, Apr 18, 2024 at 1:49 PM Jelte Fennema-Nio wrote:
> I think this is an interesting idea. I can indeed see use cases for
> e.g. inserting a new row based on another row (where the secret is the
> same).
>
> IMHO that means that we should also bump the protocol version for this
> change,
On Thu, Apr 18, 2024 at 3:25 PM Daniel Gustafsson wrote:
> I don't think this is the way to go, such an option will be plastered on to
> helpful tutorials which users will copy/paste from even when they don't need
> the option at all, only to disable checksums when there was no reason for
>
On Thu, Dec 14, 2017 at 08:51:06AM +0700, Ali Akbar wrote:
> Patch for adding check in pg_upgrade.
[...]
On Fri, Sep 29, 2023 at 11:36:42AM -0500, Justin Pryzby wrote:
> On Fri, Sep 29, 2023 at 09:16:35AM +0900, Michael Paquier wrote:
> > You mean when upgrading from an instance of 9.6 or older
On Thu, Apr 18, 2024 at 08:24:03PM +, Devulapalli, Raghuveer wrote:
>> This seems to contradict the note about doing step 3 at any point, and
>> given step 1 is the OSXSAVE check, I'm not following what this means,
>> anyway.
>
> It is recommended that you run the xgetbv code before you check
Kirk Wolak writes:
> On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut
> wrote:
>
>> On 17.04.24 19:47, Kirk Wolak wrote:
>> > *Example:*
>> > \h current_setting
>> > No help available for "current_setting".
>> > Try \h with no arguments to see available help.
>> >
>> >
On Thu, Apr 18, 2024 at 09:29:55PM +, Devulapalli, Raghuveer wrote:
> (1) Shouldn't it be: return (_xgetbv(0) & 0xe6) == 0xe6; ? Otherwise
> zmm_regs_available() will return false..
Yes, that's a mistake. I fixed that in v3.
> (2) Nitpick: avx512_popcnt_available and avx512_bw_available()
Hi,
Here's two patched to deal with this open item. 0001 is a trivial fix of
typos and wording, I moved it into a separate commit for clarity. 0002
does the actual fix - adding the index_insert_cleanup(). It's 99% the
patch Alvaro shared some time ago, with only some minor formatting
tweaks by
On Thu, Apr 18, 2024 at 10:11:08PM +, Devulapalli, Raghuveer wrote:
>> On that note, is it necessary to also check for avx512f? At the moment,
>> we are assuming that's supported if the other AVX-512 instructions are
>> available.
>
> No, it's not needed. There are no CPU's with
On Thu, Apr 18, 2024 at 11:22:24AM +0530, Amit Kapila wrote:
> +1 for option 2 as it sounds logical to me and consistent with ALTER
> SUBSCRIPTION. BTW, IIUC, you are referring to: "When altering the
> slot_name, the failover and two_phase property values of the named
> slot may differ from the
On Fri, Apr 19, 2024 at 6:01 AM Andres Freund wrote:
> On 2024-04-18 11:15:43 +, Sriram RK wrote:
> > We (IBM-AIX team) looked into this issue
> >
> > https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
> >
> > This is related to the compiler issue. The compilers
>
> Yeah, we can't expect everyone wanting to call a built-in function to
> know how they would define an equivalent one themselves. In that case I
> propos marking it up like this:
>
> format (
> formatstr text
> , formatarg "any"
> , ... )
> text
>
Looks good, but I guess I
On Thu, Apr 18, 2024 at 3:34 PM Jelte Fennema-Nio wrote:
> I really don't understand what exactly you're worried about. What do
> you expect will break when bumping the protocol version? As Dave said,
> clients should never bail out due to protocol version differences.
Sure, and I should never
On Thu, Apr 18, 2024 at 10:23:01AM -0500, Nathan Bossart wrote:
> On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote:
>> That does indeed seem like a saner approach. Since we look up the relkind we
>> can also remove the is_index parameter to binary_upgrade_set_pg_class_oids
>>
On Fri, Apr 19, 2024 at 12:57 AM Marcel Hofstetter
wrote:
> SKIP_READLINE_TESTS works. margay is now green again.
Great! FTR there was a third thing revealed by margay since you
enabled the TAP tests: commit e2a23576.
I would guess that the best chance of getting the readline stuff to
actually
On Thu, Apr 18, 2024 at 06:12:22PM +, Shankaran, Akash wrote:
> Good find. I confirmed after speaking with an intel expert, and from the
> intel AVX-512 manual [0] section 14.3, which recommends to check bit27. From
> the manual:
>
> "Prior to using Intel AVX, the application must identify
> On 18 Apr 2024, at 12:53, Peter Eisentraut wrote:
> Review of the latest batch:
Thanks for reviewing!
> 8 v9-0002-Remove-support-for-OpenSSL-1.0.2.patch
>
> Ok, but maybe make the punctuation consistent here:
Fixed.
> * v9-0004-Support-SSL_R_VERSION_TOO_LOW-on-LibreSSL.patch
>
> Seems
Here are some additional fixes to docs.
>From 6da8beaa5a2b78e785e5b6519894f8357002d916 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 18 Apr 2024 15:40:44 -0500
Subject: [PATCH] doc review for ALTER TABLE ... SPLIT/MERGE PARTITION
---
doc/src/sgml/ddl.sgml | 4 ++--
On Thu, Apr 18, 2024 at 10:33:08PM +0200, Daniel Gustafsson wrote:
> From a read-through they look good, a very nice performance improvement in an
> important path. I think it would be nice with some comments on the
> BinaryUpgradeClassOids struct (since the code using it is thousands of lines
>
> Thanks for the feedback. I've attached an updated patch.
(1) Shouldn't it be: return (_xgetbv(0) & 0xe6) == 0xe6; ? Otherwise
zmm_regs_available() will return false.
(2) Nitpick: avx512_popcnt_available and avx512_bw_available() run the same
cpuid leaf. You could combine them into one to
On Thu, Apr 18, 2024 at 2:37 PM Peter Eisentraut
wrote:
> On 17.04.24 19:47, Kirk Wolak wrote:
> > *Example:*
> > \h current_setting
> > No help available for "current_setting".
> > Try \h with no arguments to see available help.
> >
> >
Hi!
18.04.2024 19:00, Alexander Lakhin wrote:
leaves a strange constraint:
\d+ t*
Table "public.tp_0"
...
Not-null constraints:
"merge-16385-26BCB0-tmp_i_not_null" NOT NULL "i"
Thanks!
Attached fix (with test) for this case.
The patch should be
On Thu, Apr 18, 2024 at 6:35 AM Alexander Korotkov wrote:
> The revised patchset is attached.
> 1) I've split the fix for the CommandCounterIncrement() issue and the
> fix for relation persistence issue into a separate patch.
> 2) I've validated that the lock on the new partition is held in
>
> On 18 Apr 2024, at 22:28, Nathan Bossart wrote:
>
> On Thu, Apr 18, 2024 at 10:23:01AM -0500, Nathan Bossart wrote:
>> On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote:
>>> That does indeed seem like a saner approach. Since we look up the relkind
>>> we
>>> can also remove
On Thu, Apr 18, 2024 at 6:09 PM Japin Li wrote:
> /home/japin/postgres/build/../src/common/config_info.c:198:11: error:
> comparison of integer expressions of different signedness: 'int' and 'size_t'
> {aka 'long unsigned int'} [-Werror=sign-compare]
> 198 | Assert(i == *configdata_len);
On Thu, Apr 18, 2024 at 07:56:35PM +0200, Peter Eisentraut wrote:
> On 18.04.24 19:11, Andres Freund wrote:
>> Thoughts about when to apply these? Arguably they're fixing mildly broken
>> code, making it appropriate to fix in 17, but it's also something that we
>> could end up fixing for a
Hello Alvaro,
18.04.2024 16:39, Alvaro Herrera wrote:
I have pushed a fix which should hopefully fix this problem
(d9f686a72e). Please give this a look. Thanks for reporting the issue.
Please look at an assertion failure, introduced with d9f686a72:
CREATE TABLE t(a int, NOT NULL a NO
On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote:
> I'm not sure I understand the problem here. Do you mean that in theory
> a platform's PRId64 could be something other than "l" or "ll"?
Yes. I don't know why anyone would do that, and the systems I checked
all have the obvious
Corey Huinker writes:
>>
>> I havent dealt with variadic yet, since the two styles are visually
>> different, not just markup (... renders as [...]).
>>
>> The two styles for variadic are the what I call caller-style:
>>
>>concat ( val1 "any" [, val2 "any" [, ...] ] )
>>format(formatstr
On Thu, 18 Apr 2024 at 23:36, Jelte Fennema-Nio wrote:
> To clarify: My proposed approach is to use a protocol extension
> parameter for to enable the new messages that the server can send
> (like Peter is doing now). And **in addition to that** gate the new
> Bind format type behind a feature
> On that note, is it necessary to also check for avx512f? At the moment, we
> are assuming that's supported if the other AVX-512 instructions are available.
No, it's not needed. There are no CPU's with avx512bw/avx512popcnt without
avx512f. Unfortunately though, avx512popcnt does not mean
On Thu, Feb 8, 2024 at 3:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Jan 30, 2024 at 5:06 PM Tom Lane wrote:
> >> Thomas Munro writes:
> >>> Ahh, there is one: https://github.com/cpan-authors/IO-Tty/issues/38
>
> >> Just for the archives' sake: I hit this today on a fresh install
On 4/19/24 01:10, Robert Haas wrote:
On Wed, Apr 17, 2024 at 7:56 PM David Steele wrote:
Thanks! I've tested this and it works as advertised.
Ideally I'd want an error on backup if there is a similar file in any
data directories that would cause an error on combine, but I admit that
it is
On Thu, Apr 18, 2024 at 12:21:56PM +0200, Jelte Fennema-Nio wrote:
> On Thu, 18 Apr 2024 at 09:02, Michael Paquier wrote:
>> On Fri, Apr 12, 2024 at 09:36:36AM +0900, Michael Paquier wrote:
>> log_backtrace speaks a bit more to me as a name for this stuff because
>> it logs a backtrace. Now,
On 4/19/24 00:50, Robert Haas wrote:
On Wed, Apr 17, 2024 at 7:09 PM David Steele wrote:
Fair enough. I accept that your reasoning is not random, but I'm still
not very satisfied that the user needs to run a separate and rather
expensive process to do the verification when pg_combinebackup
On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut wrote:
> Maybe this means something like our int64 is long long int but the
> system's int64_t is long int underneath, but I don't see how that would
> matter for the limit macros.
Agreed, so I don't think it's long vs long long (when they have
On Thu, 18 Apr 2024 at 22:17, Robert Haas wrote:
> If we go with Peter's approach, every driver that supports his feature
> will work perfectly, and every driver that doesn't will work exactly
> as it does today. The risk of breaking anything is as near to zero as
> human developers can
On Thursday, April 18, 2024 1:52 PM Amit Kapila wrote:
>
> 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
Hi,
On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
> Here is a patch series that aims to clean up ecpg's preprocessor
> code a little and fix the compile time problems we're seeing with
> late-model clang [1]. I guess whether it's a cleanup is in the eye of
> the beholder, but it definitely
On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
> >> (If our code coverage tools worked on bison/flex stuff,
> >> maybe this'd be less scary ... but they don't.)
>
> > For bison coverage seems to work, see e.g.:
>
> Yeah, I'd
1 - 100 of 139 matches
Mail list logo
