On Apr 2, 2025, at 5:14, Noah Misch wrote:Yes, pg_upgrade should not do that. I was trying to explain the differencebetween NULL and 'NULL'. I didn't mean pg_upgrade should emit "IS NULL".(Apologies for the probably-weirdly-formatted message)This issue has been already mentioned around here, wit
On Tue, Apr 01, 2025 at 04:28:34PM -0300, Ranier Vilela wrote:
> Em ter., 1 de abr. de 2025 às 15:39, Noah Misch
> escreveu:
>
> > On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > > Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier <
> > mich...@paquier.xyz>
> > > escreveu:
Em ter., 1 de abr. de 2025 às 15:39, Noah Misch
escreveu:
> On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier <
> mich...@paquier.xyz>
> > escreveu:
> >
> > > On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> >
Em ter., 1 de abr. de 2025 às 15:39, Noah Misch
escreveu:
> On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier <
> mich...@paquier.xyz>
> > escreveu:
> >
> > > On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> >
On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier
> escreveu:
>
> > On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> > > @@ -455,7 +455,9 @@ set_locale_and_encoding(void)
> > > locale->db_locale,
> > > strlen
Em qui., 27 de fev. de 2025 às 22:19, Michael Paquier
escreveu:
> On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > Yeah, I also think it would look good like this.
>
> It's the least confusing option, indeed. I've reduced a bit the diffs
> and done that down to v16 for the pg_u
On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> Yeah, I also think it would look good like this.
It's the least confusing option, indeed. I've reduced a bit the diffs
and done that down to v16 for the pg_upgrade part where this exists.
Double-checking the tree, it does not seem
Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier
escreveu:
> On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> > @@ -455,7 +455,9 @@ set_locale_and_encoding(void)
> > locale->db_locale,
> > strlen(locale->db_locale));
> > else
> > - datlocale_literal = pg_strdup("NULL");
On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> @@ -455,7 +455,9 @@ set_locale_and_encoding(void)
> locale->db_locale,
> strlen(locale->db_locale));
> else
> - datlocale_literal = pg_strdup("NULL");
> + datlocale_literal = PQescapeLiteral(conn_new_template1,
> + "NULL",
> + s
Hi,
On 2025-02-12 19:08:31 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > I have looked at bit at the uses of PQescapeLiteral() and
> > PQescapeIdentifier() in the tree. On top of the one in pg_amcheck you
> > are just pointing to, there is an inconsistency in pg_upgrade.c for
> > set_loca
Em ter., 25 de fev. de 2025 às 03:02, Michael Paquier
escreveu:
> On Thu, Feb 13, 2025 at 01:50:29PM +0900, Michael Paquier wrote:
> > On Wed, Feb 12, 2025 at 07:08:31PM -0500, Tom Lane wrote:
> >> I spent a little time earlier today seeing what I could do with the
> >> use-dmalloc patch I posted
On Thu, Feb 13, 2025 at 01:50:29PM +0900, Michael Paquier wrote:
> On Wed, Feb 12, 2025 at 07:08:31PM -0500, Tom Lane wrote:
>> I spent a little time earlier today seeing what I could do with the
>> use-dmalloc patch I posted earlier. It turns out you can get through
>> initdb after s/free/PQfreem
Em qua., 12 de fev. de 2025 às 18:17, Tom Lane escreveu:
> Ranier Vilela writes:
> > Coverity has some reports about pg_createsubcriber.
>
> > CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
> > 10. leaked_storage: Variable dbname going out of scope leaks the storage
> it
> > points to.
>
On Wed, Feb 12, 2025 at 07:08:31PM -0500, Tom Lane wrote:
> I spent a little time earlier today seeing what I could do with the
> use-dmalloc patch I posted earlier. It turns out you can get through
> initdb after s/free/PQfreemem/ in just two places, and then the
> backend works fine. But psql i
Michael Paquier writes:
> I have looked at bit at the uses of PQescapeLiteral() and
> PQescapeIdentifier() in the tree. On top of the one in pg_amcheck you
> are just pointing to, there is an inconsistency in pg_upgrade.c for
> set_locale_and_encoding() where datlocale_literal may be allocated
>
On Wed, Feb 12, 2025 at 01:35:20PM -0500, Tom Lane wrote:
> For amusement's sake, totally dirty hack-and-slash patch attached.
> (I tested this on macOS, with dmalloc from MacPorts; adjust SHLIB_LINK
> to suit on other platforms.)
Ugh. Fun one.
--
Michael
signature.asc
Description: PGP signatur
On Wed, Feb 12, 2025 at 12:00:03PM -0500, Andres Freund wrote:
> Particularly for something like libpq it's not quitetrivial to add
> attributes like this, of course. We can't even depend on pg_config.h.
>
> One way would be to define them in libpq-fe.h, guarded by an #ifdef, that's
> "armed" by a
Ranier Vilela writes:
> Coverity has some reports about pg_createsubcriber.
> CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
> 10. leaked_storage: Variable dbname going out of scope leaks the storage it
> points to.
FTR, the security team's Coverity instance also complained about that.
I
Tom Lane writes:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Tom Lane writes:
>>> libpq-fe.h has to be compilable by application code that has never
>>> heard of pg_config.h let alone c.h, so we'd have to tread carefully
>>> about not breaking that property. But it seems like this w
I experimented with the other approach: hack libpq.so to depend on
dmalloc, leaving the rest of the system alone, so that libpq's
allocations could not be freed elsewhere nor vice versa.
It could not even get through initdb, crashing here:
replace_guc_value(char **lines, const char *guc_name, con
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> libpq-fe.h has to be compilable by application code that has never
>> heard of pg_config.h let alone c.h, so we'd have to tread carefully
>> about not breaking that property. But it seems like this would be
>> worth looking
Tom Lane writes:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Andres Freund writes:
>>> Particularly for something like libpq it's not quitetrivial to add
>>> attributes like this, of course. We can't even depend on pg_config.h.
>>> One way would be to define them in libpq-fe.h, guard
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Andres Freund writes:
>> Particularly for something like libpq it's not quitetrivial to add
>> attributes like this, of course. We can't even depend on pg_config.h.
>> One way would be to define them in libpq-fe.h, guarded by an #ifdef, that's
>
Andres Freund writes:
> Hi,
>
> On 2025-02-12 11:02:04 -0500, Tom Lane wrote:
>> I wish we had some way to detect misuses automatically ...
>>
>> This seems like the sort of bug that Coverity could detect if only it
>> knew to look, but I have no idea if it could be configured that way.
>> Maybe
Hi,
On 2025-02-12 11:02:04 -0500, Tom Lane wrote:
> I wish we had some way to detect misuses automatically ...
>
> This seems like the sort of bug that Coverity could detect if only it
> knew to look, but I have no idea if it could be configured that way.
> Maybe some weird lashup with a debugging
Hi.
Em qua., 12 de fev. de 2025 às 13:02, Tom Lane escreveu:
> Andres Freund writes:
> > On 2025-02-11 13:32:32 -0300, Euler Taveira wrote:
> >> There is no bug. They are the same behind the scenes.
>
> > That *is* a bug. On windows the allocator that a shared library (i.e.
> libpq)
> > uses, m
Andres Freund writes:
> On 2025-02-11 13:32:32 -0300, Euler Taveira wrote:
>> There is no bug. They are the same behind the scenes.
> That *is* a bug. On windows the allocator that a shared library (i.e. libpq)
> uses, may *not* be the same as the one that an executable
> (i.e. pg_createsubscribe
Hi,
On 2025-02-11 13:32:32 -0300, Euler Taveira wrote:
> On Mon, Feb 10, 2025, at 1:31 PM, Ranier Vilela wrote:
> > Coverity has some reports about pg_createsubcriber.
> >
> > CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
> > 10. leaked_storage: Variable dbname going out of scope leaks th
Em qua., 12 de fev. de 2025 às 00:54, Michael Paquier
escreveu:
> On Tue, Feb 11, 2025 at 01:32:32PM -0300, Euler Taveira wrote:
> > There is no bug. They are the same behind the scenes. I'm fine changing
> it. It
> > is a new code and it wouldn't cause a lot of pain to backpatch patches
> in the
On Tue, Feb 11, 2025 at 01:32:32PM -0300, Euler Taveira wrote:
> There is no bug. They are the same behind the scenes. I'm fine changing it. It
> is a new code and it wouldn't cause a lot of pain to backpatch patches in the
> future.
On consistency grounds, and as this is documented in fe-exec.c a
On Mon, Feb 10, 2025, at 1:31 PM, Ranier Vilela wrote:
> Coverity has some reports about pg_createsubcriber.
>
> CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
> 10. leaked_storage: Variable dbname going out of scope leaks the storage it
> points to.
> Additionally there are several calls
Hi.
Per Coverity.
Coverity has some reports about pg_createsubcriber.
CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
10. leaked_storage: Variable dbname going out of scope leaks the storage it
points to.
Additionally there are several calls that are out of the ordinary,
according to the
32 matches
Mail list logo
