I don't know how to fix this, but thought it's worth reporting.
Best regards,
--
Sergey Shinderukhttps://postgrespro.com/diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index 6ce979f2d8b..19ee8b09685 100644
--- a/src/back
On 20.09.2023 11:42, Daniel Gustafsson wrote:
Attached is a v2 on top of HEAD with commit message etc, which I propose to
backpatch to v15 where it was introduced.
There is a typo: upon en error. Otherwise, looks good to me. Thank you.
--
Sergey Shinderukhttps
ntinuing.
And in the server log we see:
DEBUG: SSL connection from DN:"" CN:"ssltestuser"
While in the normal case we get:
DEBUG: SSL connection from DN:"CN=ssltestuser" CN:"ssltestuser"\
Probably we shouldn't ignore the error from X509_NAME
e file and recomputed the checksum. Like this:
https://security.stackexchange.com/a/58845
I'll try to add a client certificate lacking a CN to the SSL test suite.
--
Sergey Shinderukhttps://postgrespro.com/
On 24.08.2023 11:38, Daniel Gustafsson wrote:
On 24 Aug 2023, at 10:11, Sergey Shinderuk wrote:
I triggered a crash by generating a certificate without a CN and forcing malloc
to return NULL when called from X509_NAME_print_ex or BIO_get_mem_ptr with gdb.
Can you extend the patch with
On 23.08.2023 16:23, Daniel Gustafsson wrote:
On 1 Aug 2023, at 16:44, Sergey Shinderuk wrote:
A static analyzer reported a possible pfree(NULL) in be_tls_open_server().
This has the smell of a theoretical problem, I can't really imagine a
certificate where which would produce this.
2253
passed to X509_NAME_print_ex() ensures that null bytes are escaped.
Best regards,
--
Sergey Shinderukhttps://postgrespro.com/diff --git a/src/backend/libpq/be-secure-openssl.c
b/src/backend/libpq/be-secure-openssl.c
index 658b09988d6..31b6a6eacdf 100644
--- a/src/backend/
served after longjmp().
Good idea, but then why not the same for input_message? It's fully
reinitialized each time through the loop, too.
Yeah, that's better.
In short, something like the attached, except I'm not totally sold
on changing the volatility of the timeout flags
lieve, making them volatile doesn't affect performance in any way.
I also moved firstchar's declaration inside the loop where it's used, to
make it clear that this variable needn't be volatile and is not
preserved after longjmp().
Best regards,
--
Sergey Shinderuk
ful way to implement it.
Maybe something like the attached would do?
--
Sergey Shinderukhttps://postgrespro.com/
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 39bfb48dc22..94866743f48 100644
--- a/src/backend/executor/execMain.c
+++ b/s
hink it is counterproductive to hide syntax differences when
there is a significant difference in performance (and will be).
Fair enough. Thank you, Pavel.
--
Sergey Shinderukhttps://postgrespro.com/
also true for the too_many_rows exception, but
arguably it's a programmer error, while no_data_found switches to a
different convention for handling (or not handling) an empty result with
SELECT INTO.
Otherwise the patch is straightforward.
What do you think?
--
Sergey Shinderuk
On 01.12.2022 11:18, Richard Guo wrote:
On Mon, Nov 28, 2022 at 5:59 PM Sergey Shinderuk
mailto:s.shinde...@postgrespro.ru>> wrote:
Not quite sure that we don't need to do anything for the
WINDOWAGG_PASSTHROUGH_STRICT case. Although, we won't return any more
On 28.11.2022 03:23, David Rowley wrote:
On Sat, 26 Nov 2022 at 05:19, Tom Lane wrote:
Sergey Shinderuk writes:
What about user-defined operators? I created my own <= operator for int8
which returns true on null input, and put it in a btree operator class.
Admittedly, it's weird th
3 | 3
sales | 4 | 4800 | 2007-08-08 | 3 ||| 3
(3 rows)
Admittedly, it's weird that (null <= 1) evaluates to true. But does it
violate the contract of the btree operator class or something? Didn't
find a clear answer in the docs.
--
Sergey Shinderukhttps://postgrespro.com/
s_ExprContext->ecxt_per_tuple_memory;
+#else
+ evalWfuncContext =
winstate->ss.ps.ps_ExprContext->ecxt_per_query_memory;
+#endif
Shouldn't we handle any pass-by-reference type the same? I suppose, a
user-defined window function can return some other type, not int8.
Best re
previous value instead. But if int8 is passed by reference,
the previous value stored in econtext->ecxt_aggvalues becomes a dangling
pointer when the per-output-tuple memory context is reset.
Attaching a patch that makes the window test fail on a 64-bit system.
Best regards,
--
Sergey Shinderuk
as running: select f();
I believe it's a use-after-free error, triggered by assigning a new
value to s in g(), thus making t a dangling pointer.
After reconnecting I get a scary error:
postgres=# select f();
ERROR: compressed pglz data is corrupt
Best regards,
--
Sergey Shinderukhttps://postgrespro.com/
On 20.09.2022 17:10, Daniel Gustafsson wrote:
On 20 Sep 2022, at 15:43, Sergey Shinderuk wrote:
There is a race around setting and clearing of dathasloginevt.
Thanks for the report! The whole dathasloginevt mechanism is IMO too clunky
and unelegant to go ahead with, I wouldn't be surp
D 4 THEN
+ RAISE EXCEPTION 'Login forbidden';
+END IF;
can be bypassed with PGOPTIONS='-c timezone=...'. Probably this is
nothing new and concerns any SECURITY DEFINER function, but still...
Best regards,
--
Sergey Shinderukhttps://postgrespro.com/
On 14.01.2022 13:01, Sergey Shinderuk wrote:
Unexpectedly, this changes the error message:
postgres=# set idle_session_timeout = '1s';
SET
postgres=# select 1;
could not receive data from server: Software caused connection
abort (0x2745/10053)
For the rec
On 14.01.2022 13:01, Sergey Shinderuk wrote:
When the timeout expires, the server sends the error message and
gracefully closes the connection by sending a FIN. Later, psql sends
another query to the server, and the server responds with a RST. But
now recv() returns WSAECONNABORTED(10053
s WSAECONNRESET.
IIUIC, in both cases we may or may not recv() the error message from the
server depending on how fast the RST arrives from the server.
Should we handle ECONNABORTED similarly to ECONNRESET in pqsecure_raw_read?
--
Sergey Shinderukhttps://postgrespro.com/
of time on that to close the loop and
make sure that no code paths are missing an error context, adjusted a
couple of comments to explain more the role of *errstr in all the
SCRAM routines, and finally applied it on HEAD.
Thanks!
--
Sergey Shinderukhttps://postgrespro.com/
in a
couple of places (see the diff attached).
Didn't test it.
--
Sergey Shinderukhttps://postgrespro.com/diff --git a/src/common/hmac.c b/src/common/hmac.c
index 592f9b20a38..a27778e86b3 100644
--- a/src/common/hmac.c
+++ b/src/common/hmac.c
@@ -46,9 +46,7 @@ typede
On 11.01.2022 10:57, Michael Paquier wrote:
On Tue, Jan 11, 2022 at 10:50:50AM +0300, Sergey Shinderuk wrote:
+ * Returns a static string providing errors about an error that happened
"errors about an error" looks odd.
Sure, that could be reworded. What about "providing d
d to never
return NULL. I find that confusing.
If I have two distinct pg_hmac_ctx's, are their errreason's idependent
from one another or do they really point to the same static buffer?
Regards,
--
Sergey Shinderukhttps://postgrespro.com/
falls back to
/usr/lib/libpq.5.dylib provided by Apple (I am testing on Catalina).
% DYLD_PRINT_LIBRARIES=1 ./tmp_install/usr/local/bin/psql --version 2>&1
| grep libpq
dyld: loaded: <4EDF735E-2104-32AD-BE7B-B400ABFCF57C> /usr/lib/libpq.5.dylib
Regards,
--
Sergey Shinderukhttps://postgrespro.com/
On 13.10.2021 07:21, Michael Paquier wrote:
Looks fine seen from here, so I'll apply shortly.
Thank you!
--
Sergey Shinderukhttps://postgrespro.com/
On 10.10.2021 20:12, Peter Eisentraut wrote:
On 04.10.21 19:09, Sergey Shinderuk wrote:
I wonder what is the proper fix. Just drop pfree() altogether or add
pstrdup() instead? I see that makeMultirangeTypeName() doesn't bother
freeing its buf.
I think removing the pfree()s is a correc
uot;}}
(gdb) n
1900if (!commandCollected)
(gdb) p *(Value *)((TypeName *)((DefElem *)((CreateRangeStmt
*)parsetree)->params->elements[1].ptr_value)->arg)->names->elements[0].ptr_value
$2 = {type = T_String, val = {ival = -401972176, str = 0x5652e80a6430
'\177' , "\020"}}
Regards,
--
Sergey Shinderukhttps://postgrespro.com/
hem from clang on macOS either.
> I’ve optimistically updated the patch to hopefully address them, but I’d like
> to know what I need to do to get those warnings.
But gcc-11 on Ubuntu 20.04 emits them.
Regards,
--
Sergey Shinderukhttps://postgrespro.com/
On 01.10.2021 15:05, Daniel Gustafsson wrote:
>> On 1 Oct 2021, at 12:39, Sergey Shinderuk wrote:
>
>> Here is a patch fixing the subject.
>
> Seems reasonable on a quick glance, the interim h buffer should be freed (this
> is present since 14). I'll have another l
Hi,
Here is a patch fixing the subject.
Regards,
--
Sergey Shinderukhttps://postgrespro.com/
diff --git a/src/common/hmac.c b/src/common/hmac.c
index 1089db67443..bfe2e7cb5e9 100644
--- a/src/common/hmac.c
+++ b/src/common/hmac.c
@@ -232,7 +232,10 @@ pg_hmac_final(pg_hmac_ctx
On 23.09.2021 10:50, zhang listar wrote:
> Thanks for your reply, I do make distclean and git clean -fdx, but it
> does no help.
>
> the code: master, c7aeb775df895db240dcd6f47242f7e08899adfb
> It looks like the macos issue, because of the ignoring of some lib, it
> drives the compiling error.
M
s -lpgcommon -lpgport -lz -lreadline -lm -o zic
Looks the same, and gives no warnings.
Just in case, I configured like that:
./configure --prefix=$(cd ..;pwd)/install-gcc-11 --enable-cassert
--enable-debug --enable-tap-tests CC=/usr/local/bin/gcc-11
Hope that helps.
--
Sergey Shinderukhttps://postgrespro.com/
On 23.01.2021 08:02, Sergey Shinderuk wrote:
On the whole it looks like we should recommend installing the CLT
and not bothering with Xcode, which is about 10X the size:
$ du -hs /Library/Developer/CommandLineTools
1.1G /Library/Developer/CommandLineTools
$ du -hs /Applications/Xcode.app
On 23.01.2021 08:02, Sergey Shinderuk wrote:
I checked the script [1], and it really requires the CLT. Here is the
explanation [2] for this:
There is actually no such requirement. However, there are
formulae that will be forced to build from source if you do not
have the CLT
er to use only the CLT
because it's a much smaller download and takes less time to
install and upgrade than Xcode.
[1] https://github.com/Homebrew/install/blob/master/install.sh#L191
[2] https://github.com/Homebrew/brew/issues/1613
Regards.
--
Sergey Shinderuk
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Postgres successfully. So it looks like Xcode is really enough, at
least on a recent macOS version.
[1] https://xcodereleases.com
--
Sergey Shinderuk
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 21.01.2021 02:07, Tom Lane wrote:
I now believe what is actually happening with the short command is
that it's iterating through the available SDKs (according to some not
very clear search path) and picking the first one it finds that
matches the host system version. That matches the ktrace e
On 15.01.2021 04:45, Tom Lane wrote:
Hence, I propose the attached. This works as far as I can tell
to fix the problem you're seeing.
Yes, it works fine. Thank you very much.
On 15.01.2021 05:04, Tom Lane wrote:
on her machine there's no detail at all:
% xcrun --verbose --no-cache --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
The same on my machine. I get details for --find, but not for
--show-sdk-path.
So I'm not sure what to make
On 15.01.2021 04:53, Sergey Shinderuk wrote:
I see that "xcrun --sdk macosx --show-sdk-path" really calls
"/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk
macosx -version Path" under the hood.
... and caches the result. xcodebuild not called witho
On 15.01.2021 01:13, Tom Lane wrote:
than relying entirely on xcodebuild. Maybe there's a case for trying
"xcrun --sdk macosx --show-sdk-path" in between; in my tests that
seemed noticeably faster than invoking xcodebuild, and I've not yet
seen a case where it gave a different answer.
I see
On 14.01.2021 21:05, Tom Lane wrote:
After considerable playing around, I'm guessing that the reason
-no_weak_imports doesn't help is that it rejects calls that are
marked as weak references on the *calling* side. Since AC_CHECK_FUNCS
doesn't bother to #include the relevant header file, the comp
On 15.01.2021 01:13, Tom Lane wrote:
I borrowed my wife's Mac, which is still on Catalina and up to now
never had Xcode on it, and found some very interesting things.
Step 1: download/install Xcode 12.3, open it, agree to license,
wait for it to finish "installing components".
At this point, /L
On 14.01.2021 18:42, Tom Lane wrote:
I noticed that "cc" invoked from command line uses:
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
Hm, how did you determine that exactly?
% echo 'int main(void){}' >tmp.c
% cc -v tmp.c
Apple clang version 12.0.0 (clang-1200.0.32.28)
T
The symptoms sound consistent with using bleeding-edge Xcode on a
Catalina machine ... please report exact OS and Xcode versions.
macOS 10.15.7 (19H2)
Xcode 12.3 (12C33)
macOS SDK 11.1 (20C63)
Everything is fine if I run "configure" with
PG_SYSROOT=/Library/Developer/CommandLineTools/SDKs/Mac
On 13.01.2021 12:56, Thomas Munro wrote:
On Wed, Jan 13, 2021 at 10:40 PM Sergey Shinderuk
wrote:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include/sys/uio.h:104:9:
note: 'pwritev' has been marked as being introduced in
Expected in: /usr/lib/libSystem.B.dylib
Regards.
--
Sergey Shinderuk
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
51 matches
Mail list logo
