On Wed Apr 2, 2025 at 6:58 PM PDT, Sami Imseih wrote:
>> > + indexes. If performance degrades after making an index invisible, it can
>> > be easily
>> > + be made visible using VISIBLE. Before making an index
>> > invisible, it's recommended
>> > + to check
>> > pg_stat_user_indexes.idx_scan
>>
On Sun, Sep 22, 2024 at 3:45 PM David Rowley wrote:
> I think the documents should also mention that disabling an index is a
> useful way to verify an index is not being used before dropping it as
> the index can be enabled again at the first sign that performance has
> been effected. (It might a
On Sun, Mar 30, 2025 at 4:31 AM Heikki Linnakangas wrote:
>
> On 30/03/2025 13:23, Etsuro Fujita wrote:
> > While working on something else I noticed $SUBJECT: we are allocating
> > more memory than necessary and copying more data than necessary
> > because we specify the wrong PgStat_KindInfo mem
On Sun Mar 30, 2025 at 4:39 AM PDT, Heikki Linnakangas wrote:
> On 30/03/2025 14:32, Heikki Linnakangas wrote:
>> On 30/03/2025 13:28, Etsuro Fujita wrote:
>>> Another thing I noticed is $SUBJECT: I think “if lock could not
>>> immediately acquired” should be “if lock could not be immediately
>>> a
Please see attached a few minor edits to README.tuplock, which I feel
make an improvement over the current version.
Reading through that, though, I could not see a functional difference
between FOR NO KEY UPDATE and FOR KEY SHARE mode of locks. I understand
they are of different strength, exclusiv
ch
it did not.
It definitely did not feel like a -1.
On Mon, Mar 3, 2025 at 8:40 AM Robert Haas wrote:
>
> On Sun, Mar 2, 2025 at 1:10 AM Gurjeet Singh wrote:
> > I propose the following change to the generation script,
> > generate-lwlocknames.pl
> >
> > - pri
+Andres Freund, since an old email of his is quoted here.
On Fri, Mar 14, 2025 at 8:45 AM Nathan Bossart wrote:
>
> On Thu, Mar 06, 2025 at 08:54:59AM +0900, Fujii Masao wrote:
> > +1 to having the reloption (if specified) override the GUC setting.
> > That is, I think that autovacuum_vacuum_trun
On Sat, Mar 1, 2025 at 10:26 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > I propose the following change to the generation script,
> > generate-lwlocknames.pl
> > ...
> > which produces the lock names in this format
>
> > #define ShmemIndexLock
Currently the contents of lwlocknames.h look like this:
#define ShmemIndexLock (&MainLWLockArray[1].lock)
#define OidGenLock (&MainLWLockArray[2].lock)
#define XidGenLock (&MainLWLockArray[3].lock)
#define ProcArrayLock (&MainLWLockArray[4].lock)
#define SInvalReadLock (&MainLWLockArray[5].lock)
.
On Mon, Jan 27, 2025 at 1:55 AM Laurenz Albe wrote:
>
> On Thu, 2025-01-23 at 22:33 -0800, Gurjeet Singh wrote:
> > > > I am also wondering if having an autovacuum setting to control it would
> > > > be
> > > > a good idea for a feature.
> > >
ehaviour on just one database. So leaving the parameter context to be the same
as most other autovacuum parameters: SIGHUP.
Best regards,
Gurjeet
http://Gurje.et
commit 84e8eebb87bc2c58feae847efd995bc055701688
Author: Gurjeet Singh
Date: Thu Jan 23 19:37:33 2025 -0800
Version 1
diff --git a/src/ba
I was working on an extension [1] that needed to manage a list of query IDs.
Query ID is internally of type uint64 (struct Query's member named queryId),
but it is exposed to the SQL layer as signed int64 (e.g
pg_stat_activity.query_id is of type bigint).
I wanted to use the list api from pg_list.
On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>
> Attached is the patch for this.
Hi Tatsuo,
I believe the newline endings in your patches are causing the patch application
to fail. I experienced this with your initial patch, as well as with the latest
patch. Converting it to unix-style lin
On Fri, Dec 27, 2024 at 9:46 PM Tatsuo Ishii wrote:
>
>
> With opinions from Michael and David , what about following additional APIs?
...
> #define makeStringInfo
> makeStringInfoExtended(STRINGINFO_DEFAULT_SIZE)
Minor nit: the definition of the macro should contain parentheses, like s
On Tue, Dec 31, 2024 at 12:50 PM David G. Johnston
wrote:
>
> Thoughts?
>
> On Fri, Dec 20, 2024 at 9:02 AM David G. Johnston
> wrote:
>>
>> Hi,
>>
>> The commit reference page lacks an "Outputs" section even though it is
>> capable of outputting both "COMMIT" and "ROLLBACK".
>>
>> The attached
On Mon, Nov 4, 2024 at 7:02 PM Ryohei Takahashi (Fujitsu)
wrote:
>
> On the other hand, pgevent.dll is moved from lib/ directory to bin/directory
> on PG 17.0
>
> (It seems that it is moved because of meson)
>
> So, I think the documentation need to be updated like attached.
I'm unable to confir
Is there a desire to have a division operator / that takes dividend
and divisor of types interval, and results in a quotient of type
double precision.
This would be helpful in calculating how many times the divisor
interval can fit into the dividend interval.
To complement this division operator,
On Fri, Nov 17, 2023 at 11:02 AM Jeff Davis wrote:
>
> I had briefly experimented changing the hash table in guc.c to use
> simplehash. It didn't offer any measurable speedup, but the API is
> slightly nicer.
>
> I thought I'd post the patch in case others thought this was a good
> direction or ni
On Fri, Nov 17, 2023 at 12:13 PM Andres Freund wrote:
>
> On 2023-11-17 10:42:54 -0800, Jeff Davis wrote:
> > Right now, if allocation fails while growing a hashtable, it's left in
> > an inconsistent state and can't be used again.
+1 to the patch.
> I'm not against allowing this - but I am curi
The commit message in the attached patch provides the reasoning, as follows:
The user does not benefit from knowing that libpq allocates some/all memory
using malloc(). Mentioning malloc() here has a few downsides, and almost no
benefits.
All the relevant mentions of malloc() are followed by an e
On Fri, Oct 20, 2023 at 7:30 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> There exists an extraneous break condition in
> pg_logical_replication_slot_advance(). When the end of WAL or moveto
> LSN is reached, the main while condition helps to exit the loop, so no
> separate break condition is needed. A
The attached patch adds the word 'databases' to show that template0,
template1 and postgres are databases in a default installation.
Best regards,
Gurjeet
http://Gurje.et
pg_upgrade.implementation.diff
Description: Binary data
On Mon, Oct 9, 2023 at 2:31 AM Gurjeet Singh wrote:
>
> Next steps:
> - Break the patch into a series of smaller patches.
Please see attached the same v3 patch, but now split into 3 separate
patches. Each patch in the series depends on the previous patch to
have been applied. I have
On Sun, Oct 8, 2023 at 1:01 PM Gurjeet Singh wrote:
>
> On Fri, Oct 6, 2023 at 1:29 PM Jeff Davis wrote:
> >
> > On Thu, 2023-10-05 at 14:28 -0700, Gurjeet Singh wrote:
> >
> > > This way there's a notion of a 'new' and 'old' passwords.
On Fri, Oct 6, 2023 at 1:29 PM Jeff Davis wrote:
>
> On Thu, 2023-10-05 at 14:28 -0700, Gurjeet Singh wrote:
>
> > This way there's a notion of a 'new' and 'old' passwords.
>
> IIUC, you are proposing that there are exactly two slots, NEW and OLD.
&
On Sun, Oct 8, 2023 at 10:29 AM Bruce Momjian wrote:
>
> I was speaking of autoremoving in cases where we are creating a new one,
> and taking the previous new one and making it the old one, if that was
> not clear.
Yes, I think I understood it differently. I understood it to mean that
this behav
On Fri, Oct 6, 2023 at 1:46 PM Bruce Momjian wrote:
>
> On Fri, Oct 6, 2023 at 01:20:03PM -0700, Jeff Davis wrote:
> > The basic problem, as I see it, is: how do we keep users from
> > accidentally dropping the wrong password? Generated unique names or
>
> I thought we could auto-remove old passw
On Thu, Oct 5, 2023 at 1:09 PM Jeff Davis wrote:
>
> >
> > I think this would be mighty confusing to users since it's not clear
> > that
> > adding a password will potentially invalidate a current password
> > (which
> > might be actively in use), but only if there are already 2 in the
> > stack.
On Thu, Oct 5, 2023 at 12:04 PM Nathan Bossart wrote:
>
> On Wed, Oct 04, 2023 at 10:41:15PM -0700, Gurjeet Singh wrote:
> > The patches posted in this thread so far attempt to add the ability to
> > allow the user to have an arbitrary number of passwords. I believe
> >
On Thu, Oct 5, 2023 at 1:52 AM Jon Erdman wrote:
>
> So I have some good news! At long last I've found a company/manager that
> wants to actually factually pay me to do some work on PG!!
Congratulations!
> For the proposal (this one is a bit Apple specific): because my team
> offers managed post
I had an idea to simplify this feature/patch and after some validation
in internal discussions, I am posting the new approach here. I'd
appreciate any feedback and comments.
To begin with, the feature we are chasing is to make it convenient for
the users to rollover their passwords. Currently ther
On Tue, Sep 26, 2023 at 4:02 PM Bruce Momjian wrote:
>
> Patch applied back to PG 11.
+Peter E. since I received the following automated note:
> Closed in commitfest 2023-09 with status: Moved to next CF (petere)
Just a note that this patch has been committed (3fea854691), so I have
marked the
On Fri, Sep 8, 2023 at 7:52 AM Bruce Momjian wrote:
>
> On Thu, Sep 7, 2023 at 09:21:07PM -0700, Nathan Bossart wrote:
> > On Thu, Sep 07, 2023 at 07:13:44PM -0400, Bruce Momjian wrote:
> > > On Thu, Sep 7, 2023 at 02:54:13PM -0700, Nathan Bossart wrote:
> > >> IMO the phrase "open a port" is ki
Currently, psql exits if a database connection is not established when
psql is launched.
Sometimes it may be useful to launch psql without connecting to the
database. For example, a user may choose to start psql and then pipe
commands via stdin, one of which may eventually perform the \connect
com
On Wed, Apr 26, 2023 at 4:48 AM David Rowley wrote:
>
> On Sun, 23 Apr 2023, 3:42 am Gurjeet Singh, wrote:
>>
>> I anticipate that edits to Appendix K Postgres Limits will prompt
>> improving the note in there about the maximum column limit, That note
>> is too
On Sun, Jul 23, 2023 at 6:09 AM Ahmed Ibrahim
wrote:
>
> Hi everyone,
>
> I have been working on this. This is a proposed patch for it so we have a
> force option for DROPping the database.
>
> I'd appreciate it if anyone can review.
Hi Ahmed,
Thanks for working on this patch!
+
+int
On Fri, Jul 21, 2023 at 7:17 PM Dean Rasheed wrote:
>
> On Mon, 17 Jul 2023 at 20:43, Jeff Davis wrote:
> >
> > > > Maybe instead of a function it could be a special table reference
> > > > like:
> > > >
> > > > MERGE ... RETURNING MERGE.action, MERGE.action_number, id, val?
> > > >
> > The ben
On Mon, Jul 24, 2023 at 9:26 AM Tristan Partin wrote:
> attached patch
+/*
+ * Restore the default SIGINT behavior while within libpq.
Otherwise, we
+ * can never exit from polling for the database connection. Failure to
+ * restore is non-fatal.
+ */
+
On Fri, Jul 21, 2023 at 10:42 AM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > Please see attached the patch that does this. Let me know if this patch
> > helps.
>
> I don't like this patch one bit, because it adds a lot of overhead
> (i.e., an extra index_open/c
On Thu, Jul 20, 2023 at 11:38 PM Junwang Zhao wrote:
>
> On Fri, Jul 21, 2023 at 2:26 PM Michael Paquier wrote:
> >
> > On Fri, Jul 21, 2023 at 02:05:56PM +0800, Junwang Zhao wrote:
> > > I noticed there are some places calling table_open with
> > > RowExclusiveLock but table_close with NoLock, l
On Mon, Jul 17, 2023 at 12:43 PM Jeff Davis wrote:
>
> On Fri, 2023-07-14 at 09:55 +0100, Dean Rasheed wrote:
> > I found a 10-year-old thread discussing adding support for OLD/NEW to
> > RETURNING [1], but it doesn't look like anything close to a
> > committable solution was developed, or even a
On Fri, Jul 14, 2023 at 1:55 AM Dean Rasheed wrote:
>
> On Thu, 13 Jul 2023 at 20:14, Jeff Davis wrote:
> >
> > On Thu, 2023-07-13 at 18:01 +0100, Dean Rasheed wrote:
> > > For some use cases, I can imagine allowing OLD/NEW.colname would mean
> > > you wouldn't need pg_merge_action() (if the colu
On Thu, Jul 20, 2023 at 2:10 AM Daniel Gustafsson wrote:
>
> > On 19 Jul 2023, at 19:28, Gurjeet Singh wrote:
> >
> > The docs for 'pg_restore --create` say "Create the database before
> > restoring into it. If --clean is also specified, drop and re
On Tue, Jul 11, 2023 at 9:35 AM Ahmed Ibrahim
wrote:
>
> We have been working on the pg_adviser extension whose goal is to suggest
> indexes by creating virtual/hypothetical indexes and see how it affects the
> query cost.
>
> The hypothetical index shouldn't take any space on the disk (allocate
On Tue, Jul 18, 2023 at 12:53 AM Joan wrote:
>
> Since posgres 13 there's the option to do a FORCE when dropping a database
> (so it disconnects current users) Documentation here:
> https://www.postgresql.org/docs/current/sql-dropdatabase.html
>
> I am currently using dir format for the output
>
On Mon, Jul 17, 2023 at 1:47 PM Nathan Bossart wrote:
>
> Here is a new version of the patch in which I've updated this comment as
> proposed. Gurjeet, do you have any other concerns about this patch?
With the updated comment, the patch looks good to me.
Best regards,
Gurjeet
http://Gurje.et
On Thu, Jul 13, 2023 at 1:37 PM David G. Johnston
wrote:
>
> I'm against simply breaking the past without any recourse as what we did for
> pg_dump/pg_restore still bothers me.
I'm sure this is tangential, but can you please provide some
context/links to the change you're referring to here.
Be
On Thu, Jul 13, 2023 at 11:56 AM Jeff Davis wrote:
>
> The current approach seemed to get support from Noah, Nathan, and Greg
> Stark.
>
> Concerns were raised by Gurjeet, Tom, and Robert in the 16 cycle; but
I didn't see Tom's or Robert's concerns raised in this thread. I see
now that for some r
On Thu, Jul 13, 2023 at 8:38 AM Dean Rasheed wrote:
>
> On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh wrote:
> > { oid => '9499', descr => 'command type of current MERGE action',
> > - proname => 'pg_merge_action', provolatile =>
On Wed, Jul 12, 2023 at 5:22 PM Matheus Alcantara wrote:
>
> I was reading the jit implementation and I notice that the lljit field of
> LLVMJitHandle is being assigned twice on llvm_compile_module function, is this
> correct? I'm attaching a supposed fixes that removes the second assignment. I
>
On Wed, Jul 12, 2023 at 1:03 PM Dave Cramer wrote:
>
> With a simple insert such as
>
> INSERT INTO test_table (cnt) VALUES (1), (2) RETURNING id
>
> if a portal is used to get the results then the CommandStatus is not returned
> on the execute only when the portal is closed. After looking at thi
On Wed, Jul 12, 2023 at 3:08 AM Peter Eisentraut wrote:
>
> On 12.07.23 09:42, Gurjeet Singh wrote:
> > These two variants show the two extremes; bare minimum vs. everything
> > but the kitchen sink. So one may feel the need to find a middle ground
> > and provide a "
These patches were created during an unrelated discussion about pgbench.
Please see emails [1] - [6] linked below, for the past discussion.
In brief:
> $ pgbench -i -I dtGvp -s 500
The init-steps are severely under-documented in pgbench --help output.
I think at least a pointer to the the p
On Tue, Jul 11, 2023 at 1:43 PM Gurjeet Singh wrote:
>
> In the above hunk, if there's an exception/ERROR, I believe we should
> PG_RE_THROW(). If there's a reason to continue, we should at least set
> rslot = NULL, otherwise we may be returning an uninitialized value to
>
On Fri, Jul 7, 2023 at 3:48 PM Dean Rasheed wrote:
>
> On Thu, 6 Jul 2023 at 06:13, Gurjeet Singh wrote:
> >
> > > One minor annoyance is that, due to the way that pg_merge_action() and
> > > pg_merge_when_clause() require access to the MergeActionState, they
On Mon, Jun 19, 2023 at 5:48 PM Bruce Momjian wrote:
>
> On Tue, Jun 13, 2023 at 11:11:04PM -0400, Tom Lane wrote:
> >
> > There is certainly an argument that such a condition indicates that
> > something's very broken in our configuration and we should complain.
> > But I'm not sure how exciting
On Sun, Jul 9, 2023 at 7:18 AM Tom Lane wrote:
>
> Michael Paquier writes:
> > That should be OK, I assume. However, if this is improved and
> > something we want to support in the long-run I guess that a TAP test
> > may be appropriate.
>
> I do not see the point of a TAP test. It's not like t
On Sun, Jul 9, 2023 at 7:21 AM Richard Veselý wrote:
>
> ... there's no shortage of people that suffer from sluggish
> pg_dump/pg_restore cycle and I imagine there are any number of people that
> would be interested in improving bulk ingestion which is often a bottleneck
> for analytical worklo
On Sat, Jul 8, 2023 at 1:33 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
> >> The ECPG datetime datatype support code has been basically unmaintained
> >> for years, and has diverged quite far at this point from th
On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
>
> The ECPG datetime datatype support code has been basically unmaintained
> for years, and has diverged quite far at this point from the core code.
I was under the impression that anything in the postgresql.git
repository is considered core, and he
On Fri, Jul 7, 2023 at 6:12 AM Ranier Vilela wrote:
>
> Hi,
>
> This has already been discussed in [1].
> But I thought it best to start a new thread.
>
> The commit 31966b1 introduced the infrastructure to extend
> buffers.
> But the patch mixed types with int and uint32.
> The correct type of th
On Fri, Jul 7, 2023 at 9:33 AM Jeff Davis wrote:
>
> On Sat, 2023-06-17 at 09:09 -0700, Gurjeet Singh wrote:
> > The docs for the CREATE COLLATION option 'locale' say: "This is a
> > shortcut for setting LC_COLLATE and LC_CTYPE at once."
> >
>
On Thu, Jul 6, 2023 at 12:37 AM Masahiko Sawada wrote:
> On Sat, Jul 1, 2023 at 8:57 AM Joe Conway wrote:
> >
> > The basic idea is to mirror how pg_stat_statements works, except the
> > logged messages keyed by filename, lineno, and elevel are saved with a
> > aggregate count. The format string
On Thu, Jul 6, 2023 at 11:27 AM Daniel Gustafsson wrote:
>
> > On 6 Jul 2023, at 20:10, Gurjeet Singh wrote:
>
> > I can
> > imagine if cfbot was developed against some other CI, it's very likely
> > that we'd be using that other CI instead of Cirrus.
&
On Thu, Jul 6, 2023 at 8:01 AM Karina Litskevich
wrote:
>
>
>> EB_SMGR and EB_REL are macros for making new structs.
>> IMO these are buggy, once make new structs without initializing all fields.
>> Attached a patch to fix this and make more clear when rel or smgr is NULL.
>
>
> As long as a struc
On Wed, Jul 5, 2023 at 6:22 AM Andrew Dunstan wrote:
>
>
> On 2023-07-04 Tu 19:44, Newhouse, Robin wrote:
>
> Hello!
>
>
>
> I propose the attached patch to be applied on the 'master' branch
>
> of PostgreSQL to add GitLab CI automation alongside Cirrus CI in the
> PostgreSQL repository.
>
>
>
>
On Thu, Jul 6, 2023 at 4:07 AM jian he wrote:
>
> On Thu, Jul 6, 2023 at 1:13 PM Gurjeet Singh wrote:
> > I think the name of function pg_merge_when_clause() can be improved.
> > How about pg_merge_when_clause_ordinal().
>
> another idea: pg_merge_action_ordinal()
On Thu, Jul 6, 2023 at 3:39 AM Alvaro Herrera wrote:
>
> On 2023-Jul-05, Gurjeet Singh wrote:
> > I expected the .out file to have captured the stdout. I'm gradually,
> > and gladly, re-learning bits of the test infrastructure.
> >
> > The DELETE comm
On Sat, Jul 1, 2023 at 4:08 AM Dean Rasheed wrote:
>
> On Mon, 13 Mar 2023 at 13:36, Dean Rasheed wrote:
> >
> > And another rebase.
> >
>
> I ran out of cycles to pursue the MERGE patches in v16, but hopefully
> I can make more progress in v17.
>
> Looking at this one with fresh eyes, it looks m
On Tue, Jun 27, 2023 at 9:57 PM Nathan Bossart wrote:
>
> While looking at something unrelated, I noticed that the vacuumdb docs
> mention the following:
>
> vacuumdb might need to connect several times to the PostgreSQL server,
> asking for a password each time.
>
> IIUC this has
On Wed, Jun 14, 2023 at 9:48 PM Jeff Davis wrote:
>
> Currently, CREATE COLLATION always defaults the provider to libc.
>
> The attached patch causes it to default to libc if LC_COLLATE/LC_CTYPE
> are specified, otherwise default to the current database default
> collation's provider.
+
On Fri, Jun 16, 2023 at 1:56 PM Tristan Partin wrote:
>
> On Fri Jun 16, 2023 at 3:29 PM CDT, Jeff Davis wrote:
> > Patch attached. Currently, the Makefile specifies NO_LOCALE=1, and the
> > meson.build does not.
>
> Looks alright to me, but it might be nicer to change the order of
> arguments to
On Wed, Jun 14, 2023 at 5:12 AM Ranier Vilela wrote:
>
> Em qua., 14 de jun. de 2023 às 06:51, Richard Guo
> escreveu:
>>
>>
>> On Tue, Jun 13, 2023 at 3:39 PM Kyotaro Horiguchi
>> wrote:
>>>
>>> Gurjeet has mentioned that eb.rel cannot be modified by another
>>> process since the value or mem
On Mon, Jun 12, 2023 at 10:59 PM Nathan Bossart
wrote:
> On Sat, May 27, 2023 at 03:17:21PM -0700, Gurjeet Singh wrote:
> > If listen_addresses is empty, then server won't try to open any TCP/IP
> > ports. The patch does not change any language related to that.
>
> Your
On Mon, Jun 5, 2023 at 8:58 AM Kirk Wolak wrote:
>
> Everyone,
> After recently deep diving on some readline features and optimizing my bash
> environment to have a static set of "snippets" that I can always find...
>
> it takes just a couple of history API calls to add some interesting
> fe
On Mon, Jun 5, 2023 at 4:24 AM Ranier Vilela wrote:
> Em seg., 5 de jun. de 2023 às 08:06, Ranier Vilela
> escreveu:
>> Em dom., 4 de jun. de 2023 às 23:37, Richard Guo
>> escreveu:
>>> On Sun, Jun 4, 2023 at 8:42 PM Ranier Vilela wrote:
Hi,
Per Coverity.
At function
On Fri, Jun 9, 2023 at 6:20 PM Gurjeet Singh wrote:
> On Fri, Jun 9, 2023 at 5:42 PM Gregory Smith wrote:
> > On Fri, Jun 9, 2023 at 1:25 PM Gurjeet Singh wrote:
> >>
> >> > $ pgbench -i -I dtGvp -s 500
> >>
> >> The steps are severely unde
On Fri, Jun 9, 2023 at 5:42 PM Gregory Smith wrote:
>
> On Fri, Jun 9, 2023 at 1:25 PM Gurjeet Singh wrote:
>>
>> > $ pgbench -i -I dtGvp -s 500
>>
>> The steps are severely under-documented in pgbench --help output.
>
>
> I agree it's not
On Fri, Jun 9, 2023 at 2:00 PM Jeff Davis wrote:
>
> On Thu, 2023-06-08 at 21:55 -0700, Nathan Bossart wrote:
> > On Thu, Jun 08, 2023 at 06:08:08PM -0400, Greg Stark wrote:
> > > I guess that's pretty narrow and a reasonable thing to desupport.
> > > Users could just mark those functions with sea
On Fri, Jun 9, 2023 at 6:24 AM Gregory Smith wrote:
>
> Unfortunately there's no simple command line option to change just that one
> thing about how pgbench runs. You have to construct a command line that
> documents each and every step you want instead. You probably just want this
> form:
>
On Fri, Jun 9, 2023 at 12:28 AM Gregory Smith wrote:
>
> Let me start with the happy ending to this thread:
Phew! I'm sure everyone would be relieved to know this was a false alarm.
> On Thu, Jun 8, 2023 at 9:21 PM Andres Freund wrote:
>>
>> You might need to add --no-children to the perf repor
On Thu, Jun 8, 2023 at 7:35 AM Tom Lane wrote:
>
> o.tselebrovs...@postgrespro.ru writes:
> > While working on an extension I've found an error in how length of
> > encoded base64 string is calulated;
>
> Yeah, I think you're right. It's not of huge significance, because
> it just overestimates b
On Wed, Jun 7, 2023 at 7:31 AM Tristan Partin wrote:
>
> This patch is really not necessary from a functional point of view. It
> is only necessary if we want to silence a compiler warning.
>
> Tested on `gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)`.
...
> From my perspective, this warning defi
e report!
Best regards,
Gurjeet
http://Gurje.et
From f694a97e72a3ad744073c9a04f3c39615b1a9987 Mon Sep 17 00:00:00 2001
From: Gurjeet Singh
Date: Thu, 8 Jun 2023 19:30:57 -0700
Subject: [PATCH v1] Fix grammar
As reported by Daniel Westermann.
---
src/backend/access/nbtree/README | 2 +-
1 file changed
On Sat, Apr 22, 2023 at 4:33 PM Julien Rouhaud wrote:
>
> Hi,
>
> On Sat, Apr 22, 2023 at 12:53:23PM -0400, Isaac Morland wrote:
> >
> > I have an application for this: creating various dev/test versions of data
> > from production.
> >
> > Start by restoring a copy of production from backup. Then
On Mon, Jun 5, 2023 at 12:32 AM Laurenz Albe wrote:
>
> On Mon, 2023-06-05 at 00:22 -0700, Gurjeet Singh wrote:
> > On Sat, Apr 22, 2023 at 8:01 AM Gurjeet Singh wrote:
> > >
> > > This is a proposal for a new transaction characteristic. I haven't
> > &
On Sat, Apr 22, 2023 at 8:01 AM Gurjeet Singh wrote:
>
> This is a proposal for a new transaction characteristic. I haven't
> written any code, yet, and am interested in hearing if others may find
> this feature useful.
Please see attached the patch that introduces this new f
The attached patch clarifies that the server will start even if it is
unable to open the port on some of the TCP/IP addresses listed (or
implied by a value of '*' or localhost) in listen_addresses parameter.
I think it is important to call this out, because I was surprised to
see that the server s
On Tue, Aug 31, 2021 at 10:02 AM Gurjeet Singh wrote:
> On Tue, Aug 31, 2021 at 8:04 AM Alvaro Herrera
> wrote:
>
> > You know what I've heard? That your index advisor module languishes
> > unmaintained and that there's no shortage of people wishing to use it.
&
On Mon, Apr 24, 2023 at 5:14 AM Daniel Gustafsson wrote:
> > On 21 Apr 2023, at 18:38, Gurjeet Singh wrote:
> >
> > On Fri, Apr 21, 2023 at 7:47 AM Robert Haas
> wrote:
> >>
> >> On Fri, Apr 21, 2023 at 8:25 AM Daniel Gustafsson
> wrote:
> >>
On Fri, Apr 21, 2023 at 12:14 AM Nikita Malakhov wrote:
> This limitation applies not only to wide tables - it also applies to tables
> where TOASTed values
> are updated very often. You would soon be out of available TOAST value ID
> because in case of
> high frequency updates autovacuum cleanu
On Thu, Dec 22, 2022 at 10:07 AM Nikita Malakhov wrote:
> Any suggestions on the previous message (64-bit toast value ID with
> individual counters)?
Was this patch ever added to CommitFest? I don't see it in the current
Open Commitfest.
https://commitfest.postgresql.org/43/
Best regards,
Gurj
This is a proposal for a new transaction characteristic. I haven't
written any code, yet, and am interested in hearing if others may find
this feature useful.
Many a times we start a transaction that we never intend to commit;
for example, for testing, or for EXPLAIN ANALYZE, or after detecting
un
On Fri, Apr 21, 2023 at 10:15 AM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 21.04.23 16:28, Imseih (AWS), Sami wrote:
> >> I suggest a small doc fix:
> >> “Note that for a complex query, several sort or hash operations might be
> >> running simultaneously;”
>
> > Here is a discussion of
On Fri, Apr 21, 2023 at 7:47 AM Robert Haas wrote:
>
> On Fri, Apr 21, 2023 at 8:25 AM Daniel Gustafsson wrote:
> > The reason I left it like this when reviewing and committing is that I
> > think it
> > makes for more readable code. The amount of lines saved is pretty small,
> > and
> > "shuf
On Thu, Apr 20, 2023 at 11:00 PM Gurjeet Singh wrote:
>
> Commit 7f5b198 introduced TAP tests that use string literals to mark
> the presence of a query in server logs. For no explicable reason, the
> tests with the marker 'connect2' occur before the tests that use
> &
Commit 7f5b198 introduced TAP tests that use string literals to mark
the presence of a query in server logs. For no explicable reason, the
tests with the marker 'connect2' occur before the tests that use
'connect1' marker.
The attached patch swaps the connection marker strings so that a
reader doe
Commit [1] implements Fisher-Yates shuffling algorithm to shuffle
connection addresses, in two places.
The attached patch moves the duplicated code to a function, and calls
it in those 2 places.
[1]: Support connection load balancing in libpq
7f5b19817eaf38e70ad1153db4e644ee9456853e
Best regards
On Thu, Apr 20, 2023 at 9:31 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > When reviewing a recently committed patch [1] I noticed the odd usage
> > of a format specifier:
>
> > + libpq_append_conn_error(co
When reviewing a recently committed patch [1] I noticed the odd usage
of a format specifier:
+ libpq_append_conn_error(conn, "invalid %s value: \"%s\"",
+ "load_balance_hosts",
+ conn->load_balance_hosts);
The oddity is
1 - 100 of 154 matches
Mail list logo
