dropping the said index, you may mark the index invisible to
the planner by using the ALTER INDEX ... INVISIIBLE command. If it turns
out that doing so causes a performance degradation, the index can be
quickly made visible to the planner for query optimization by using the
ALTER INDEX ... VISIBLE command.
Thoughts?
Best regards,
Gurjeet
http://Gurje.et
f
advice? Or maybe it needs to be reworded to fit the command reference style?
Best regards,
Gurjeet
http://Gurje.et
quick glance.
+1 on both counts.
Best regards,
Gurjeet
http://Gurje.et
pgstat_*.c files.
> While we're at it, the comment feels a bit awkward to me anyway. Maybe
> rephrase it to "If nowait is true and the lock could not be immediately
> acquired, returns false without flushing the entry. Otherwise returns true."
This rephrasing does sounds better.
Best regards,
Gurjeet
http://Gurje.et
an improvement in the two sentences quoted
above, but perhaps others can think of something that helps the reader.
--
Best regards,
Gurjeet
http://Gurje.et
diff --git a/src/backend/access/heap/README.tuplock
b/src/backend/access/heap/README.tuplock
index 843c2e58f92..0763fbaa9e7 100644
---
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
if we
> can agree on behavior and nomenclature, I'll do my darndest to get this
> responsibly committed in time.
Thank you for all your help and work on this patch! Unfortunately I haven't been
able to work on it as much as I would've liked to.
Best regards,
Gurjeet
http://Gurje.et
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
Array[2].lock)
#define XidGenLock (&MainLWLockArray[3].lock)
#define ProcArrayLock (&MainLWLockArray[4].lock)
#define SInvalReadLock (&MainLWLockArray[5].lock)
...
The lockname column needs to be at least 30 chars wide to accommodate the
longest of the lock names 'DynamicSharedMemoryControlLock'.
Best regards,
Gurjeet
http://Gurje.et
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.
> > >
t truncate operation is being skipped, perhaps only if the truncation
would've freed up space over a certain threshold.
Perhaps there's value in letting this parameter be specified at database level,
but I'm not able to think of a reason why someone would want to disable this
b
there's interest in list
API for int64 type, I can complete the patch and make the new API match the
current API for int type.
[1]: pg_block_queries
https://github.com/gurjeet/pg_block_queries/
Best regards,
Gurjeet
http://Gurje.et
int64_list_api.patch
Description: Binary data
xisting APIs (makeStringInfo() and initStringInfo()) are now macros to call
makeStringInfoExtended() and initStringInfoExtended(), respectively, with
the default buffer size of 1024.
Best regards,
Gurjeet
http://Gurje.et
rentheses, like so:
#define makeStringInfo()
Best regards,
Gurjeet
http://Gurje.et
aborted state - the effect of the commit will look like a rollback,
+ including the command tag output.
So this seems like a better statement: If the transaction is in an
aborted state, say, because of an error, then the effect of the
COMMIT will be identical to that of ROLLBACK,
including
ached.
I'm unable to confirm the veracity of the claim that the pgevent.dll
file on Windows is now placed in a different directory, and that this
is a result of meson builds. But the patch looks good to me; it
applies cleanly to REL_17_STABLE and main branches.
Best regards,
Gurjeet
http://Gurje.et
, it would be desirable to also
have a remainder operator %.
For example,
('365 days'::interval / '5 days'::interval) => 73
('365 days'::interval % '5 days'::interval) => 0
('365 days'::interval / '3 days'::interval) => 121
(&
ized
implementation
* for hash tables that aren't performance or space sensitive.
But your argument of a nicer API might make a case for the patch. I
Best regards,
Gurjeet
http://Gurje.et
H_ELEMENT_TYPE) * size);
> >
> > + SH_UPDATE_PARAMETERS(tb, size);
> > return tb;
> > }
>
> Maybe add a comment explaining why it's important to update parameters after
> allocating?
Perhaps something like this:
+ /*
+ * Update parameters _after_ allocation succeeds; prevent
+ * bogus/corrupted state.
+ */
+ SH_UPDATE_PARAMETERS(tb, size);
Best regards,
Gurjeet
http://Gurje.et
One mention of malloc is left intact, because that mention is unrelated to how
the memory is allocated, or how to free it.
In passing, slightly improve the language of PQencryptPasswordConn()
documentation.
Best regards,
Gurjeet
http://Gurje.et
v1-0001-Replace-references-to-malloc-in-
ing one (very
cheap, in common case) extra call of this macro.
Best regards,
Gurjeet
http://Gurje.et
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.
&
ould apply
to all passwords, irrespective of which command/feature was used to
create a password.
Best regards,
Gurjeet
http://Gurje.et
g like a tombstone, and the case where the user may want to
extend the validity of a password, instead of having to create a new
one and change application configuration(s) to specify the new
password.
Best regards,
Gurjeet
http://Gurje.et
above proposal
addresses the use case you describe.
> if we allow multiple deprecated passwords, we'd still have to come up
> with some way to address them (names, numbers, validity period,
> something). But by isolating the problem to deprecated passwords only,
> it feels like the system is still being restored to a clean state with
> at most one single current password. The awkwardness is contained to
> old passwords which will hopefully go away soon anyway and not
> represent permanent clutter.
+1
Best regards,
Gurjeet
http://Gurje.et
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
> >
:-)
> Jon Erdman (aka StuckMojo on IRC)
TIL.
I wish there was a directory of IRC identities that pointed to real
identities (at least for folks who don't mind this mapping available
in the open), so that when we converse in IRC, we have a face to go
with the IRC handles. As a human I feel that necessity.
Best regards,
Gurjeet
http://Gurje.et
he better mechanism.
I realize that allowing for a maximum of 2 passwords goes against the
zero-one-infinity rule [1], but I think in the case of password
rollovers it's perfectly acceptable to limit the number of active
passwords to just 2. If there are use cases, either related to password
rollovers, or in its vicinity, that can be better addressed by
allowing an arbitrarily many passwords, I would love to learn about
them and change this design to accommodate for those use cases, or
perhaps revert to pursuing the multiple-passwords feature.
[1]: https://en.wikipedia.org/wiki/Zero_one_infinity_rule
Best regards,
Gurjeet
http://Gurje.et
arked the CF item [1] as 'Committed', and specified Bruce as the
committer.
[1]: https://commitfest.postgresql.org/45/4333/
Best regards,
Gurjeet
http://Gurje.et
"open a
> > port," but otherwise it LGTM.
>
> Agreed, I never liked the "port" mention. I couldn't figure how to get
> "open" out of the warning sentence though. Updated patch attached.
LGTM.
Best regards,
Gurjeet
http://Gurje.et
ql throws an error if --no-connect and --list are
specified together.
$ psql --no-connect --list
psql: error: --no-connect cannot be specified with --list
Best regards,
Gurjeet
http://Gurje.et
psql_no_connect.diff
Description: Binary data
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
ay insist on it, when reviewing.
Here are a couple of helpful links on how to prepare and submit
patches to the community. You may not need to strictly adhere to
these, but try to pick up a few recommendations that would make the
reviewer's job a bit easier.
[1]: https://wiki.postgresql.org/wiki/Creating_Clean_Patches
[2]: https://wiki.postgresql.org/wiki/Submitting_a_Patch
Best regards,
Gurjeet
http://Gurje.et
_ARGS)
+{
...
+relaction = mtstate->mt_merge_action;
+if (relaction)
+{
..
+}
+
+PG_RETURN_NULL();
+}
Under what circumstances would the relaction be null? Is it okay to
return NULL from this function if relaction is null, or is it better
to throw an error? These questions apply to the
pg_merge_when_clause_number() function as well.
[1]: Row pattern recognition
https://www.postgresql.org/message-id/flat/20230625.210509.1276733411677577841.t-ishii%40sranhm.sra.co.jp
Best regards,
Gurjeet
http://Gurje.et
ports such
failures to the community.
Best regards,
Gurjeet
http://Gurje.et
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
CommitTransaction() in xact.c, and specifically at the
ResourceOwnerRelease() calls in there.
Best regards,
Gurjeet
http://Gurje.et
into something the executor
> > could handle, which might just end up being the existing functions
> > anyway.
>
> The benefits are:
>
> 1. It is naturally constrained to the right context.
+1
> I'm not sure how much extra complication it would cause, though.
If that attempt with UPDATE RETURNING a decade ago is any indication,
it's probably a tough one.
Best regards,
Gurjeet
http://Gurje.et
hat the old thread could not accomplish a
decade ago.
> Presumably
> something in the planner would turn that into something the executor
> could handle, which might just end up being the existing functions
> anyway.
If the current patch's functions can serve the needs of the SQL syntax
variant, that'd be a neat win!
Best regards,
Gurjeet
http://Gurje.et
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
an index is hypothetical it can rely on
the index adviser's notion of which index is hypothetical. The hook
implementer has the opportunity to not only mark the
indexOptInfo->hypothetical = true, but also calculate the tree height,
if they can.
Please see attached the patch that does this.
RCE is not a guarantee, as the DROP DATABASE docs clarify
the conditions under which it may fail.
Best regards,
Gurjeet
http://Gurje.et
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
x27;re referring to here.
Best regards,
Gurjeet
http://Gurje.et
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 t
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 =>
ond assignment. I
> ran meson test and all tests have pass.
-handle->lljit = compile_orc;
LGTM.
Best regards,
Gurjeet
http://Gurje.et
T command
behaves like that (resultset followed by CommandStatus), then I'd say
the INSERT RETURNING is behaving as expected.
Best regards,
Gurjeet
http://Gurje.et
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 "
sineog9w%40mail.gmail.com
[6] Tristan showing preference for the second variant
https://www.postgresql.org/message-id/CTBN5E2K2YSJ.3QYXGZ09JZXIW%40gonk
+CC Tristan Partin and Greg Smith, since they were involved in the
initial thread.
Best regards,
Gurjeet
http://Gurje.et
variant-1-brief-po
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
t and can't listen on
> anything?
Yes. For every host listed in listen_addresses, if Postgres fails to
open the port on that address, we get a WARNING message in the server
log. After the end of processing of a non-empty listen_addresses, if
there are zero open TCP/IP connections, the server exits (with a FATAL
message, IIRC).
Best regards,
Gurjeet
http://Gurje.et
e patch does not include any TAP
tests. Reliably reproducing the original error message involves
restarting the database, and since that can't be done via SQL
commands, no sql tests are included, either.
The patch also includes minor wordsmithing, and benign whitespace
changes in neighboring c
EINDEX. The -hackers list feels like a place to discuss such
changes.
Best regards,
Gurjeet
http://Gurje.et
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
one still using it, even if it was left marked
deprecated indefinitely. Discovering benign neglect for the tool you
depend on, from secondary sources (like this list, forums, etc.), does
not evoke a lot of confidence.
Best regards,
Gurjeet
http://Gurje.et
362gp4KHAah-yUe08CQY4a4SsOQ%40mail.gmail.com
Best regards,
Gurjeet
http://Gurje.et
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."
> >
>
idea; a monitoring system trained at this view can bubble
up problems to users that may otherwise go unnoticed. Piggybacking on,
or using pg_stat_statments implementation as a model seems fine. I
believe making this available as a contrib module hits the right
balance; not all installations may want this, hence in-core, always
collecting data, seems undesirable; if it's an external project, it
won't be discoverable, I see that as a very high bar for someone to
trust it and begin to use it.
Best regards,
Gurjeet
http://Gurje.et
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.
&
) zero;
> - if it is an aggregate, every member is initialized (recursively) according
> to these rules;
> - if it is a union, the first named member is initialized (recursively)
> according to these rules.
Best regards,
Gurjeet
http://Gurje.et
for its advantages that Andres mentions in the
email, but also for the reason that cfbot had chosen Cirrus. 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.
[1]:
https://www.postgresql.org/message-id/20211001222752.wrz7erzh4cajvgp6%40alap3.anarazel.de
Best regards,
Gurjeet
http://Gurje.et
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
UES ($1, $2, $3)) AS v(sid, balance, delta)
+ON tid = v.sid
+WHEN MATCHED AND tid > 2 THEN
Again, for consistency, the comparison operator should be >=. There
are a few more occurrences of this comparison in the rest of the file,
that need the same treatment.
Best regards,
Gurjeet
http://Gurje.et
e src/bin/scripts/reindexdb.c
$ file v1-0001-harmonize-password-reuse-in-vacuumdb-clusterdb-an.patch
v1-0001-harmonize-patch: unified diff output text, ASCII text,
with CRLF line terminators
Best regards,
Gurjeet
http://Gurje.et
lead to the
same outcome.
Otherwise the patch looks good.
> v11-0001-CREATE-COLLATION-default-provider.patch
I believe v11 is a typo, and you really meant v1.
Best regards,
Gurjeet
http://Gurje.et
nt
with one of the existing order of the options.
So attached is updated patch that makes the order consistent across
all 3 occurrences.
Best regards,
Gurjeet
http://Gurje.et
v2-0001-test_extensions-make-meson.build-consistent-with-.patch
Description: Binary data
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
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
;s just less
> clear...
Understandably, there doesn't seem to be a lot of enthusiasm for this.
If you could show others a sample/demo session of what the UI and UX
would look like, maybe others can chime in with either their opinion
of the behaviour, or perhaps a better/different way of achieving that.
Best regards,
Gurjeet
http://Gurje.et
is a shared-memory data structure,
and some other process changed the 'rel' member in shared-memory. And
I don't think 'eb' is in shared memory in this case.
To me, it looks like these checks are a result of code being
copy-pasted from somewhere else, where this check might have been
necessary. The checks are sure not necessary at these spots.
Please see attached v2 of the patch; it includes both occurrences of
the spurious checks identified in this thread.
Best regards,
Gurjeet
http://Gurje.et
v2-0001-Remove-always-true-checks.patch
Description: Binary data
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
at way we can
mark the old behaviour "deprecated", with a workaround for those who
may desperately need it, and in another release or so, finally pull
the plug on old behaviour.
My 2bits.
Best regards,
Gurjeet
http://Gurje.et
hint to where to find more details
about what the letters in --init-steps mean, would save them a lot of
time.
[1]: https://www.postgresql.org/docs/15/pgbench.html
Best regards,
Gurjeet
http://Gurje.et
-a sleep 1
> perf report --stdio
There is no mention of perf or similar utilities in pgbench-tools
docs. I'm guessing Linux is the primary platform pgbench-tools gets
used on most. If so, I think it'd be useful to mention these tools and
snippets in there to make others lives easier
st back when
pgcrypto was added, but since it does now, it may be worth it make
others depend on implementation in src/common/ code.
Best regards,
Gurjeet
http://Gurje.et
ray at the point of
definition, like your patch does. So, +1 to the patch.
Best regards,
Gurjeet
http://Gurje.et
On Thu, Jun 8, 2023 at 7:11 AM Daniel Westermann (DWE)
wrote:
>
> ... shouldn't there be a "to" before "detect"?
>
> These two additions make it possible detect a concurrent page split
Agreed. Attached is a small patch that fixes this.
Thanks for th
ar utilities) may not
have a way to extract or sanitize the exact data you want.
With this feature built into Postgres, you'd not need any external
utilities or extensions. The benefits of features built into Postgres
are that the users can come up with ways of leveraging such a feature
in future in a way that we can't envision today.
Best regards,
Gurjeet
http://Gurje.et
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
atch does not change any language related to that.
Best regards,
Gurjeet
http://Gurje.et
v1-0001-Document-that-the-server-starts-only-if-at-least-.patch
Description: Binary data
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:
> >>
ed.
Please submit a patch.
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 wordy, and sometimes confusing, especially for the audience
that it's written for: newcomers to Postgres ecosystem.
Best regards,
Gurjeet https://Gurje.et
http://aws.amazon.com
est regards,
Gurjeet http://Gurje.et
http://aws.amazon.com
];
I'm not yet sure if the COMMIT AND CHAIN command should carry this
characteristic to the next transaction.
Thoughts?
Best regards,
Gurjeet https://Gurje.et
http://aws.amazon.com
7;re speaking of the per-hash-table limit or some
> (nonexistent) overall limit. How about
>
> - memory available for hash tables is computed by multiplying
> + memory limit for a hash table is computed by multiplying
+1
Best regards,
Gurjeet https://Gurje.et
Postgres Contributors Team, http://aws.amazon.com
e libpq feature. This patch is merely a
minor improvement to the code that I think deserves a consideration.
It's not a litigation, by any means.
Best regards,
Gurjeet https://Gurje.et
Postgres Contributors Team, http://aws.amazon.com
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
> &
ngs so that a
reader doesn't have to spend extra deciphering why 'connect2' tests
appear before 'connect1' tests.
Best regards,
Gurjeet https://Gurje.et
Postgres Contributors Team, http://aws.amazon.com
v0-0001-Reorder-connection-markers-in-TAP-tests.patch
Description: Binary data
regards,
Gurjeet https://Gurje.et
Postgres Contributors Team, http://aws.amazon.com
v0-0001-Reduce-code-duplication-in-fe-connect.c.patch
Description: Binary data
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
own strings
v1-0001-Replace-placeholders-with-known-strings.patch
[3]: Make require_auth error message similar to surrounding messages
v1-0001-Make-require_auth-error-message-similar-to-surrou.patch
Best regards,
Gurjeet http://Gurje.et
Postgres Contributors Team, http://aws.amazon.com
v1-0
1 - 100 of 157 matches
Mail list logo
