On Thu, Jul 21, 2022 at 4:35 PM Gurjeet Singh wrote:
> I like the idea of performing library initialization in
> InitPostgres(), as it performs the first transaction of the
> connection, and because of the libraries' ability to gin up new GUC
> variables that might need special handli
On Thu, Jul 21, 2022 at 3:29 PM Nathan Bossart wrote:
>
> On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> > Right. So there are basically two things we could do about this:
> >
> > 1. set_config_option could decline to call pg_parameter_aclcheck
> > if not IsTransactionState(),
On Thu, Jul 21, 2022 at 2:44 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > While poking at plperl's GUC in an internal discussion, I was able to
> > induce a crash (or an assertion failure in assert-enabled builds) as
> > an unprivileged user.
> > My inv
://Gurje.et
Forwarded Conversation
Subject: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
From: Gurjeet Singh
Date: Mon, Jul 4, 2022 at 10:24 AM
To: Postgres Security
Cc: Bossart, Nathan
While poking at plperl's GUC in an internal discussion
On Tue, Jun 21, 2022 at 7:56 AM Przemysław Sztoch wrote:
> There is another patch.
> It works, but one thing is wrongly done because I lack knowledge.
Thank you for continuing to work on it despite this being your first
time contributing, and despite the difficulties. I'll try to help as
much as
I am planning on picking it up next week; right now picking up steam,
and reviewing a different, smaller patch.
At his behest, I had a conversation with Joshua (OP), and have his
support to pick up and continue working on this patch. I have a some
ideas of my own, on what this patch should do,
(fixed your top-posting)
On Fri, Jun 24, 2022 at 4:59 PM Hannu Krosing wrote:
> On Sat, Jun 25, 2022 at 1:46 AM Gurjeet Singh wrote:
> >
> > On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> > > On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> >
> >
On Fri, Jun 24, 2022 at 4:13 PM Andres Freund wrote:
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > 3) should this be back-patched (we can provide batches for all
> > supported PgSQL versions)
>
> Err, what?
Translation: Backpatching these changes to any stable versions will
not be
On Thu, May 26, 2022 at 4:13 PM Tom Lane wrote:
> Gurjeet Singh writes:
> > On Thu, May 26, 2022 at 12:16 PM Tom Lane wrote:
> >> so maybe those comments in libpq-be.h
> >> should be moved to their respective functions? In any case, I'm not
> >> excited
On Thu, May 26, 2022 at 2:40 PM Tom Lane wrote:
>
> Robert Haas writes:
> > I think you're overreacting to a behavior that isn't really very surprising.
>
> > If we don't initialize SSL the first time, we don't have a working SSL
> > stack. If we didn't choose to die at that point, we'd be
On Thu, May 26, 2022 at 1:00 PM Robert Haas wrote:
>
> On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh wrote:
> > There's an symmetry, almost a diametric opposition, between how SSL
I meant "an asymmetry".
> > initialization error is treated when it occurs during ser
On Thu, May 26, 2022 at 12:16 PM Tom Lane wrote:
> Gurjeet Singh writes:
> > On Mon, May 23, 2022 at 8:51 PM Tom Lane wrote:
> >> The comments for secure_initialize() and be_tls_init() both explain
> >> this already.
>
> > The comments above secure_initia
On Wed, May 25, 2022 at 10:05 PM Gurjeet Singh wrote:
> I have added a comment to be_tls_init(), which I hope explains this
> difference in treatment of errors. I have also added comments to
> be_tls_init(), explaining why we don't destroy/free the global
> SSL_context vari
On Mon, May 23, 2022 at 8:51 PM Tom Lane wrote:
>
> Daniel Gustafsson writes:
> >> On 22 May 2022, at 08:41, Gurjeet Singh wrote:
> >> The initialization in PostmasterMain() blindly turns on LoadedSSL,
> >> irrespective of the outcome of secure_initial
On Sun, May 22, 2022 at 12:17 AM Daniel Gustafsson wrote:
> > On 22 May 2022, at 08:41, Gurjeet Singh wrote:
>
> > The initialization in PostmasterMain() blindly turns on LoadedSSL,
> > irrespective of the outcome of secure_initialize().
>
> This call is invoked with i
The initialization in PostmasterMain() blindly turns on LoadedSSL,
irrespective of the outcome of secure_initialize(). I don't think
that's how it should behave, primarily because of the pattern followed
by the other places that call secure_initialize().
This patch makes PostmasterMain() behave
://www.postgresql.org/message-id/flat/673096.1630006990%40sss.pgh.pa.us#cd378cba4b990fda070c6fa4b51a069c
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
leakproof_comments.patch
Description: Binary data
EPOINT one;
ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
RELEASE SAVEPOINT one;
ERROR: RELEASE SAVEPOINT can only be used in transaction blocks
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
On Tue, Aug 31, 2021 at 8:04 AM Alvaro Herrera wrote:
>
> On 2021-Aug-30, Gurjeet Singh wrote:
>
> > I'm very happy to announce that I now work for Supabase [1]. They
> > have hired me so that I can participate in, and contribute to the
> > Postgres community.
&g
On Mon, Aug 30, 2021 at 10:53 PM Gurjeet Singh wrote:
> PS: Hacker News announcement is at https://news.ycombinator.com/item?id=
https://news.ycombinator.com/item?id=28364406
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
is at https://news.ycombinator.com/item?id=
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
tdb
> >> help
> >> output match the other exiting options in there. Barring objections, I
> >> think
> >> this is ready.
> >
> > LGTM. Thanks!
>
> Pushed to master, thanks!
Thank you Daniel and Nathan! Much appreciated.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
ue intent of the option, because generally a "write" operation
is still limited to dirtying the OS buffers, and does not guarantee
sync-to-disk.
It'd be better if the help message said, either "flush all database
files to disk and exit",or "sync all database files to disk
%40mail.gmail.com
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
v1-0001-Warn-if-sync-only-is-used-with-other-options.patch
Description: Binary data
not modify any data
To match the wording of --sync-only option:
write contents of data directory to disk; helpful after --no-sync option
Clearly specify the system operation used for the option
perform fsync on data directory; helpful after --no-sync option
Best regards,
--
Gurjeet Singh http
The proposed patch is attached.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
On Wed, Jun 30, 2021 at 5:56 PM Gurjeet Singh wrote:
>
> (Re-sending this email, because the Commitfest app mistakenly [3]
> considered previous email [4] to be part of the old thread, whereas it
a continuation of a previous thread, _and_
the 'Latest attachment' entry points to a different email, even though
my email [4] contained a patch.
[4]:
https://www.postgresql.org/message-id/CABwTF4VS+HVm11XRE_Yv0vGmG=5kpYdx759RyJEp9F+fiLTU=q...@mail.gmail.com
Best regards,
--
Gurjeet Singh http
in the protocol.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
notify_xid.patch
Description: Binary data
a 100% chance of the idea being shot down :-)
> but maybe the ability to receive jsonbc on the wire would be of interest
> to drivers generally.
I'm not sure of that, but then I don't have visibility into the needs
of consumers of our drivers.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
On Wed, May 13, 2020 at 1:14 PM Gurjeet Singh wrote:
>
> Arguably, delivering JSON (with its repeating attribute names in every
> element of the array, dquotes and commas) is more network intensive
> than converting the resultset to JSON on network side.
s/network side/client side/
On Wed, May 13, 2020 at 12:50 PM Robert Haas wrote:
>
> On Mon, May 11, 2020 at 4:42 PM Gurjeet Singh wrote:
> > That's a good point! It might still be desirable, perhaps for performance
> > trade-off of JSON conversion on the client-side instead of on the
> > ser
On Mon, May 11, 2020 at 1:24 PM Robert Haas wrote:
> On Fri, May 8, 2020 at 7:32 PM Gurjeet Singh wrote:
> > There's no standard format that comes to mind, but perhaps an output
> format similar to that of (array of row_to_json()) would be desirable. For
> example, `select relnam
On Fri, May 8, 2020 at 12:10 PM Pavel Stehule
wrote:
>
>
> pá 8. 5. 2020 v 21:08 odesílatel Gurjeet Singh napsal:
>
>>
>> On Fri, May 8, 2020 at 12:01 PM Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> pá 8. 5. 2020 v 20:18 odesílatel
On Fri, May 8, 2020 at 12:01 PM Pavel Stehule
wrote:
> Hi
>
> pá 8. 5. 2020 v 20:18 odesílatel Gurjeet Singh napsal:
>
>> psql currently supports HTML, CSV, etc output formats. I was
>> wondering if supporting JSON format was requested or discussed in pa
psql currently supports HTML, CSV, etc output formats. I was wondering
if supporting JSON format was requested or discussed in past. If there's
desire for this feature, perhaps we can add it to the TODO list on wiki so
someone can pick it up and work on it in future.
Best regards,
--
Gurjeet
:25:37PM -0700, Gurjeet Singh wrote:
> > Please see attached the patch that corrects the file-level SQL comment
> that
> > indicates which submodule of pgcrypto is being tested.
>
> Thanks, committed. There was a second one in pgp-decrypt.sql.
> --
> Michael
>
--
Gurjeet Singh http://gurjeet.singh.im/
Please see attached the patch that corrects the file-level SQL comment that
indicates which submodule of pgcrypto is being tested.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
pgcrypto-test-comments.patch
Description: Binary data
101 - 137 of 137 matches
Mail list logo
