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
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
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
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.
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.
> >
> > IIUC,
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.
> When adding a pas
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
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
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
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
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
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
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
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/close
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,
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
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 recreat
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
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.
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
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 => 'v',
> > + proname =>
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
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
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
> the
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
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
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
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
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
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 command t
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
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
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
>
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 easy
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
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
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
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
ort!
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, 1 i
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.
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
> > > w
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 featur
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
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
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,
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
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
> >
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
> 'c
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
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
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
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak wrote:
> I love that my proposal for %T in the prompt, triggered some great
> conversations.
>
> This is not instead of that. That lets me run a query and come back HOURS
> later, and know it finished before 7PM like it was supposed to!
Neat! I
On Mon, Jan 30, 2023 at 11:50 PM Gurjeet Singh wrote:
> It was the classical case of out-of-bounds access.
> This mistake would've been caught early if there were assertions
> preventing access beyond the number of arguments passed to the
> function. I'll send the assert_enoug
On Mon, Jan 30, 2023 at 4:07 PM Tom Lane wrote:
> Gurjeet Singh writes:
> > [ generate_series_with_timezone.v6.patch ]
>
> The cfbot isn't terribly happy with this. It looks like UBSan
> is detecting some undefined behavior. Possibly an uninitialized
> variable?
It w
On Sat, Nov 12, 2022 at 10:44 AM Tom Lane wrote:
> However, what it shouldn't be is part of this patch. It's worth
> pushing it separately to have a record of that decision. I've
> now done that, so you'll need to rebase to remove that delta.
>
> I looked over the v5 patch very briefly, and
On Fri, Jan 20, 2023 at 9:32 AM Ted Yu wrote:
>
> Since `validIdentifier` doesn't modify the contents of `name` string, it
> seems that there is no need to create `tmp` string in `validNamedOperator`.
> You can pass the start and end offsets into the string (name) as second and
> third
On Sat, Jan 14, 2023 at 6:14 AM Gurjeet Singh wrote:
>
> I agree that an identifier _surrounded_ by the same token (e.g. #foo#)
> or the pairing token (e.g. {foo}) looks better aesthetically, so I am
> okay with any of the following variations of the scheme, as well:
>
> \#foo
On Thu, Jan 12, 2023 at 5:55 AM Matthias van de Meent
wrote:
> On Thu, 12 Jan 2023 at 11:59, Gurjeet Singh wrote:
> > ... defining an operator
> > gives you many additional features that the planner can use to
> > optimize your query differently, which it can't d
On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
wrote:
>
> On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
> >
> > Technically correct name of this feature would be Readable Names for
> > Operators, or Pronounceable Names for Operators. But I'd like to cal
Please see attached a slightly updated patch. There were some comment
changes sitting in uncommitted in Git worktree, that were missed.
Best regards,
Gurjeet
http://Gurje.et
named_operators_v1.patch
Description: Binary data
Technically correct name of this feature would be Readable Names for
Operators, or Pronounceable Names for Operators. But I'd like to call
it Named Operators.
With this patch in place, the users can name the operators as
:some_pronounceable_name: instead of having to choose from the special
On Sat, Nov 5, 2022 at 11:23 AM Andres Freund wrote:
> > As far as I know, Gurjeet has been annoyed only with non-user-settable
> > GUCs for one connection (correct me of course), there was nothing
> > fancy with isolation tests, yet. Not saying that this is useless for
> > isolation tests, this
In an internal conversation it was seen that for some tests that want
to enforce a behaviour, a behaviour that is controlled by a GUC, we
_need_ to perform a sleep for an arbitrary amount of time.
Alternatively, executing the rest of the test on a new connection also
helps to get the expected
I'm trying to build Postgres using the Nix language and the Nix package
manager on macOS (see [1]). After some work I was able to build, and even
run Postgres. But `make check` failed with the error
pg_regress: could not exec "sh": No such file or directory
The reason is that pg_regress uses
On Tue, Aug 16, 2022 at 3:16 AM Bharath Rupireddy
wrote:
>
> On Tue, Aug 16, 2022 at 1:55 PM Drouvot, Bertrand wrote:
> >
> > Hi,
> >
> > On 8/16/22 10:10 AM, Bharath Rupireddy wrote:
> > > On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand
> > >
(reposting the same review, with many grammatical fixes)
On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand wrote:
> Please find attached v2-0004-connection_hooks.patch
/*
* Stop here if it was bad or a cancel packet. ProcessStartupPacket
* already did any appropriate error
On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand wrote:
> Please find attached v2-0004-connection_hooks.patch
/*
* Stop here if it was bad or a cancel packet. ProcessStartupPacket
* already did any appropriate error reporting.
*/
if (status != STATUS_OK)
+{
On Tue, Apr 20, 2021 at 9:06 AM Andrew Dunstan wrote:
>
> On 4/20/21 11:02 AM, Tom Lane wrote:
> > Aleksander Alekseev writes:
> >> While trying to build PostgreSQL from source (master branch, 95c3a195) on a
> >> MacBook I discovered that `make check` fails:
> > This is the usual symptom of not
1 - 100 of 137 matches
Mail list logo
