On Mon, Dec 16, 2024 at 04:18:26PM -0600, Nathan Bossart wrote:
> On Mon, Dec 16, 2024 at 08:00:00AM +0100, Andreas 'ads' Scherbaum wrote:
>> Can confirm that the crash no longer happens when applying your patch.
>
> The patch looks reasonable to me. I'll commit it soon unless someone
> objects.
On Mon, Dec 16, 2024 at 10:57:49PM +0100, Michael Banck wrote:
> Thanks, I have added the documentation now in v2.
The doc additions seem fine to me. I've just grabbed three tiny nits,
nothing critical.
+ case 's':
+ if (PQservi
Hello,
On Mon, Dec 16, 2024 at 11:18 PM Nathan Bossart
wrote:
> On Mon, Dec 16, 2024 at 08:00:00AM +0100, Andreas 'ads' Scherbaum wrote:
> > Can confirm that the crash no longer happens when applying your patch.
>
> The patch looks reasonable to me. I'll commit it soon unless someone
> objects.
On Mon, Dec 16, 2024 at 11:17:17PM -0500, Tom Lane wrote:
> The failures all seem to be in "checkprep", ie the test setup
> stage not the test proper. The log output from that isn't being
> captured, making it hard to diagnose. Could we prevail on you
> to install a more up-to-date buildfarm clie
On Mon, Dec 16, 2024 at 03:42:04PM +, Bertrand Drouvot wrote:
> It's not necessary per say, but it ensures that pg_stat_get_backend_io() does
> not
> return rows full of "invalid" combinations.
Okay. I am not planning to fight more over this point.
> I'm not sure that would be possible for
On Tue, Dec 17, 2024 at 10:01 AM AbdelAziz Sharaf
wrote:
>
> No
> when specifying search_path, we build another schema, where each duplicate
> data must be inside
> what I suggested is to have versions/aliases for schemas and any duplicate
> table/view/... could be inherited if duplicate with al
Hi,
On Mon, Dec 16, 2024 at 04:02:56PM -0600, Nathan Bossart wrote:
> On Mon, Dec 16, 2024 at 10:11:23AM +, Bertrand Drouvot wrote:
> > +#define PARALLEL_VACUUM_WORKER_DELAY_REPORT_INTERVAL_NS (NS_PER_S)
> >
> > Did not changed in v14, but "PARALLEL_VACUUM_REPORT_INTERVAL_NS" could be
> > an
On Tue, 17 Dec 2024 at 04:43, Noah Misch wrote:
> The reason I said databases.sql for the test is that CREATE DATABASE is
> expensive. We currently have just one successful CREATE DATABASE in the
> src/test/regress suite, and we shouldn't add more that reasonably could
> instead harness the exis
> But if the column names are ambiguous within the same RTE, how does
> table-qualification fix that? And it's within-the-same-RTE that
> we're concerned with here
> It only takes one case to mean we have to deal with it ;-). But I'm
> fairly sure that there are many other cases, since the parse
On Mon, 16 Dec 2024 at 16:50, Nishant Sharma
wrote:
> Also, I think Andrew's suggestion can resolve the concern me and Krill
> had on forcing users to create tables with correct column names and
> numbers. Also, will make error table checking simpler. No need for the
> above kind of checks.
+1 on
Thomas Munro writes:
> Whenever I run into this, or my Mac requires manual ipcrm to clean up
> leaked SysV kernel junk, I rebase my patch for sema_kind = 'futex'.
> Here it goes. It could be updated to support NetBSD I believe, but I
> didn't try as its futex stuff came out later.
FWIW, I looked
Robins Tharakan writes:
> I am quite late to this discussion, but I am unable to get snakefly up and
> running,
> i.e. I see that all versions failed today (most on
> ssl_passphrase_callback-check
> test [2], but v15/v16 on sslCheck [1] too)
The failures all seem to be in "checkprep", ie the test
On Wed, 2024-10-30 at 08:08 -0700, Jeff Davis wrote:
> Rebased, v12 attached.
Rebased v13 attached.
Regards,
Jeff Davis
From 8def5ca25901e005c616d9b6989ba5986b7c2c68 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Tue, 2 Jan 2024 13:42:48 -0800
Subject: [PATCH v13] CREATE SUSBCRIPTION .
Hi Evgeny
xid64 path split several threads ,The current one should be this:(
https://www.postgresql.org/message-id/flat/CACG=ezawg7_nt-8ey4akv2w9lculthhknwcawmbgeetnjrj...@mail.gmail.com)
,We can do some tests on path so that can merge earlier
Thanks
On Tue, Dec 10, 2024 at 7:47 PM Evgeny
On Monday, December 16, 2024 7:21 PM Dilip Kumar wrote:
Hi,
>
> On Wed, Dec 11, 2024 at 2:32 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Attach the V16 patch set which addressed above comments.
> >
> > There is a new 0002 patch where I tried to dynamically adjust the interval
> > for
> > advanci
On Mon, Dec 16, 2024 at 6:00 PM Alexander Lakhin wrote:
> It turned out that OpenBSD has semmns as low as 60 (see [4])
Whenever I run into this, or my Mac requires manual ipcrm to clean up
leaked SysV kernel junk, I rebase my patch for sema_kind = 'futex'.
Here it goes. It could be updated to su
Hi,
On Thu, 4 Apr 2024 at 05:42, Daniel Gustafsson wrote:
>
> massasauga and snakefly run the ssl_passphrase_callback-check test but
> none of
> these run the ssl-check tests AFAICT, so we have very low coverage as is.
> The
> fact that very few animals run the ssl tests is a pet peeve of mine,
I wrote:
> While comparing bootstrap.c to postmaster.c, I also noticed that
> bootstrap mode is failing to call set_stack_base(). That means that
> our checks for stack overflow are inoperative in bootstrap mode,
> which doesn't seem great.
> The same omissions appear in PostgresSingleUserMain, me
On Wed, Dec 4, 2024 at 11:38 PM Robert Haas wrote:
> On Sun, Nov 10, 2024 at 7:52 PM Richard Guo wrote:
> > Hmm, currently we only consider grouped aggregation for eager
> > aggregation. For grouped aggregation, the window function's
> > arguments, as well as the PARTITION BY expressions, must a
On Sun, Dec 15, 2024 at 2:18 PM Daniel Gustafsson wrote:
> I think we should, I just now experimented with setting the server major
> version (backed by PG_VERSION_NUM) in the callback struct and added a simple
> test. I'm not sure if there is a whole lot more we need, maybe an opaque
> integer f
On 12/16/24 8:39 AM, Peter Eisentraut wrote:
I'll leave it at this for now and wait for some reviews.
I really like this work since it makes the code cleaner to read on top
of paving the way for threading.
Reviewed the patches and found a couple of issues.
- Shouldn't yyext in syncrep_scann
On Thu, Dec 12, 2024 at 9:39 PM Tomas Vondra wrote:
>
> On 12/11/24 20:18, Masahiko Sawada wrote:
> >
> > ...
> >
> >> Here's an example to exercise the new log message:
> >>
> >> create table foo (a int, b int) with (autovacuum_enabled = false);
> >> insert into foo select generate_series(1,1000)
On Mon, Dec 16, 2024 at 12:26:38PM +, Dagfinn Ilmari Mannsåker wrote:
> s{create tablespace .* location .*\btspitr\K[12]}{N}i for @_;
>
> I think I'm leaning towards the latter, for simplicity and robustness.
Simplicity and robustness works here and in the CI, so I have used the
latter then a
On Wed, Dec 11, 2024 at 2:18 PM Masahiko Sawada wrote:
>
> On Thu, Dec 5, 2024 at 4:32 PM Melanie Plageman
> wrote:
> >
> > On Mon, Dec 2, 2024 at 9:28 AM Robert Haas wrote:
> > >
> > >
> > > All that said, if you really want this broken out into three
> > > categories rather than two, I'm not o
I was experimenting today with running initdb under low-resource
situations (per nearby thread about OpenBSD), and I realized that
"postgres --check" does not provide an adequate check on whether
the specified number of semaphores can be created. That's because
it fails to check whether we can sti
On Wed, Dec 11, 2024 at 11:37:49AM +0500, Kirill Reshke wrote:
> PFAv4
>
> regressdeptestdb1 -> regressiondeptestdb1
The reason I said databases.sql for the test is that CREATE DATABASE is
expensive. We currently have just one successful CREATE DATABASE in the
src/test/regress suite, and we shou
On Mon, 16 Dec 2024 at 22:00, Melanie Plageman
wrote:
> Users wishing to debug slow connection establishment have little
> visibility into which steps take the most time. We don't expose any
> stats and none of the logging includes durations.
Two thoughts:
1. Would it make sense to also expose th
On Mon, Dec 16, 2024 at 12:52 PM Andres Freund wrote:
> I don't see what we gain by requiring guesswork (what does allocating vs
> zeroing mean, zeroing also allocates disk space after all) to interpret the
> main error message. My experience is that it's often harder to get the DETAIL
> than the
While revisiting some old threads, I found this one that seemed to
reach a conclusion, but then it seemed nothing happened.
After multiple suggestions AFAICT James preferred the docs [1]
modification suggested [2] by Laurenz.
Should we make a CF entry for this with the status RfC, or was the
whol
On Tue, Dec 17, 2024 at 02:29:59AM +1300, Thomas Munro wrote:
> On Sun, Dec 15, 2024 at 3:32 PM Noah Misch wrote:
> > For PostgreSQL, I expect the most obvious problems will arise for rolname
> > and
> > datname containing non-UTF8. For example, pg_dumpall relies on
> > appendShellString() to ca
On Mon, 16 Dec 2024 at 21:55, Tom Lane wrote:
> Oh, well if you're willing to cheat like that, sure ;-). I was
> speaking of replacing the existing logic with something that looked
> only at the post-analysis tree.
Yeah, alright. That's not really something that I think we can do
without introdu
On Mon, Dec 16, 2024 at 9:40 PM Nisha Moond wrote:
>
> On Mon, Dec 16, 2024 at 9:58 AM Peter Smith wrote:
> >
...
> > SUGGESTIONS:
> >
> > Docs (idle_replication_slot_timeout): Invalidate replication slots
> > that have remained idle longer than this duration.
> > Docs (idle_timeout): means that
I had a thought about this: I don't think EXPLAIN is ever required
to print the names of join alias variables (since the planner flattens
all join alias variables to some kind of expression over their
underlying columns). So we could skip assigning column names to
join RTEs at all, if we know that
On Mon, Dec 16, 2024 at 08:00:00AM +0100, Andreas 'ads' Scherbaum wrote:
> Can confirm that the crash no longer happens when applying your patch.
The patch looks reasonable to me. I'll commit it soon unless someone
objects. I was surprised to learn that the DSA_ALLOC_HUGE flag is only
intended t
Jeff Davis writes:
> On Tue, 2024-10-22 at 10:40 -0400, Tom Lane wrote:
>> I understand and agree with your conclusion
>> that it's pretty much impossible to do what the SQL standard suggests
>> should happen --- but maybe we're both missing something that would
>> make it feasible.
> It sounds f
On Mon, Dec 16, 2024 at 10:11:23AM +, Bertrand Drouvot wrote:
> +#define PARALLEL_VACUUM_WORKER_DELAY_REPORT_INTERVAL_NS (NS_PER_S)
>
> Did not changed in v14, but "PARALLEL_VACUUM_REPORT_INTERVAL_NS" could be
> an option as well. I think it keeps the key concepts while being more concise
> (
Hi Michael,
On Tue, Dec 10, 2024 at 04:38:24PM +0900, Michael Paquier wrote:
> On Thu, Nov 28, 2024 at 09:17:23PM +0100, Michael Banck wrote:
> > On Tue, Nov 19, 2024 at 07:47:58PM -0500, Greg Sabino Mullane wrote:
> > > Compiled and tested: works fine, so +1 from me. Honestly, I was surprised
> >
On Mon, Dec 16, 2024 at 12:06:33PM +0200, Heikki Linnakangas wrote:
> While working on the CSN snapshot patch, I got sidetracked looking closer
> into the snapshot tracking in snapmgr.c. Attached are a few patches to
> clarify some things.
I haven't yet looked closely at what you are proposing, bu
On Tue, 2024-10-22 at 10:40 -0400, Tom Lane wrote:
> I understand and agree with your conclusion
> that it's pretty much impossible to do what the SQL standard suggests
> should happen --- but maybe we're both missing something that would
> make it feasible.
It sounds feasible for case-insensitive
On 12/16/24 12:49, Jeff Davis wrote:
One question I have is whether we want this function to normalize the
output.
I believe most usecases would want the output normalized, because
normalization differences (e.g. "a" U+0061 followed by "combining
acute" U+0301 vs "a with acute" U+00E1) are more
On Tue, 17 Dec 2024 at 07:10, Nathan Bossart wrote:
> On Mon, Dec 16, 2024 at 09:50:39AM -0800, Paul Ramsey wrote:
> > CREATE TABLE foo (id integer, x integer, y integer);
> > INSERT INTO foo VALUES (1, 0, 1);
> > INSERT INTO foo VALUES (2, 1, 2);
> > INSERT INTO foo VALUES (3, 2, 3);
> >
> > WITH
Hi,
Users wishing to debug slow connection establishment have little
visibility into which steps take the most time. We don't expose any
stats and none of the logging includes durations.
The attached patch logs durations for authentication, forking the
Postgres backend, and the end-to-end connect
Jelte Fennema-Nio writes:
> On Mon, 16 Dec 2024 at 21:09, Tom Lane wrote:
>> However, after thinking a little longer I seem to recall that we've
>> previously looked into the idea of deriving the default aliases from
>> the post-parse-analysis tree. We gave up because there were too many
>> case
On Mon, 16 Dec 2024 at 21:09, Tom Lane wrote:
> Hm. If we made this behavior type-specific then you could have what
> you want without having to break any existing expectations at all.
Yeah, I agree that's definitely the safest. So, that's basically
option 2 I described in my first email, right?
Sami Imseih writes:
>>> Looking further into this improvement, I started to question if it is
>>> necessary to make columns unique for EXPLAIN purposes?
>> Yes, otherwise references to them elsewhere in the plan will be
>> ambiguous.
> Explain will qualify the column name with the table name suc
Jelte Fennema-Nio writes:
> 4. For the custom type that I'm implementing the subscripting for, I
> really don't want such a prefix.
Hm. If we made this behavior type-specific then you could have what
you want without having to break any existing expectations at all.
However, after thinking a li
Andreas Karlsson writes:
> On 12/13/24 12:33 AM, Tom Lane wrote:
>> What I think we should do about this is to teach timestamp
>> input to look into the current IANA time zone to see if it
>> knows the given abbreviation, and if so use that meaning
>> regardless of what timezone_abbreviations migh
On Mon, Dec 16, 2024 at 2:17 PM Peter Geoghegan wrote:
> Maybe it's a good idea, but right now it poses a similar risk to my
> scenario involving a random, isolated SELECT FOR SHARE that happens to
> affect some random tuple on a cold/frozen page. Of course, this
> wouldn't be all that hard to fix
On Sun, Dec 15, 2024 at 06:43:35PM +0100, Michail Nikolaev wrote:
> I have Win 11 with that feature enabled, 200_connstr.pl passes without any
> issues, but 010_dump_connstr.pl fails, yes.
> All other tests seem to be passing, at least without ICU enabled.
>
> 010_dump_connstr.pl log is attached.
On Mon, Dec 16, 2024 at 1:50 PM Melanie Plageman
wrote:
> Then in the next vacuum, we end up scanning those all-frozen pages again
> because the
> ranges of frozen pages are smaller than SKIP_PAGES_THRESHOLD. This is
> mostly going to happen for an insert-only workload. I'm not saying
> freezing
On 12/13/24 12:33 AM, Tom Lane wrote:
What I think we should do about this is to teach timestamp
input to look into the current IANA time zone to see if it
knows the given abbreviation, and if so use that meaning
regardless of what timezone_abbreviations might say. This
isn't particularly hard,
On Mon, 16 Dec 2024 at 19:32, Tom Lane wrote:
> No, sorry, I was just illustrating the behavior with HEAD.
> The important part of this is not the assigned alias
> but the visible cast.
Then I don't think I understand what you're trying to say. While I
think it would be good to not have an explic
On Mon, Dec 16, 2024 at 12:32 PM Peter Geoghegan wrote:
>
> On Mon, Dec 16, 2024 at 10:37 AM Melanie Plageman
> wrote:
> > On a related note, the other day I noticed another negative effect
> > caused in part by SKIP_PAGES_THRESHOLD. SKIP_PAGES_THRESHOLD interacts
> > with the opportunistic freez
Jelte Fennema-Nio writes:
> On Mon, 16 Dec 2024 at 16:34, Tom Lane wrote:
>> View definition:
>> SELECT data['a'::text] AS data
>> FROM tj;
> Are you sure you ran this with my patch?
No, sorry, I was just illustrating the behavior with HEAD.
The important part of this is not the assigned alias
On 12/16/24 6:51 PM, Tomas Vondra wrote:
OK, pushed. Similarly to tho the other tab completion patches I
committed today, I chose not to squash the parts, even though these
changes seem to be in the same area. Seems tidier this way.
Thanks!
Personally I do not care either way. Most committers
Andres Freund writes:
> On 2024-12-16 12:52:46 -0500, Tom Lane wrote:
>> * Why in the world is the default value of max_wal_senders 10?
>> I find it hard to believe that there are installations using
>> more than about 3, and even there you can bet they are changing
>> a lot of other parameters.
Hi,
On 2024-12-16 12:52:46 -0500, Tom Lane wrote:
> or 20 + 3 + 1 + 8 + 10 + 6 = 48. We allocate semaphores in groups
> of SEMAS_PER_SET (16), plus one for identification purposes,
> so with this many semaphores needed we create 3 sets of 17 semaphores
> = 51 semaphores. One more requested semap
Hi all.
I was reviewing nearby thread about parallel index creation for GIN,
and spotted this test [0] :
create table gin_t (a int[]);
insert into gin_t select * from rand_array(3000, 0, 100, 0, 50);
create index on gin_t using gin(a);
v34 fails on this. The reason is we should never check t
Thanks for the report!
On Mon, Dec 16, 2024 at 09:50:39AM -0800, Paul Ramsey wrote:
> Apologies if this is already reported, but there´s a crasher in recursive
> queries at the head of the current development that happened to be
> exercised by our regression suite. Here is a core-only reproduction
Andrew Dunstan writes:
> On 2024-12-16 Mo 12:23 AM, Tom Lane wrote:
>> Yeah. That was more-or-less okay before we invented parallel query,
>> but now there needs to be some headroom. I've thought about adjusting
>> initdb to not allow max_connections less than 25 (can't remember if
>> I actually
Hi,
On 2024-12-16 18:05:59 +0100, Alvaro Herrera wrote:
> On 2024-Dec-16, Robert Haas wrote:
>
> > On Mon, Dec 16, 2024 at 9:12 AM Andres Freund wrote:
> > > Personally I don't like the obfuscation of "allocate" and "zero" vs just
> > > naming the function names. But I guess that's just taste th
On 12/8/24 00:06, Tomas Vondra wrote:
> Hi,
>
> On 11/16/24 17:59, Andreas Karlsson wrote:
>> Hi,
>>
>> Here is a set of small patches which improve the tab completion of joins
>> in psql. The completion of select queries and DML is very primitive in
>> psql but since we already have completion
Apologies if this is already reported, but there’s a crasher in recursive
queries at the head of the current development that happened to be exercised by
our regression suite. Here is a core-only reproduction.
CREATE TABLE foo (id integer, x integer, y integer);
INSERT INTO foo VALUES (1, 0, 1);
On Mon, 16 Dec 2024 at 16:34, Tom Lane wrote:
> I dunno, this seems to be putting an undue amount of emphasis on
> one very specific usage pattern. Why should it matter whether
> the subscripts are string literals or not? What will happen when
> ruleutils decides to dump those expressions with th
On Mon, Dec 16, 2024 at 10:37 AM Melanie Plageman
wrote:
> On a related note, the other day I noticed another negative effect
> caused in part by SKIP_PAGES_THRESHOLD. SKIP_PAGES_THRESHOLD interacts
> with the opportunistic freeze heuristic [1] causing lots of all-frozen
> pages to be scanned when
> > Looking further into this improvement, I started to question if it is
> > necessary to make columns unique for EXPLAIN purposes?
> Yes, otherwise references to them elsewhere in the plan will be
> ambiguous.
Explain will qualify the column name with the table name such as the simple
example b
On 2024-Dec-16, Robert Haas wrote:
> On Mon, Dec 16, 2024 at 9:12 AM Andres Freund wrote:
> > Personally I don't like the obfuscation of "allocate" and "zero" vs just
> > naming the function names. But I guess that's just taste thing.
> >
> > When looking for problems it's considerably more work
Hi,
Every time I create a new file that I want to write a file header comment for
I get confused about the order in which we write them.
The main "patterns" seem to be
/*-
*
* $filename
*$oneline_description
*
*
On 12/8/24 05:22, Kirill Reshke wrote:
> On Sun, 8 Dec 2024 at 03:35, Tomas Vondra wrote:
>>
>> Hi,
>> I took a quick look at this patch series, and it looks generally fine to
>> me. Barring objections, I'll get it committed. Yes, there's a couple
>> cosmetic details, and it needs a pgindent run,
Sami Imseih writes:
> Looking further into this improvement, I started to question if it is
> necessary to make columns unique for EXPLAIN purposes?
Yes, otherwise references to them elsewhere in the plan will be
ambiguous.
It looks like your proposal tries to dodge that by unique-ifying
in some
Recently, a user reported that running an explain for a query joining
many wide tables taking more than 1 minute to complete. Running the
query without explain takes only a few seconds.
Further research showed that this is similar to a report from
2018 [1]. colname_is_unique is used to assign uniq
Hi,
Thank you for working on this!
On Fri, 6 Dec 2024 at 03:32, Melanie Plageman wrote:
>
> Here's an example to exercise the new log message:
>
> create table foo (a int, b int) with (autovacuum_enabled = false);
> insert into foo select generate_series(1,1000), 1;
> delete from foo where a > 5
On 16.12.2024 13:56, Amit Kapila wrote:
On Fri, Dec 13, 2024 at 10:58 AM Peter Smith wrote:
While reviewing the pg_createsubscriber [1] docs I found a potentially
wrong linkend.
This sentence:
"For smaller databases, initial data synchronization is recommended."
links to [2] ("29.4.5. Initial
Hi,
On Mon, Dec 16, 2024 at 05:07:52PM +0900, Michael Paquier wrote:
> On Fri, Dec 13, 2024 at 09:20:13AM +, Bertrand Drouvot wrote:
>
> Not feeling so sure about the value brought by the backend_type
> returned in pg_stat_get_backend_io(), but well..
It's not necessary per say, but it ensur
On Sun, Dec 15, 2024 at 4:47 PM Tomas Vondra wrote:
>
> What's happening is that if the fraction of updated rows is sufficiently
> high, the modified pages are within the SKIP_PAGES_THRESHOLD distance,
> and vacuum switches to seqscan. But with flash storage that happens to
> be harmful - I built
Jelte Fennema-Nio writes:
> SELECT data['a'], data['b'], data['c'] FROM tj;
> Gives the following output:
> data │ data │data
> ──┼───┼
> 123 │ "abc" │ [123, 456]
> I'd much rather have it output:
> a│ b │c
> ──┼───┼
> 123 │ "abc"
Hi hackers,
As noted in previous feedback, relying on pg_shdepend leads to a less-than-ideal
behavior: no privileges are displayed for an object until at least one privilege
is granted to a role other than the owner, as explained by Alvaro:
On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
>
Hi hackers,
After further consideration, I'm withdrawing the patch.
Some fundamental questions remain unresolved:
- Should round-trip fidelity be a strict goal? By "round-trip fidelity",
I mean that data exported and then re-imported should yield exactly
the original values, including the dis
Hi,
On 2024-12-16 14:45:37 +0100, Jakub Wartak wrote:
> On Thu, Dec 12, 2024 at 12:50 AM Andres Freund wrote:
> An extended cycle of 80 backends copying into relations and occasionally
> > truncating them (to simulate the partitions being dropped and new ones
> > created). For this I ran a 4TB fi
On Mon, Dec 16, 2024 at 9:12 AM Andres Freund wrote:
> Personally I don't like the obfuscation of "allocate" and "zero" vs just
> naming the function names. But I guess that's just taste thing.
>
> When looking for problems it's considerably more work with bytes, because - at
> least for me - the
On 2024-12-16 Mo 12:23 AM, Tom Lane wrote:
Alexander Lakhin writes:
I deployed OpenBSD 7.4 locally and reproduced "too many clients" and that
hang as well. It turned out that OpenBSD has semmns as low as 60 (see [4])
and as a consequence, initdb sets max_connections = 20 for the regression
tes
hi. some minor issues...
SET EXPRESSION AS
This form replaces the expression of a generated column. Existing data
in the column is rewritten and all the future changes will apply the new
generation expression.
the second sentence seems not to ap
Hi,
On 2024-12-14 09:29:12 +0100, Alvaro Herrera wrote:
> On 2024-Dec-11, Andres Freund wrote:
>
> > One thing that I think we should definitely do is to include more detail in
> > the error message. mdzeroextend()'s error messages don't include how many
> > blocks the relation was to be extended
Andrey M. Borodin wrote:
> I've addressed all items, except formatting a table...
Sorry for not following up sooner.
To illustrate my point upthread that was left unaddressed, let's say
I have a server with an incorrect date in the future.
A session generates an uuid
postgres=# select
On 16/12/2024 10:00, Alexander Lakhin wrote:
Recently hornet made some noise too: [1], by failing on the test
modification added with e9c8747ee (in REL_13_STABLE):
# issuing query via background psql: SELECT count(*) FROM
t_009_tbl_standby_mvcc
# pump_until: process terminated unexpectedly when
On Thu, Dec 12, 2024 at 12:50 AM Andres Freund wrote:
> Hi,
>
> FWIW, I tried fairly hard to reproduce this.
>
Same, but without PG and also without much success. I've also tried to push
the AGs (with just one or two AGs created via mkfs) to contain only small
size extents (by creating hundreds
I'm working on implementing subscripts for a custom type, but one
usability issue I'm running into is that the default column names for
subscript expressions are rather bad.
The easiest way to show this is with json. Running the following in psql:
CREATE TABLE tj(data jsonb);
INSERT INTO tj value
On Sun, Dec 15, 2024 at 3:32 PM Noah Misch wrote:
> For PostgreSQL, I expect the most obvious problems will arise for rolname and
> datname containing non-UTF8. For example, pg_dumpall relies on
> appendShellString() to call pg_dump for arbitrary datname. pg_dumpall would
> get "database ... doe
On Sat, Dec 14, 2024 at 4:20 AM Thomas Munro wrote:
> On Sat, Dec 14, 2024 at 9:29 PM Alvaro Herrera
> wrote:
> > On 2024-Dec-11, Andres Freund wrote:
> > > One thing that I think we should definitely do is to include more detail
> > > in
> > > the error message. mdzeroextend()'s error messages
Hi,
Thanks for updating the patch and here are some comments:
'path' column of pg_get_process_memory_contexts() begins with 0, but
that column of pg_backend_memory_contexts view begins with 1:
=# select path FROM pg_get_process_memory_contexts('20271', false);
path
---
{0}
{0,
Michael Paquier writes:
> On Sun, Dec 15, 2024 at 10:34:07AM +0900, Michael Paquier wrote:
>> Indeed, good catch. I'll take care of it.
Thanks!
> +sub {
> +s{create tablespace .* location '.*/tspitr\K[12]}{N}i for @_;
> +return $_[0] ne $_[1];
> +});
>
> The CI is compl
Hi,
Thank you for your interest in this thread.
> You could create database on RAM disk and make benchmarks.
According to your advice, I created RAM disk and put input files and data
directory on RAM disk.
But the result changed only a few seconds.
In this test case, the table is unlogged ta
Hi,
Thank you for your reply.
I tried your patch and report in this e-mail.
> 1. Those code paths finish up in pg_pwritev(), but it has a loop over
> 8kb writes on Windows. Does it help if we just make "zbuffer" bigger?
> How big?
This patch improves the performance.
I applied 0001-Use-bigg
On Mon, Dec 16, 2024 at 6:14 PM Ashutosh Bapat
wrote:
>
> Hi Junwang,
>
> >
> > I'm looking at the catalog definition, I have some questions which
> > might be silly.
>
> Thanks for your interest in SQL/PGQ.
>
> >
> > Each pg element can have multiple labels(whose properties belong
> > to the same
On Mon, 16 Dec 2024 at 12:05, vignesh C wrote:
> I prefer the other approach to remove both the checks in
> getPublicationTables() and getPublicationNamespaces() which also makes
> it consistent with the other case that Amit mentioned at [1].
If I understand your suggestion correctly I think this
On Fri, Dec 13, 2024 at 1:57 PM jian he wrote:
> On Wed, Dec 11, 2024 at 7:41 PM Nishant Sharma
> wrote:
> >
> > Thanks for the v3 patch!
> >
> > Please find review comments on v3:-
> >
> > 1) I think no need to change the below if condition, we can keep
> > it the way it was before i.e with
> >
On Wed, Dec 11, 2024 at 2:32 PM Zhijie Hou (Fujitsu)
wrote:
>
> Attach the V16 patch set which addressed above comments.
>
> There is a new 0002 patch where I tried to dynamically adjust the interval for
> advancing the transaction ID. Instead of always waiting for
> wal_receiver_status_interval,
On 09.12.24 18:20, Tom Lane wrote:
walsender.h should depend on xlog.h, not vice versa. (Actually, the
inclusion was circular until a couple hours ago, which was even sillier;
but Bruce broke it in the expedient rather than logically correct
direction.) Because of that poor
Hello, I am working on query time optimization on some data structures. I
am recently working on multi dimensional queries. I am using cube to multi
dimensions. I have a table in my database what named points and it has a
column what named point. Point column has 10 dimensions. I can perform a
data
On Sat, 14 Dec 2024 at 05:27, Tom Lane wrote:
>
> [ reviving one aspect of an old thread ]
>
> vignesh C writes:
> > On Mon, Jul 19, 2021 at 9:32 AM tanghy.f...@fujitsu.com <
> > tanghy.f...@fujitsu.com> wrote:
> >> I tested your v12 patch and found a problem in the following case.
> >>
> >> Step
1 - 100 of 112 matches
Mail list logo
