Re: Add 64-bit XIDs into PostgreSQL 15

On 25.07.24 13:09, Heikki Linnakangas wrote: However, if there is no more disaster threshold at 2^31, what is the guidance for setting these?  Or more radically, why even run transaction-count-based vacuum at all? To allow the CLOG to be truncated. There's no disaster anymore, but without

Re: Incremental backup from a streaming replication standby fails

On Wed, 2024-07-24 at 15:27 -0400, Robert Haas wrote: > On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe wrote: > >    An incremental backup is only possible if replay would begin from a later > >    checkpoint than the checkpoint that started the previous backup upon > > which > >    it depends. >

Re: Remove duplicate table scan in logical apply worker and code refactoring

Hi! > When reviewing the code in logical/worker.c, I noticed that when applying a > cross-partition update action, it scans the old partition twice. Nice catch! > -/* > - * Workhorse for apply_handle_update() > - * relinfo is for the relation we're actually updating in > - * (could be a child

Re: Add 64-bit XIDs into PostgreSQL 15

On Thu, Jul 25, 2024 at 5:19 PM Peter Eisentraut wrote: > On 23.07.24 11:13, Aleksander Alekseev wrote: > >> Here is the fix. It can be tested like this: > >> [...] > > > > PFA the rebased patchset. > > I'm wondering about the 64-bit GUCs. > > At first, it makes sense that if there are settings

Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test

On 2024-07-25 Th 8:00 AM, Alexander Lakhin wrote: Hello hackers, Please take a look at today's failure [1], that raises several questions at once: 117/244 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade TIMEOUT    3001.48s   exit status 1 180/244 postgresql:pg_amcheck /

Re: Add 64-bit XIDs into PostgreSQL 15

On 25/07/2024 13:19, Peter Eisentraut wrote: I'm wondering about the 64-bit GUCs. At first, it makes sense that if there are settings that are counted in terms of transactions, and transaction numbers are 64-bit integers, then those settings should accept 64-bit integers. But what is the

Re: Conflict detection and logging in logical replication

On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu) wrote: > > Here is the V6 patch set which addressed Shveta and Nisha's comments > in [1][2][3][4]. > Do we need an option detect_conflict for logging conflicts? The possible reason to include such an option is to avoid any overhead during

Re: Add 64-bit XIDs into PostgreSQL 15

On 23.07.24 11:13, Aleksander Alekseev wrote: Here is the fix. It can be tested like this: [...] PFA the rebased patchset. I'm wondering about the 64-bit GUCs. At first, it makes sense that if there are settings that are counted in terms of transactions, and transaction numbers are 64-bit

Re: Logical Replication of sequences

On Thu, Jul 25, 2024 at 12:08 PM shveta malik wrote: > > On Thu, Jul 25, 2024 at 9:06 AM vignesh C wrote: > > > > The attached v20240725 version patch has the changes for the same. > > Thank You for addressing the comments. Please review below issues: > > 1) Sub ahead of pub due to wrong initial

Re: why there is not VACUUM FULL CONCURRENTLY?

Hi! On Tue, 30 Jan 2024 at 15:31, Alvaro Herrera wrote: > FWIW a newer, more modern and more trustworthy alternative to pg_repack > is pg_squeeze, which I discovered almost by random chance, and soon > discovered I liked it much more. Can you please clarify this a bit more? What is the exact

RE: Parallel heap vacuum

Dear Sawada-san, > Thank you for the test! > > I could reproduce this issue and it's a bug; it skipped even > non-all-visible pages. I've attached the new version patch. > > BTW since we compute the number of parallel workers for the heap scan > based on the table size, it's possible that we

Re: optimizing pg_upgrade's once-in-each-database steps

> On 25 Jul 2024, at 04:58, Nathan Bossart wrote: > > On Mon, Jul 22, 2024 at 03:07:10PM -0500, Nathan Bossart wrote: >> Here is a new patch set. I've included the latest revision of the patch to >> fix get_db_subscription_count() from the other thread [0] as 0001 since I >> expect that to be

Re: improve ssl error code, 2147483650

> On 24 Jul 2024, at 15:32, Peter Eisentraut wrote: > > On 25.06.24 16:21, Tom Lane wrote: >> Peter Eisentraut writes: >>> On 21.06.24 16:53, Tom Lane wrote: Most of libpq gets at strerror_r via SOCK_STRERROR for Windows portability. Is that relevant here? >>> Looking inside the

Re: REINDEX not updating partition progress

On Sun, Jul 21, 2024 at 11:41:43AM +0100, Ilya Gladyshev wrote: > Forgot to update partition_relid in reindex_index in the second patch. Fixed > in attachment. relid oid - OID of the table on which the index is being created. + OID of the table on which the

Re: PG buildfarm member cisticola

On Wed, Jul 24, 2024 at 01:09:22PM +0200, Alvaro Herrera wrote: > Hmm, it appears that these symbols did not exist in 1.1.1g, and since > neither of them is invoked directly by the Postgres code, maybe the > reason for this is that the OpenSSL headers being used do not correspond > to the library

Re: Support prepared statement invalidation when result types change

On Wed, 24 Jul 2024 at 17:39, Tom Lane wrote: > > This patch starts to allow a prepared statement to continue to work even > > when the result type changes. > > What this is is a wire protocol break. Yeah that's what I realised as well in my latest email. I withdrew this patch from the

Re: Can we rely on the ordering of paths in pathlist?

Hi Richard Guo Is it necessary to add some comments here？ + if (!innerpath->parallel_safe || + !bms_is_empty(PATH_REQ_OUTER(innerpath))) + continue; + + if (matched_path != NULL && + compare_path_costs(matched_path, innerpath, TOTAL_COST) <= 0) + continue; + + matched_path = innerpath;

Re: pg_upgrade and logical replication

On Wed, Jul 24, 2024 at 10:16:51PM -0500, Nathan Bossart wrote: > On Thu, Jul 25, 2024 at 08:43:03AM +0530, Amit Kapila wrote: >>> Shall we close the open items? >> >> Sorry for the typo. There is only one open item corresponding to this: >> "Subscription and slot information retrieval

Re: Convert node test compile-time settings into run-time parameters

On 24.05.24 16:39, Tom Lane wrote: Maybe not three settings, but a single setting, with multiple values, like debug_io_direct? Yeah, good idea. Let's get some more feedback on this before I code up a complicated list parser. Kinda doubt it's worth the trouble, either to code the GUC support

Re: Logical Replication of sequences

ns exist on the publisher. If - * refresh_all_sequences is true, it will mark all sequences with "init" state + * If 'copy_data' parameter is true, the function will set the state + * to "init"; otherwise, it will set the state to "ready". + * + * When 'validate_publicat

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bind

On Wed, Jul 24, 2024 at 05:33:07PM +0200, Peter Eisentraut wrote: > This commit message confused me, because I don't think this is what the > \bindx command actually does. AFAICT, it only binds, it does not execute. > At least that is what the documentation in the content of the patch appears >

Re: Logical Replication of sequences

On Thu, Jul 25, 2024 at 9:06 AM vignesh C wrote: > > The attached v20240725 version patch has the changes for the same. Thank You for addressing the comments. Please review below issues: 1) Sub ahead of pub due to wrong initial sync of last_value for non-incremented sequences. Steps at [1] 2)

Re: SQL:2011 application time

On Wed, Jul 24, 2024 at 12:08 AM Paul Jungwirth wrote: > > On 7/18/24 11:39, Paul Jungwirth wrote: > > So I swapped in the &&& patch, cleaned it up, and added tests. But > > something is wrong. After I get > > one failure from an empty, I keep getting failures, even though the table > > is

Re: long-standing data loss bug in initial sync of logical replication

On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote: > > On Wed, 17 Jul 2024 at 11:54, Amit Kapila wrote: > > > > On Tue, Jul 16, 2024 at 6:54 PM vignesh C wrote: > > > > BTW, I noticed that we don't take any table-level locks for Create > > Publication .. For ALL TABLES (and Drop Publication). Can

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi, THREAD SUMMARY: Proposal: How about making COPY format extendable? Background: Currently, COPY TO/FROM supports only "text", "csv" and "binary" formats. There are some requests to support more COPY formats. For example: * 2023-11: JSON and JSON lines [1] * 2022-04: Apache Arrow [2] *

Re: Recent 027_streaming_regress.pl hangs

Hello Andrew, 04.06.2024 13:00, Alexander Lakhin wrote: Also, 027_stream_regress still fails due to the same reason: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus=2024-05-22%2021%3A55%3A03

Re: query_id, pg_stat_activity, extended query protocol

stgresql.org/message-id/ZqCMCS4HUshUYjGc%40paquier.xyz > We do have to account for the queryId changing after cache revalidation, so > we should still set the queryId inside GetCachedPlan in the case the query > underwent re-analysis. This means there is a chance that a queryId set at >

Re: Make tuple deformation faster

On Mon, Jul 1, 2024 at 5:07 PM David Rowley wrote: > cycles idle >8505168 stalled-cycles-backend:u #0.02% backend cycles > idle > 165442142326 instructions:u#3.35 insn per cycle > #0.00

Re: pg_upgrade and logical replication

On Thu, Jul 25, 2024 at 08:43:03AM +0530, Amit Kapila wrote: >> Shall we close the open items? > > Sorry for the typo. There is only one open item corresponding to this: > "Subscription and slot information retrieval inefficiency in > pg_upgrade" which according to me should be closed after your

Re: pg_upgrade and logical replication

On Thu, Jul 25, 2024 at 8:41 AM Amit Kapila wrote: > > On Wed, Jul 24, 2024 at 10:03 PM Nathan Bossart > wrote: > > > > On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote: > > > LGTM. > > > > Thanks for reviewing. Committed and back-patched to v17. > > > > Shall we close the open

Re: pg_upgrade and logical replication

On Wed, Jul 24, 2024 at 10:03 PM Nathan Bossart wrote: > > On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote: > > LGTM. > > Thanks for reviewing. Committed and back-patched to v17. > Shall we close the open items? I think even if we want to improve the slot fetching/creation

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Tue, 23 Jul 2024 at 22:14, Melih Mutlu wrote: > Fixed the name. Also I needed to cast parameters when calling that function > as below to get rid of some warnings. > > + get_memory_context_name_and_ident(context, > +

Re: Slow catchup of 2PC (twophase) transactions on replica in LR

On Wed, Jul 24, 2024 at 9:13 PM Tom Lane wrote: > > Amit Kapila writes: > > I merged these changes, made a few other cosmetic changes, and pushed the > > patch. > > There is a CF entry pointing at this thread [1]. Should it be closed? > Yes, closed now. Thanks for the reminder. -- With

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Wed, 24 Jul 2024 at 21:47, David Rowley wrote: > I've only had a quick look so far, but I think the patch is now in the > right shape. Unless there's some objections to how things are being > done in v10, I plan to commit this in the next few days... modulo any > minor adjustments. I reviewed

Re: Sporadic connection-setup-related test failures on Cygwin in v15-

24.07.2024 23:58, Thomas Munro wrote: +1. I'm not planning to back-patch that work. Perhaps lorikeet could stop testing releases < 16? They don't work and it's not our bug[1]. We decided not to drop Cygwin support[2], but I don't think we're learning anything from investigating that noise in

Re: optimizing pg_upgrade's once-in-each-database steps

On Mon, Jul 22, 2024 at 03:07:10PM -0500, Nathan Bossart wrote: > Here is a new patch set. I've included the latest revision of the patch to > fix get_db_subscription_count() from the other thread [0] as 0001 since I > expect that to be committed soon. I've also moved the patch that moves the >

Re: CI, macports, darwin version problems

ile thinking about that, it occurred to me that it might also be better if it also re-installs from scratch whenever our script that installs MacPorts changes, so I included its md5 in the cache key. Otherwise it's a bit hard to test, since the cached installation survives across rebuilds by design

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bind

On Wed, Jul 24, 2024 at 05:33:07PM +0200, Peter Eisentraut wrote: > This commit message confused me, because I don't think this is what the > \bindx command actually does. AFAICT, it only binds, it does not execute. > At least that is what the documentation in the content of the patch appears >

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Wed, Jul 24, 2024 at 06:00:59AM -0700, Noah Misch wrote: > I'm still seeing need for s/int/int64/ at: Nice catches! I've missed these. > - "pagesegno" variable > - return value of MultiXactIdToOffsetSegment() Only used in four places for two elog(DEBUG1) entries with %x. > - return value

Re: CI, macports, darwin version problems

On Thu, Jul 25, 2024 at 7:25 AM Joe Conway wrote: > I *think* I finally have it in a good place. I replaced the nvme > enclosure that I bought the other day (which had a 10G interface speed) > with a new one (which has 40G rated speed). The entire ~/.tart directory > is a symlink to

Re: Remove dependence on integer wrapping

On Mon, Jul 22, 2024 at 5:52 PM Alexander Lakhin wrote: > Also there are several trap-producing cases with date types: > SELECT make_date(-2147483648, 1, 1); Hi, I’ve attached a patch that fixes the make_date overflow. I’ve upgraded the patches accordingly to reflect Joseph’s committed fix.

Re: Convert sepgsql tests to TAP

On 7/24/24 10:35 PM, Tom Lane wrote: Andreas Karlsson writes: 1) As I said earlier I think we should remove the old code. I agree that carrying two versions of the test doesn't seem great. However, a large part of the purpose of test_sepgsql is to help people debug their sepgsql setup, which

Re: Sporadic connection-setup-related test failures on Cygwin in v15-

On Thu, Jul 25, 2024 at 1:00 AM Alexander Lakhin wrote: > The important fact here is that this failure is not reproduced after > 7389aad63 (in v16), so it seems that it's somehow related to signal > processing. Given that, I'm inclined to stop here, without digging deeper, > at least until there

Re: Convert sepgsql tests to TAP

Andreas Karlsson writes: > 1) As I said earlier I think we should remove the old code. I agree that carrying two versions of the test doesn't seem great. However, a large part of the purpose of test_sepgsql is to help people debug their sepgsql setup, which is why it goes to great lengths to

Re: DRAFT: Pass sk_attno to consistent function

=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes: > I understand extensibility of GIST makes many operators opaque to the planner > and it is the “consistent” function that can perform optimisations (or we can > come up with some additional mechanism during planning phase). > Providing more

Re: [BUG?] check_exclusion_or_unique_constraint false negative

Hello, everyone! Updates so far: * issue happens with both LOGGED and UNLOGGED relations * issue happens with DirtySnapshot * not happens with SnapshotSelf * not happens with SnapshotAny * not related to speculative inserted tuples - I have commented the code of its insertion - and the issue

Re: Convert sepgsql tests to TAP

On 7/24/24 6:33 PM, Peter Eisentraut wrote: On 24.07.24 16:31, Andreas Karlsson wrote: I took a quick look at the patch and I like that we standardize things a bit. But one thing I am not a fan of are all the use of sed and awk in the Perl script. I would prefer if that logic happened all in

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, Jul 24, 2024 at 3:43 PM Jeremy Schneider wrote: > But non-unique indexes for case insensitive searches will be more common. > Historically this is the most common way people did case insensitive on > oracle. > > Changing ctype would mean these queries can return wrong results Yeah. I

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, Jul 24, 2024 at 12:47 PM Robert Haas wrote: On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote: > There's a qualitative difference between a collation update which can > break your PKs and FKs, and a ctype update which definitely will not. I don't think that's true. All you need is a

Re: Regarding t_cid in Neon heap WAL records

On 24/07/2024 21:44, Muhammad Malik wrote: Neon added a t_cid field to heap WAL records https://github.com/yibit/neon-postgresql/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records .

Re: Incremental backup from a streaming replication standby fails

On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe wrote: > An incremental backup is only possible if replay would begin from a later > checkpoint than the checkpoint that started the previous backup upon which > it depends. My concern here is that the previous backup might have been taken on a

Re: CI, macports, darwin version problems

On 7/23/24 10:44, Joe Conway wrote: I guess if all else fails I will have to get the mac mini with more built in storage in order to accommodate sonoma. I *think* I finally have it in a good place. I replaced the nvme enclosure that I bought the other day (which had a 10G interface speed)

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, Jul 24, 2024 at 3:12 PM Jeff Davis wrote: > In any case, you are correct that Unicode updates could put some > constraints at risk, including unique indexes, CHECK, and partition > constraints. But someone has to actually use one of the affected > functions somewhere, and that's the main

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, 2024-07-24 at 14:47 -0400, Robert Haas wrote: > On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote: > > There's a qualitative difference between a collation update which > > can > > break your PKs and FKs, and a ctype update which definitely will > > not. > > I don't think that's true. All

Re: proposal: schema variables

út 23. 7. 2024 v 23:41 odesílatel Laurenz Albe napsal: > On Tue, 2024-07-23 at 16:34 +0200, Laurenz Albe wrote: > > CREATE VARIABLE command: > > > > This is buggy: > > > > CREATE VARIABLE str AS text NOT NULL DEFAULT NULL; > > > > Ugh. > > > > SELECT str; > > ERROR: null value

Re: add function argument names to regex* functions.

jian he writes: > On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote: >> The larger issue is that contrib/citext offers versions of some of >> these functions that are meant to be drop-in replacements using >> citext input. Hence, we need to add the same parameter names to >> those functions, or

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote: > There's a qualitative difference between a collation update which can > break your PKs and FKs, and a ctype update which definitely will not. I don't think that's true. All you need is a unique index on UPPER(somecol). -- Robert Haas EDB:

Re: improve performance of pg_dump with many sequences

I ran Euler's tests again on the v6 patch set. for i in `seq 1 1`; do psql postgres -c "CREATE SEQUENCE s$i;"; done time pg_dump -f - -s -d postgres > /dev/null HEAD:0.607s 0001 + 0002: 0.094s all patches: 0.094s Barring additional feedback, I

Re: warning: dereferencing type-punned pointer

Peter Eisentraut writes: > If you change the member to a pointer > - ErrorSaveContext escontext; > + ErrorSaveContext *escontext; > } JsonExprState; > and make the required adjustments elsewhere in the code, the warning > goes away. > This arrangement would also appear to be more

Re: warning: dereferencing type-punned pointer

BTW, I tried the same experiment of building without -fno-strict-aliasing using gcc 11.4.1 (from RHEL9). I see one more warning than Tatsuo-san did: In file included from verify_heapam.c:18: verify_heapam.c: In function ‘check_tuple_attribute’: ../../src/include/access/toast_internals.h:37:11:

Re: warning: dereferencing type-punned pointer

On 24.07.24 20:09, Tom Lane wrote: Peter Eisentraut writes: On 24.07.24 16:05, Tom Lane wrote: I'm not very thrilled with these changes. It's not apparent why your compiler is warning about these usages of IsA and not any other ones, I think one difference is that normally IsA is called on

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On 24.07.24 14:20, Robert Haas wrote: On Wed, Jul 24, 2024 at 12:42 AM Peter Eisentraut wrote: Fair enough. My argument was, that topic is distinct from the topic of this thread. OK, that's fair. But I think the solutions are the same: we complain all the time about glibc and ICU shipping

Re: warning: dereferencing type-punned pointer

Peter Eisentraut writes: > On 24.07.24 16:05, Tom Lane wrote: >> I'm not very thrilled with these changes. It's not apparent why >> your compiler is warning about these usages of IsA and not any other >> ones, > I think one difference is that normally IsA is called on a Node * (since > you

Re: warning: dereferencing type-punned pointer

On 24.07.24 16:05, Tom Lane wrote: I'm not very thrilled with these changes. It's not apparent why your compiler is warning about these usages of IsA and not any other ones, I think one difference is that normally IsA is called on a Node * (since you call IsA to decide what to cast it to),

Re: warning: dereferencing type-punned pointer

Peter Eisentraut writes: > This is basically the textbook example of aliasing violation, isn't it? > Wouldn't it be just as simple to do > memcpy(_crc, _state, sizeof(file_crc)); +1. Also, it seems thoroughly bizarre to me that this case is handled before checking for read failure. I'd move

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, 2024-07-24 at 08:20 -0400, Robert Haas wrote: > I note in passing that the last time I saw a customer query with > UPPER() in the join clause was... yesterday. Can you expand on that? This thread is mostly about durable state so I don't immediately see the connection. > So I don't want

Re: warning: dereferencing type-punned pointer

On 24.07.24 08:55, Tatsuo Ishii wrote: origin.c: In function ‘StartupReplicationOrigin’: origin.c:773:16: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 773 |file_crc = *(pg_crc32c *) _state; |

Re: Fixing backslash dot for COPY FROM...CSV

Sutou Kouhei writes: > I read through this thread. It seems that this thread > discuss 2 things: > 1. \. in CSV mode > 2. \. in non-CSV mode > Recent messages discussed mainly 2. but how about create a > separated thread for 2.? Because the original mail focused > on 1. and it seems that we can

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, 2024-07-23 at 06:31 -0600, Jeremy Schneider wrote: > Other RDBMS are very careful not to corrupt databases, afaik > including function based indexes, by changing Unicode. I’m not aware > of any other RDBMS that updates Unicode versions in place; instead > they support multiple Unicode

Re: Detect buffer underflow in get_th()

24.07.2024 18:39, Peter Eisentraut wrote: If it can't happen in practice, maybe an assertion would be enough? In practice, the function should not receive non-numeric strings either; however, since there is an exception in place for such cases, I thought it would be good to add a check

Re: proposal: schema variables

On Wed, 2024-07-24 at 17:19 +0200, Pavel Stehule wrote: > >   This is buggy: > > > >     CREATE VARIABLE str AS text NOT NULL DEFAULT NULL; > > > >   Ugh. > > > >     SELECT str; > >     ERROR:  null value is not allowed for NOT NULL session variable > > "laurenz.str" > >     DETAIL:  The

Re: Convert sepgsql tests to TAP

On 7/24/24 12:36, Tom Lane wrote: Peter Eisentraut writes: In my experience, the tests (both the old and the proposed new) only work on Red Hat-like platforms. I had also tried on Debian but decided that it won't work. Yeah, Red Hat is pretty much the only vendor that has pushed SELinux

Re: Convert sepgsql tests to TAP

Peter Eisentraut writes: > In my experience, the tests (both the old and the proposed new) only > work on Red Hat-like platforms. I had also tried on Debian but decided > that it won't work. Yeah, Red Hat is pretty much the only vendor that has pushed SELinux far enough to be usable by

Re: Convert sepgsql tests to TAP

On 7/24/24 6:31 PM, Peter Eisentraut wrote: On 24.07.24 18:29, Andreas Karlsson wrote: Peter, what did you do to get the tests running? And should we fix these tests to make them more user friendly? In my experience, the tests (both the old and the proposed new) only work on Red Hat-like

Re: pg_upgrade and logical replication

On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote: > LGTM. Thanks for reviewing. Committed and back-patched to v17. -- nathan

Re: Convert sepgsql tests to TAP

On 24.07.24 16:31, Andreas Karlsson wrote: I took a quick look at the patch and I like that we standardize things a bit. But one thing I am not a fan of are all the use of sed and awk in the Perl script. I would prefer if that logic happened all in Perl, especially since we have some of it in

Re: Convert sepgsql tests to TAP

On 24.07.24 18:29, Andreas Karlsson wrote: On 7/24/24 4:31 PM, Andreas Karlsson wrote: I have not yet set up an VM with selinux to try the patch out for real but will do so later. I almost got the tests running but it required way too many manual steps to just get there and I gave up after

Re: Convert sepgsql tests to TAP

On 7/24/24 4:31 PM, Andreas Karlsson wrote: I have not yet set up an VM with selinux to try the patch out for real but will do so later. I almost got the tests running but it required way too many manual steps to just get there and I gave up after just getting segfaults. I had to edit

Re: Make query cancellation keys longer

t, but that's OK; we rely on atomic reads of the + * fields in the ProcSignal slots. + */ +void +SendCancelRequest(int backendPID, int32 cancelAuthCode) +{ + Assert(backendPID != 0); + + /* + * See if we have a matching backend. Reading the pss_pid and + * pss_cancel_key fields is racy, a backend migh

Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan

Richard Guo writes: > Thank you for confirming. Here is an updated patch with some tweaks to > the comments and commit message. I've parked this patch in the July > commitfest. I took a brief look at this. I think the basic idea is sound, but I have a couple of nits: * It's not entirely

Re: Wrong security context for deferred triggers?

po 8. 7. 2024 v 14:36 odesílatel Laurenz Albe napsal: > On 7/8/24 04:14, Joseph Koshakow wrote: > > Given the above and the fact that the patch is a breaking change, my > > vote would still be to keep the current behavior and update the > > documentation. Though I'd be happy to be overruled by

Re: tests fail on windows with default git settings

Hi On Sat, 13 Jul 2024 at 23:01, Thomas Munro wrote: > On Fri, Jul 12, 2024 at 3:49 AM Dave Page wrote: > > So I received an off-list tip to checkout [1], a discussion around > GSSAPI causing test failures on windows that Alexander Lakhin was looking > at. Thomas Munro's v2 patch to try to

Re: Built-in CTYPE provider

On Wed, Jul 24, 2024 at 9:27 AM Peter Eisentraut wrote: > > The last vote arrived 6 days ago. So far, we have votes from Jeff, > Noah, Tom, > > Daniel, and Laurenz. I'll keep the voting open for another 24 hours > from now > > or 36 hours after the last vote, whichever comes last. If that

Re: Slow catchup of 2PC (twophase) transactions on replica in LR

Amit Kapila writes: > I merged these changes, made a few other cosmetic changes, and pushed the > patch. There is a CF entry pointing at this thread [1]. Should it be closed? regards, tom lane [1] https://commitfest.postgresql.org/48/4867/

Re: Support prepared statement invalidation when result types change

Jelte Fennema writes: > The cached plan for a prepared statements can get invalidated when DDL > changes the tables used in the query, or when search_path changes. > ... > However, we would throw an error if the the result of the query is of a > different type than it was before: > ERROR: cached

Re: Detect buffer underflow in get_th()

On 24.07.24 11:43, Alexander Kuznetsov wrote: Hello everyone, In src/backend/utils/adt/formatting.c:1516, there is a get_th() function utilized to return ST/ND/RD/TH suffixes for simple numbers. Upon reviewing its behavior, it appears capable of receiving non-numeric inputs (this is verified

Re: Built-in CTYPE provider

On 7/24/24 11:19, Noah Misch wrote: On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: On Wed, Jul 17, 2024 at 08:48:46AM -0700, Jeff Davis wrote: > you have something in mind, please propose it. However, this feature > followed the right policies at the time of commit, so there would

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On 24.07.24 07:04, Michael Paquier wrote: This commit introduces three additional commands: \parse, \bindx and \close. \parse creates a prepared statement using extended protocol. \bindx binds and execute an existing prepared statement using extended protocol. \close closes an existing prepared

Re: Built-in CTYPE provider

On 24.07.24 17:19, Noah Misch wrote: On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: On Wed, Jul 17, 2024 at 08:48:46AM -0700, Jeff Davis wrote: On Thu, 2024-07-11 at 05:50 -0700, Noah Misch wrote: This is still marked as an open item for 17, but you've already acknowledged[1]

Re: Built-in CTYPE provider

On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: > On Wed, Jul 17, 2024 at 08:48:46AM -0700, Jeff Davis wrote: > > On Thu, 2024-07-11 at 05:50 -0700, Noah Misch wrote: > > > > This is still marked as an open item for 17, but you've already > > > > acknowledged[1] that no code changes

Re: Meson far from ready on Windows

On Sat, 20 Jul 2024 at 21:56, Andres Freund wrote: > Hi, > > On 2024-07-17 09:49:47 -0700, Andres Freund wrote: > > On 2024-07-16 15:53:45 -0500, Tristan Partin wrote: > > > Other than that, it looks pretty solid. > > > > Thanks for looking! I'm thinking of pushing the first few patches >

Re: [PATCH] Add min/max aggregate functions to BYTEA

Added patch to commitfest https://commitfest.postgresql.org/49/5138/ -- With best regards, Marat Bukharov > > Hi, > > > What part of commitfest should I put the current patch to: "SQL > > Commands", "Miscellaneous" or something else? I can't figure it out. > > Personally I qualified a similar

Re: [PATCH] Add min/max aggregate functions to BYTEA

V5 patch. I've added more tests with different bytea sizes -- With best regards, Marat Bukharov чт, 4 июл. 2024 г. в 15:29, Aleksander Alekseev : > > Hi Marat, > > > V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP > > Thanks for the patch. > > Please add it to the

Re: Convert sepgsql tests to TAP

I took a quick look at the patch and I like that we standardize things a bit. But one thing I am not a fan of are all the use of sed and awk in the Perl script. I would prefer if that logic happened all in Perl, especially since we have some of it in Perl (e.g. chomp). Also I wonder if we

Re: pg_upgrade failing for 200+ million Large Objects

On Mon, Apr 01, 2024 at 03:28:26PM -0400, Tom Lane wrote: > Nathan Bossart writes: > > The one design point that worries me a little is the non-configurability of > > --transaction-size in pg_upgrade. I think it's fine to default it to 1,000 > > or something, but given how often I've had to

Re: [PATCH] GROUP BY ALL

On Tue, Jul 23, 2024 at 6:53 PM David Christensen wrote: > > On Mon, Jul 22, 2024 at 4:34 PM David G. Johnston > wrote: > > > > On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote: > >> > >> I see that there'd been some chatter but not a lot of discussion about > >> a GROUP BY ALL

Re: warning: dereferencing type-punned pointer

Tatsuo Ishii writes: > So I think the warnings in ExecEvalJsonExprPath are better fixed > because these are the only places where IsA (nodeTag) macro are used > and the warning is printed. Patch attached. I'm not very thrilled with these changes. It's not apparent why your compiler is warning

Re: Send duration output to separate log files

Hi st 10. 7. 2024 v 17:58 odesílatel Greg Sabino Mullane napsal: > Please find attached a patch to allow for durations to optionally be sent > to separate log files. In other words, rather than cluttering up our > postgres202007.log file with tons of output from > log_min_duration_statement,

Re: improve ssl error code, 2147483650

On 25.06.24 16:21, Tom Lane wrote: Peter Eisentraut writes: On 21.06.24 16:53, Tom Lane wrote: Most of libpq gets at strerror_r via SOCK_STRERROR for Windows portability. Is that relevant here? Looking inside the OpenSSL code, it makes no efforts to translate between winsock error codes

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Wed, Jul 24, 2024 at 6:20 AM Robert Haas wrote: > > I note in passing that the last time I saw a customer query with > UPPER() in the join clause was... yesterday. The problems there had > nothing to do with CTYPE, but there's no reason to suppose that it > couldn't have had such a problem. I

<    2   3   4   5   6   7   8   9   10   11   >