In 30e7c175b81, support for pre-9.2 servers was removed from pg_dump.
But I found that a lot of dead code was left for supporting dumping
triggers from those old versions, presumably because that code was not
behind straightforward versioned "if" branches. This patch removes the
rest of the
On Mon, 2024-01-08 at 15:48 -0500, Tom Lane wrote:
> Is this enough of a bug to deserve back-patching? I'm not sure.
I like the patch, but I wouldn't back-patch it. I'd call the current
behavior a slight inconsistency rather than an outright bug, and I think
that we should be conservative with
> On 9 Jan 2024, at 00:54, Tatsuo Ishii wrote:
>
>>> On 4 Jan 2024, at 13:39, Tatsuo Ishii wrote:
>>
Attached is the patch that does this.
>>
>> I don't think the patch was attached?
>>
>>> Any objection?
>>
>> I didn't study the RFC in depth but as expected it seems to back up your
On Tue, 4 Jul 2023 at 06:56, James Coleman wrote:
>
> On Sun, Jun 11, 2023 at 10:23 PM James Coleman wrote:
> >
> > ...
> > > And while trying the v9 patch I came across a crash with the query
> > > below.
> > >
> > > set min_parallel_table_scan_size to 0;
> > > set parallel_setup_cost to 0;
> >
Dear Amit,
> > > I don't see any harm in users giving those information but we should
> > > have some checks to ensure that the server is in standby mode and is
> > > running locally. The other related point is do we need to take input
> > > for the target cluster directory from the user? Can't
On Sat, 25 Nov 2023 at 06:49, Heikki Linnakangas wrote:
>
> On 19/11/2023 02:04, Andres Freund wrote:
> > On 2023-11-17 11:37:21 +0100, Heikki Linnakangas wrote:
> >> The new facility makes it easier to optimize bulk loading, as the
> >> logic for buffering, WAL-logging, and syncing the relation
On Sat, 6 Jan 2024 at 05:50, Paul Jungwirth
wrote:
>
> Getting caught up on reviews from November and December:
>
> On 11/19/23 22:57, jian he wrote:
> >
> > I believe the following part should fail. Similar tests on
> > src/test/regress/sql/generated.sql. line begin 347.
> >
> > drop table
On Fri, 20 Jan 2023 at 15:30, vignesh C wrote:
>
> On Wed, 16 Nov 2022 at 15:35, vignesh C wrote:
> >
> > On Wed, 16 Nov 2022 at 09:34, Ian Lawrence Barwick
> > wrote:
> > >
> > > 2022年11月7日(月) 22:39 vignesh C :
> > > >
> > > > On Fri, 4 Nov 2022 at 08:19, Ian Lawrence Barwick
> > > > wrote:
On Thu, 9 Nov 2023 at 21:48, Heikki Linnakangas wrote:
>
> On 18/09/2023 07:08, David Rowley wrote:
> > On Fri, 15 Sept 2023 at 22:37, Heikki Linnakangas wrote:
> >>> I've added a call to LockAssertNoneHeld(false) in there.
> >>
> >> I don't see it in the patch?
> >
> > hmm. I must've git
On Tue, Jan 9, 2024 at 6:00 AM Alexander Lakhin wrote:
> 09.01.2024 01:09, Alexander Korotkov wrote:
> > Fixed in 30b4955a46.
>
> Thank you for fixing that!
>
> I've found another anomaly coined with d3d55ce57. This query:
> CREATE TABLE t(a int PRIMARY KEY, b int);
> INSERT INTO t VALUES (1,
On Mon, Jan 08, 2024 at 03:50:47PM -0500, Robert Haas wrote:
> Hmm, interesting. I haven't had time to study this fully today, but I
> think 0001 looks fine and could just be committed. Hooray for killing
> useless variables with dumb names.
I've been looking at 0001 a couple of weeks ago and
Dear Amit, Alexander,
> > We get the effect discussed when the background writer process decides to
> > flush a file buffer for pg_largeobject during stage 1.
> > (Thus, if a checkpoint somehow happened to occur during CREATE DATABASE,
> > the result must be the same.)
> > And another important
On Tue, Jan 9, 2024 at 2:54 AM Paul Jungwirth
wrote:
>
> On 1/8/24 06:54, jian he wrote:
> > On Fri, Jan 5, 2024 at 1:06 PM jian he wrote:
> >
> > range_intersect returns the intersection of two ranges.
> > I think here we are doing the opposite.
> > names the main SQL function
Hi,
On Tue, Jan 09, 2024 at 01:59:08PM +0900, Michael Paquier wrote:
> On Mon, Jan 08, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote:
> > Yes, I've added (VERBOSE) and also cut down the test to catch the failure
> > faster.
Thanks Alexander!
> > The difference between a successful and a
On Tue, Jan 09, 2024 at 04:55:07AM +, Bertrand Drouvot wrote:
> Thanks! v6 looks good to me.
WFM. Thanks for putting in place this sanity check when compiling.
--
Michael
signature.asc
Description: PGP signature
On Mon, 8 Jan 2024 at 22:50, Jelte Fennema-Nio wrote:
>
> On Mon, 8 Jan 2024 at 07:22, vignesh C wrote:
> > Here is a list of "Needs review" entries for which there has not been
> > much communication on the thread and needs help in proceeding further.
>
> Thank you for creating these lists.
On Mon, Jan 8, 2024 at 12:35 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > On Fri, Jan 5, 2024 at 3:36 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > I love your proposal, so I want to join the review. Here are my first
> > > comments.
> > >
> > > 01.
> > > Should we restrict that
On Mon, Jan 08, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote:
> Yes, I've added (VERBOSE) and also cut down the test to catch the failure
> faster.
> The difference between a successful and a failed run:
> tuples: 1 removed, 15 remain, 0 are dead but not yet removable
> [...]
>
Hi,
On Mon, Jan 08, 2024 at 04:02:12PM -0600, Nathan Bossart wrote:
> Sorry for the noise. I spent some more time tidying this up for commit,
> which I am hoping to do in the next day or two.
Thanks! v6 looks good to me.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open
(Compiled two separate review emails into a single one)
On Tue, Jan 02, 2024 at 03:36:12PM +0530, Ashutosh Bapat wrote:
> This discussion has not been addressed in v6. I think the interface
> needs to be documented in the order below
> INJECTION_POINT - this declares an injection point - i.e. a
09.01.2024 01:09, Alexander Korotkov wrote:
Fixed in 30b4955a46.
Thank you for fixing that!
I've found another anomaly coined with d3d55ce57. This query:
CREATE TABLE t(a int PRIMARY KEY, b int);
INSERT INTO t VALUES (1, 1), (2, 1);
WITH t1 AS (SELECT * FROM t)
UPDATE t SET b = t1.b + 1
On Mon, Jan 8, 2024 at 10:48 PM Nathan Bossart
wrote:
> On Mon, Jan 08, 2024 at 11:13:42AM +0530, Amul Sul wrote:
> > +void *
> > +dsm_registry_init_or_attach(const char *key, size_t size,
> >
> > I think the name could be simple as dsm_registry_init() like we use
> > elsewhere e.g.
On Mon, Jan 8, 2024 at 9:36 PM Jim Nasby wrote:
>
> On 1/4/24 10:19 PM, Amit Kapila wrote:
> > On Thu, Jan 4, 2024 at 5:30 PM Alexander Lakhin wrote:
> >>
> >> 03.01.2024 14:42, Amit Kapila wrote:
> >>>
> >>
> And the internal process is ... background writer (BgBufferSync()).
>
>
On Wed, Jan 3, 2024 at 11:10 PM John Naylor wrote:
>
> On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada wrote:
>
> > I agree that we expose RT_LOCK_* functions and have tidstore use them,
> > but am not sure the if (TidStoreIsShared(ts) LWLockAcquire(..., ...)"
> > calls part. I think that even if
Hi,
Robert Haas writes:
> On Sun, Jan 7, 2024 at 9:52 PM Andy Fan wrote:
>> > I think we should add cassert-only infrastructure tracking whether we
>> > currently hold spinlocks, are in a signal handler and perhaps a few other
>> > states. That'd allow us to add assertions like:
>> ..
>> > -
On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart wrote:
>
> > I suspect that there could be a regression lurking for some inputs
> > that the benchmark doesn't look at: pg_lfind32() currently needs to be
> > able to read 4 vector registers worth of elements before taking the
> > fast path. There is
Here are some review comments for patch v57-0001.
==
doc/src/sgml/protocol.sgml
1. CREATE_REPLICATION_SLOT ... FAILOVER
+
+FAILOVER [ boolean ]
+
+
+ If true, the slot is enabled to be synced to the physical
+ standbys so that logical
On 12/28/23 6:57 PM, Jeff Davis wrote:
>
> Attached a more complete version that fixes a few bugs, stabilizes the
> tests, and improves the documentation. I optimized the performance, too
> -- now it's beating both libc's "C.utf8" and ICU "en-US-x-icu" for both
> collation and case mapping
On Fri, Jan 05, 2024 at 03:00:25PM +0530, Dilip Kumar wrote:
> Some comments in 0001, mostly cosmetics
>
> 1.
> +/* utilities to handle the local array cache */
> +static void
> +injection_point_cache_add(const char *name,
> + InjectionPointCallback callback)
>
> I think the comment for this
On Mon Jan 8, 2024 at 9:26 AM EST, jian he wrote:
> On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote:
> > The `regexp_replace` summary in table 9.10 is mismatched and still
> > specifies the first parameter name as `string` instead of `source`.
> > Since all the other functions use `string`, should
On Fri, Jan 05, 2024 at 02:58:55PM -0500, Robert Haas wrote:
> I'm not a Windows expert, but my guess is that 0001 is a very good
> idea. I hope someone who is a Windows expert will comment on that.
I am +1 on 0001. It is just something we've never anticipated when
these wrappers around cmd in
On Mon, Jan 08, 2024 at 05:04:58PM -0600, Tristan Partin wrote:
> The idea I had in mind initially was PGLC_localeconv(), but I couldn't
> prove that anything changed with the annotation added. The second patch
> in my previous email was attempt at deriving real-world benefit, but
> nothing I did
"Tristan Partin" writes:
> On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote:
>> +(isascii((unsigned char)
>> mybuf.data[mybuf.len - 1]) &&
>> + isspace((unsigned char)
>> mybuf.data[mybuf.len -
>> On 4 Jan 2024, at 13:39, Tatsuo Ishii wrote:
>
>>> Attached is the patch that does this.
>
> I don't think the patch was attached?
>
>> Any objection?
>
> I didn't study the RFC in depth but as expected it seems to back up your
> change
> so the change seems reasonable.
Oops. Sorry.
On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote:
We had a complaint (see [1], but it's not the first IIRC) about how
psql doesn't behave very nicely if one ends \sf or allied commands
with a semicolon:
regression=# \sf sin(float8);
ERROR: expected a right parenthesis
This is a bit of a
On Sun Dec 31, 2023 at 9:29 PM CST, John Naylor wrote:
On Thu, Dec 28, 2023 at 1:20 AM Tristan Partin wrote:
> I recently wound up in a situation where I was checking for NULL return
> values of a function that couldn't ever return NULL because the
> inability to allocate memory was always
Okay, attempt number 5 attached. The primary changes with the previous
version are:
1. Split up commits a bit differently. I think each commit now stands
on its own and is an incremental improvement that could be committed
without any of the later ones being necessary. Descriptions of why
each
Robert Haas writes:
> On Sat, Jan 6, 2024 at 4:08 PM Tom Lane wrote:
>> The argument for the patch as proposed is that we should make the
>> mergejoin and hashjoin code paths do what the nestloop path is doing.
>> However, as I replied further down in that other thread, I'm not
>> exactly
On Mon, Jan 8, 2024 at 10:20 PM Alexander Korotkov wrote:
> On Mon, Jan 8, 2024 at 10:00 PM Alexander Lakhin wrote:
> > Please look at the following query which produces an incorrect result since
> > d3d55ce57:
> > CREATE TABLE t(a int PRIMARY KEY, b int);
> > INSERT INTO t VALUES (1, 1), (2,
Sorry for the noise. I spent some more time tidying this up for commit,
which I am hoping to do in the next day or two.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 4e222c1a1fc1a2476746cb7b68c1d2a203816699 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 8 Jan
On Mon, Jan 08, 2024 at 04:58:02PM +, Dagfinn Ilmari Mannsåker wrote:
> We can't make pg_get_serial_sequence(text, text) not work on identity
> columns any more, that would break existing users, and making the new
> function not work on serial columns would make it harder for people to
>
On Fri, Jan 5, 2024 at 3:34 PM Melanie Plageman
wrote:
> Yes, attached is a patch set which does this. My previous patchset
> already reduced the number of places we unlock the buffer and update
> the freespace map in lazy_scan_heap(). This patchset combines the
> lazy_scan_prune() and
We had a complaint (see [1], but it's not the first IIRC) about how
psql doesn't behave very nicely if one ends \sf or allied commands
with a semicolon:
regression=# \sf sin(float8);
ERROR: expected a right parenthesis
This is a bit of a usability gotcha, since many other backslash
commands are
On 1/8/24 14:36, Dean Rasheed wrote:
On Thu, 7 Dec 2023 at 01:10, Joe Conway wrote:
The attached should fix the CopyOut response to say one column.
Playing around with this, I found a couple of cases that generate an error:
COPY (SELECT 1 UNION ALL SELECT 2) TO stdout WITH (format json);
On Mon, Jan 8, 2024 at 10:00 PM Alexander Lakhin wrote:
> Please look at the following query which produces an incorrect result since
> d3d55ce57:
> CREATE TABLE t(a int PRIMARY KEY, b int);
> INSERT INTO t VALUES (1, 1), (2, 1);
> SELECT * FROM t WHERE EXISTS (SELECT * FROM t t2 WHERE t2.a =
On Mon, Jan 08, 2024 at 07:59:10AM +, Bertrand Drouvot wrote:
> + input: [files(
> +'../../backend/storage/lmgr/lwlocknames.txt',
> +'../../backend/utils/activity/wait_event_names.txt')],
>
> I think the "[" and "]" are not needed here.
D'oh! Fixed in v5.
--
Nathan Bossart
Amazon
On Fri, Jan 5, 2024 at 3:57 PM Andres Freund wrote:
> > I will be astonished if you can make this work well enough to avoid
> > huge regressions in plausible cases. There are plenty of cases where
> > we do a very thorough job opportunistically removing index tuples.
>
> These days the AM is
Yeah. I think there's an unofficial policy for post-analysis parse
trees that we don't bother writing outfuncs for utility-statement
nodes (there are too many of 'em and they're not interesting enough)
but anything that can appear in or under DML commands should be
dumpable. I'd favor the
Hello Andrei and Alexander,
Please look at the following query which produces an incorrect result since
d3d55ce57:
CREATE TABLE t(a int PRIMARY KEY, b int);
INSERT INTO t VALUES (1, 1), (2, 1);
SELECT * FROM t WHERE EXISTS (SELECT * FROM t t2 WHERE t2.a = t.b AND t2.b > 0);
a | b
---+---
1 |
On Sun, Jan 7, 2024 at 9:52 PM Andy Fan wrote:
> > I think we should add cassert-only infrastructure tracking whether we
> > currently hold spinlocks, are in a signal handler and perhaps a few other
> > states. That'd allow us to add assertions like:
> ..
> > - no lwlocks or ... while in signal
On Thu, 7 Dec 2023 at 01:10, Joe Conway wrote:
>
> The attached should fix the CopyOut response to say one column.
>
Playing around with this, I found a couple of cases that generate an error:
COPY (SELECT 1 UNION ALL SELECT 2) TO stdout WITH (format json);
COPY (VALUES (1), (2)) TO stdout
On 1/8/24 06:54, jian he wrote:
> On Fri, Jan 5, 2024 at 1:06 PM jian he wrote:
>
> range_intersect returns the intersection of two ranges.
> I think here we are doing the opposite.
> names the main SQL function "range_not_intersect" and the internal
> function as "range_not_intersect_internal"
On Mon, 18 Dec 2023 at 16:34, Jelte Fennema-Nio wrote:
>
> On Mon, 18 Dec 2023 at 16:38, Christoph Berg wrote:
> > We'd want both patches even if they do the same thing on two different
> > levels, I'd say.
>
> Makes sense.
>
I can see the appeal in this feature. However, as it stands, this
On Mon, Jan 08, 2024 at 02:01:39PM +0700, John Naylor wrote:
> On Thu, Nov 30, 2023 at 12:15 AM Nathan Bossart
> wrote:
>> writerssse2avx2 %
>> 25611951188-1
>> 512 9281054 +14
>> 1024 633 716 +13
>> 2048 332 420 +27
>>
On Fri, Jan 5, 2024 at 12:59 PM Melanie Plageman
wrote:
> > But you can just as easily turn this argument on its head, can't you?
> > In general, except for HOT tuples, line pointers are marked dead by
> > pruning and unused by vacuum. Here you want to turn it on its head and
> > make pruning do
On Sat, Jan 6, 2024 at 4:08 PM Tom Lane wrote:
> > Well, this explanation made sense to me:
> > https://www.postgresql.org/message-id/CAMbWs4-%2BGs0HJ9ouBUb%3DqwHsGCXxG%2B92eJzLOpCkedvgtOWQ%3DQ%40mail.gmail.com
>
> The argument for the patch as proposed is that we should make the
> mergejoin and
On Mon, 8 Jan 2024 at 07:22, vignesh C wrote:
> Here is a list of "Needs review" entries for which there has not been
> much communication on the thread and needs help in proceeding further.
Thank you for creating these lists. It's definitely helpful to see
what to focus my reviewing effort on.
On Mon, Jan 08, 2024 at 11:13:42AM +0530, Amul Sul wrote:
> +void *
> +dsm_registry_init_or_attach(const char *key, size_t size,
>
> I think the name could be simple as dsm_registry_init() like we use
> elsewhere e.g. ShmemInitHash() which doesn't say attach explicitly.
That seems reasonable to
On Mon, Jan 08, 2024 at 10:53:17AM +0530, Bharath Rupireddy wrote:
> 1. I think we need to add some notes about this new way of getting
> shared memory for external modules in the Shared Memory and
> LWLocks section in xfunc.sgml? This will at least tell there's
> another way for external modules
Hello Bertrand,
08.01.2024 10:34, Bertrand Drouvot wrote:
If one is able to reproduce, would it be possible to change the test and launch
the vacuum in verbose mode? That way, we could see if this is somehow due to [1]
(means something holding global xmin).
Yes, I've added (VERBOSE) and also
vignesh C writes:
> On Tue, 24 Oct 2023 at 22:00, Nathan Bossart wrote:
>>
>> On Tue, Sep 12, 2023 at 03:53:28PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> > Tom Lane writes:
>> >> It's possible that we could get away with just summarily changing
>> >> the argument type from text to regclass.
Richard Guo writes:
> On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote:
>> Thanks for the report! I guess we need something like the attached.
> +1.
Pushed, thanks for looking at it.
>> I'm surprised that this hasn't been noticed before; was the case
>> really unreachable before?
> It seems
> On Sat, Jan 06, 2024 at 09:04:54PM +0530, vignesh C wrote:
>
> CFBot shows documentation build has failed at [1] with:
> [07:44:55.531] time make -s -j${BUILD_JOBS} -C doc
> [07:44:57.987] postgres.sgml:572: element xref: validity error : IDREF
> attribute linkend references an unknown ID
>
On 1/4/24 10:19 PM, Amit Kapila wrote:
On Thu, Jan 4, 2024 at 5:30 PM Alexander Lakhin wrote:
03.01.2024 14:42, Amit Kapila wrote:
And the internal process is ... background writer (BgBufferSync()).
So, I tried just adding bgwriter_lru_maxpages = 0 to postgresql.conf and
got 20 x 10
On 2023-Dec-12, Tomas Vondra wrote:
> I propose we do a much simpler thing instead - allow the cache may be
> initialized / cleaned up repeatedly, and make sure it gets reset at
> convenient place (typically after index_insert calls that don't go
> through execIndexing). That'd mean the cleanup
On 2024-Jan-08, Dilip Kumar wrote:
> On Mon, Jan 8, 2024 at 4:55 PM Alvaro Herrera wrote:
> >
> > The more I look at TransactionGroupUpdateXidStatus, the more I think
> > it's broken, and while we do have some tests, I don't have confidence
> > that they cover all possible cases.
> >
> > Or, at
On 08.01.24 15:04, Aleksander Alekseev wrote:
[...] so I quickly wrote some (wrong) instrumentation to try to test your patch.
Yep, it confused me too at first.
Since the encoding happens right before exit() call, maybe it's worth
changing $b in-place in order to make the code slightly more
I've been thinking about INSERT performance and noticed that copyfrom.c
(COPY FROM) performs ~4 unnecessary pointer-deferences per record in the
case when there's no indexes and no AFTER ROW INSERT triggers (i.e. when
you just want to load data really fast!).
I moved the for-loop inside the
On Fri, Jan 5, 2024 at 1:06 PM jian he wrote:
>
> On Tue, Jan 2, 2024 at 9:59 AM Paul Jungwirth
> wrote:
> >
> > On 12/31/23 00:51, Paul Jungwirth wrote:
> > > That's it for now.
> >
> > Here is another update. I fixed FOR PORTION OF on partitioned tables, in
> > particular when the attnums
> >
On Mon, Jan 8, 2024 at 8:44 AM Dian Fay wrote:
>
> On Thu Jan 4, 2024 at 2:03 AM EST, jian he wrote:
> > On Thu, Jan 4, 2024 at 7:26 AM Jim Nasby wrote:
> > >
> > > On 1/3/24 5:05 PM, Dian Fay wrote:
> > >
> > > Another possibility is `index`, which is relatively short and not a
> > > reserved
Hi,
> [...] so I quickly wrote some (wrong) instrumentation to try to test your
> patch.
Yep, it confused me too at first.
Since the encoding happens right before exit() call, maybe it's worth
changing $b in-place in order to make the code slightly more readable
for most of us :)
--
Best
On Monday, January 8, 2024, Geoff Winkless wrote
>
>
> Mildly interesting: you can pass column positions to GROUP BY and
> ORDER BY but if you try to pass a position to GROUPING() (I wondered
> if that would help the engine somehow) it fails:
>
The symbol 1 is ambigious - it can be the number or
> On Jan 8, 2024, at 5:41 AM, Mark Dilger wrote:
>
> The /r modifier defeats the purpose of the patch, at least for my perl
> version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
> modifier, it works fine.
Nevermind. I might be wrong about that. I didn't have a test
On 1/7/24 23:27, Peter Eisentraut wrote:
The pg_amcheck reports a skip message if the layout of the index does
not match expectations. That message includes the bytes that were
expected and the ones that were found. But the found ones are arbitrary
bytes, which can have funny effects on
On Mon, Jan 8, 2024 at 4:55 PM Alvaro Herrera wrote:
>
> The more I look at TransactionGroupUpdateXidStatus, the more I think
> it's broken, and while we do have some tests, I don't have confidence
> that they cover all possible cases.
>
> Or, at least, if this code is good, then it hasn't been
> On 4 Jan 2024, at 13:39, Tatsuo Ishii wrote:
>> Attached is the patch that does this.
I don't think the patch was attached?
> Any objection?
I didn't study the RFC in depth but as expected it seems to back up your change
so the change seems reasonable.
--
Daniel Gustafsson
Hi,
> The pg_amcheck reports a skip message if the layout of the index does
> not match expectations. That message includes the bytes that were
> expected and the ones that were found. But the found ones are arbitrary
> bytes, which can have funny effects on the terminal when they are
>
On Mon, 8 Jan 2024 at 11:12, Geoff Winkless wrote:
> What's even more of a head-scratcher is why fixing this this then
> breaks the _first_ group's ORDERing.
Ignore that. Finger slippage - looking back I realised I forgot the
"=0" test after the GROUPING() call.
It looks like I'm going to go
On Wed, Jan 3, 2024 at 9:10 PM John Naylor wrote:
>
> On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada wrote:
>
> > I agree that we expose RT_LOCK_* functions and have tidstore use them,
> > but am not sure the if (TidStoreIsShared(ts) LWLockAcquire(..., ...)"
> > calls part. I think that even if
The more I look at TransactionGroupUpdateXidStatus, the more I think
it's broken, and while we do have some tests, I don't have confidence
that they cover all possible cases.
Or, at least, if this code is good, then it hasn't been sufficiently
explained.
If we have multiple processes trying to
On 2023-Dec-21, James Wang wrote:
> Hi All, not sure how to "Specify thread msgid" - choose one which i think
> is close to my new feature request.
Hello James, based on the "Specify thread msgid" message it looks like
you were trying to request a feature using the Commitfest website? That
Hi,
On 12/27/23 18:38, Tom Lane wrote:
Hmm. It seems odd that if an extension defines a type, the type is
listed as a member of the extension but the array type is not.
That makes it look like the array type is an externally-created
thing that happens to depend on the extension, when it's
On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote:
> Alexander Lakhin writes:
> > Please look at the following query:
> > CREATE TABLE t(i int);
> > INSERT INTO t VALUES (1);
> > VACUUM ANALYZE t;
>
> > WITH ir AS (INSERT INTO t VALUES (2) RETURNING i)
> > SELECT * FROM ir WHERE i = 2;
>
> > which
On Mon, 8 Jan 2024 at 10:23, Geoff Winkless wrote:
> Seems there was a reason why I thought that: per the documentation:
>
> "The arguments to the GROUPING function are not actually evaluated,
> but they must exactly match expressions given in the GROUP BY clause
> of the associated query
On Sat, 6 Jan 2024 at 23:27, Geoff Winkless wrote:
> Well yes. I assumed that since it's required that a group expression is in
> the query itself that
> the grouping values were taken from the result set, I have to admit to some
> surprise that
> they're calculated twice (three times?).
Andy Fan writes:
>>
>> One of the tests was aborted at CFBOT [1] with:
>> [09:47:00.735] dumping /tmp/cores/postgres-11-28182.core for
>> /tmp/cirrus-ci-build/build/tmp_install//usr/local/pgsql/bin/postgres
>> [09:47:01.035] [New LWP 28182]
>
> There was a bug in JIT part, here is the fix.
On Mon, Jan 8, 2024 at 2:24 PM Junwang Zhao wrote:
>
> + * Portions Copyright (c) 2018-2023, PostgreSQL Global Development Group
>
> A kind reminder, it's already 2024 :)
>
> I'm also curious why the 2018, is there any convention for that?
The convention I followed was "blind copy-paste", but
Hi Andrei,
> Maybe my wording needed to be more precise. I didn't implement
> multidimensional histograms before, so I don't know how expensive they
> are. I meant that for dependency statistics over about six columns, we
> have a lot of combinations to compute.
Equi-Depth Histogram in a 6
After reading the logic of removing useless join, I think the comment of
this might need to be changed: "Currently, join_is_removable only succeeds
if sjinfo's right hand is a single baserel. " could be changed to
"Currently, join_is_removable only succeeds if sjinfo's min_righthand is a
single
On Sat, Jan 6, 2024 at 12:04 AM Nathan Bossart wrote:
> I've been thinking about the configuration option approach. ISTM that
> would be the most feasible strategy, at least for v17. A couple things
> come to mind:
>
> * This option would simply map to existing compiler flags. We already have
Thanks for the review!
On Sat, Jan 6, 2024 at 2:36 AM Robert Haas wrote:
> Richard, I think it could be useful to put a better commit message
> into the patch file, describing both what problem is being fixed and
> what the design of the fix is. I gather that the problem is that we
> crash if
If I want to change the name of my database schema, I call
alter schema my_schema rename to other_schema
However, there is a problem with functions that call other functions in the
same schema. These functions have a search_path
alter function my_schema.function1 set
92 matches
Mail list logo
