reak server log checking), so the installcheck should
be performed against some clean and determinated installation anyway.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
at the demo
script:
https://pastebin.com/3jQahYNe
If you have any questions, please don't hesitate to ask.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
and move to a newer one in a
controlled manner.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
for me the question is whether the
increasing the testing surface justifies this use of time.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e" or "make world", I'm getting compilation error.
I've attached complete error report at the end of the mail.
Can you try the .cmd script (https://pastebin.com/LU9gdn27), that
compiles REL_10_STABLE on Windows with msys2 and mingw-w64 successfully?
In case of any issues with it, plea
Hello,
Please consider committing the attached patch to fix a typo in error
message.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c
index
law/pg-doc-ru/blob/master/postgresql-doc/adminpack.po
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
he rules for building pg_regress. I don't find
> that to be very relevant to the problem.
I can simplify the patch to fix only the ECPG failure, and then prepare
a distinct patch for libs, if it makes sense.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hello Tom,
31.07.2018 01:16, Tom Lane wrote:
> Alexander Lakhin writes:
>> 14.07.2018 13:57, Peter Eisentraut wrote:
>>> On 06.07.18 09:45, Alexander Lakhin wrote:
>>>> ./configure --enable-tap-tests
>>>> make install
>>>> make install -C co
Hello Peter,
14.07.2018 13:57, Peter Eisentraut wrote:
> On 06.07.18 09:45, Alexander Lakhin wrote:
>> ./configure --enable-tap-tests
>> make install
>> make install -C contrib
>> chown -R postgres:postgres /usr/local/pgsql/
>> /usr/local/pgsql/bin/initdb -D /u
sql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
/make clean/
# Also you can just install binary packages to get the same state.
make installcheck-world
# This check fails.
Best regards,
--
Alexander Lakhin
Postgres Professional: h
...
is installed in /usr/local/pgsql/bin/, should it be checked by the
installcheck? And if we target the installed stuff then why do we need
to build something (or have something built) for installcheck?
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
is for.
> I agree with Tom's position, and this is the behavior that Postgres is
> using for ages for check and installcheck. If there are no objections,
> I'll mark the patch as rejected and move on to other things.
> --
> Michael
It seems, that you miss a major part of the discussion (we have
discussed the issue from other positions later).
And I don't think that age of the behavior should prevail over it's
reasonability.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
SELECT * FROM pg_stat_database; SELECT
datid, datname FROM pgsd FOR UPDATE;
CREATE VIEW
datid | datname
---+---
13021 | postgres
1 | template1
13020 | template0
(3 rows)
(And lock is really held by the second SELECT.)
Best regards,
--
Alexander Lakhin
Postgres Professional
13.04.2018 18:55, Tom Lane wrote:
Although this is arguably a security bug, I'm not sure we should
back-patch it. The consequences seem relatively minor, and the
behavioral change carries a significant risk of breaking applications
that worked as-intended up to now. Thoughts?
The worst
06.04.2018 09:19, Alexander Lakhin wrote:
To avoid overheating of this pretty hot discussion, I would like just
to propose "a more elaborated fix" (for REL_10_STABLE and master).
In fact, when we perform "make installcheck" it not only requires us
to build ecpg, but it also
his scenario should be supported, a more elaborated fix is needed.
Best regards,
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/interfaces/ecpg/test/Makefile.regress b/src/interfaces/ecpg/test/Makefile.regress
index b3d7c1e..5df1a44
Hello,
30.11.2018 23:59, Dmitry Dolgov wrote:
>> On Sun, Nov 18, 2018 at 8:31 AM Alexander Lakhin wrote:
>>
>> I've modified the patch to use the installed version of pg_regress. It
>> simplifies a lot. The main idea of the change is to not build pg_regress
Hello,
01.12.2018 09:12, Alexander Lakhin wrote:
> 30.11.2018 23:59, Dmitry Dolgov wrote:
>> Hi,
>>
>> I've noticed that for this patch cfbot show strange error
>>
>> USE_INSTALLED_ASSETS=1 make all
> I've fixed the patch.
Rebased the patch once more after d3c0
Hello David,
25.03.2019 10:25, David Steele wrote:
> Hi Alexander,
>
> On 2/18/19 8:07 AM, Michael Paquier wrote:
>> On Thu, Feb 14, 2019 at 11:40:29AM -0800, Andres Freund wrote:
>>> I'm confused. I don't see the patch as ready, given the discussion, nor
>>> does
>>>
04.02.2019 5:09, Michael Paquier wrote:
> On Mon, Dec 03, 2018 at 11:58:13AM +0300, Alexander Lakhin wrote:
>> Rebased the patch once more after d3c09b9b.
> Moved to next CF, waiting on author as the patch conflicts with HEAD.
> --
> Michael
Hello Michael,
It's very strange
Hello Amit,
25.05.2019 13:42, Amit Kapila wrote:
> I think it is good to fix these. I haven't verified all but I can
> review them. Isn't it better to fix them as one patch instead of
> multiple patches?
If a single patch is more convenient, then here it is.
I thought that separate patches
Hello hackers,
I've done another round of cross-checking the master branch for new
unique identifiers/words. As my previous attempt to fix things was not
noticed, now I'm focusing on distinct typos.
1. authenticaion (user-visible string)
2. becuase
3. checkinunique
4. cheep
5. comparion
28.05.2019 2:05, Amit Kapila wrote:
> On Mon, May 27, 2019 at 3:59 AM Tom Lane wrote:
>> Amit Kapila writes:
>>> On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin
>>> wrote:
>>>> 5. ExecContextForcesOids - not changed, but may be should be removed
>
Hello hackers,
Please also consider fixing the following inconsistencies found in new
v12 code:
1. AT_AddOids - remove (orphaned after 578b2297)
2. BeingModified ->TM_BeingModified (for consistency)
3. copy_relation_data -> remove (orphaned after d25f5191)
4. endblock -> endblk (an internal
26.05.2019 16:49, Amit Kapila wrote:
> This occurred to me as well while reviewing, but I thought typo fixes
> should be fine. Anyway, I have excluded those before pushing. So, if
> we want to fix these, then maybe one has to first get this fixed in
> upstream first and then take from there.
>
Hello Amit,
07.06.2019 7:30, Amit Kapila wrote:
> Leaving the changes related to the above two points, I have combined
> all the changes and fixed the things as per my review in the attached
> patch. Alexander, see if you can verify once the combined patch. I
> am planning to commit the attached
Hello Michael,
13.06.2019 11:10, Michael Paquier wrote:
> On Wed, Jun 12, 2019 at 05:34:06PM +0300, Alexander Lakhin wrote:
>> I can't see another inconsistencies for v12 for now, but there are some
>> that appeared before.
>> If this work can be performed more
Hello hackers,
When running on REL_11_STABLE the following query:
CREATE PROCEDURE test_ambiguous_procname(int) as $$ begin end; $$
language plpgsql;
CREATE PROCEDURE test_ambiguous_procname(text) as $$ begin end; $$
language plpgsql;
DROP PROCEDURE test_ambiguous_procname;
under valgrind I get
Hello Amit,
Can you also review the following fixes?:
2.1. bt_binsrch_insert -> _bt_binsrch_insert (an internal inconsistency)
2.2. EWOULDBOCK -> EWOULDBLOCK (a typo)
2.3. FORGET_RELATION_FSYNC & FORGET_DATABASE_FSYNC ->
SYNC_FORGET_REQUEST (orphaned after 3eb77eba)
2.4. GetNewObjectIdWithIndex
Hello,
13.06.2019 11:10, Michael Paquier wrote:
> The last trace of tss_htup has been removed as of 2e3da03, and I see
> no mention of it in the related thread. Andres, is that intentional
> for table AMs to keep a trace of a currently-fetched tuple for a TID
> scan or something that can be
Hello hackers,
Please consider fixing the following typos and inconsistencies living in
the source code starting from v11:
3.1 add_placeholders_to_child_joinrel -> remove (orphaned after 7cfdc770)
3.2 AttachIndexInfo -> IndexAttachInfo (an internal inconsistency)
3.3 BlockRecordInfo ->
17.06.2019 10:16, Michael Paquier wrote:
> On Sat, Jun 15, 2019 at 06:00:00PM +0300, Alexander Lakhin wrote:
>> Two summary patches for REL_11_STABLE and master are attached.
> Thanks. I have committed to HEAD most of the inconsistencies you have
> pointed out.
Thank you, Michael.
Hello hackers,
I've stumbled upon a misspelled HAVE_ZLIB in a comment and decided to
check all the unique identifiers/entities in the source tree. Using the
balleyeing technique I've processed questionable A* and HAVE_* unicums
(for now). The patches for every one are attached.
1. AExprConst ->
Hello Thomas,
01.07.2019 13:47, Thomas Munro wrote:
>
> A new CF is here and this is in "Needs Review". Would you like to
> provide a rebased patch, or should it really be withdrawn?
The rebased patch is attached, but I still can't find anyone interested
in reviewing it.
So let's withdraw it.
Hello hackers,
Please consider fixing the next batch of typos and inconsistencies in
the tree:
6.1. FADVISE_WILLNEED -> POSIX_FADV_WILLNEED
6.2. failOK -> missing_ok
6.3. failOnerror -> failOnSignal
6.4. fakebits -> remove (irrelevant since introduction in 945543d9)
6.5. FastPathGetLockEntry ->
Hello hackers,
Please consider fixing the next bunch of typos and inconsistencies in
the tree:
4.1. AccesShareLock -> AccessShareLock
4.2. AdjustTimestampForTypemod -> AdjustTimestampForTypmod
4.3. AExprConst -> AexprConst
4.4. AlterExtensionOwner_oid - remove (orphaned after 994c36e0)
4.5.
Hello hackers,
Please consider fixing the next truss of typos and inconsistencies in
the tree:
9.1. NAMESPACE_SQLXML -> remove (not used since the introduction in
355e05ab)
9.2. NBXLOG_H -> NBTXLOG_H
9.3. NEWPAGE -> XLOG_FPI (orphaned since 54685338)
9.4. newXlogId, newXlogSeg -> newXlogSegNo
Hello hackers,
Please consider fixing the next heap of typos and inconsistencies in the
tree:
10.1. query_txt -> query text
10.2. quote_object_names -> quote_object_name
10.3. ragetypes_typanalyze.c -> rangetypes_typanalyze.c
10.4. RAISE_EXCEPTION -> ERRCODE_RAISE_EXCEPTION
10.5. rb_lower ->
Hello hackers,
Now that the unicums checking is finished, I would like to share the
script I used to find them.
Maybe it can be useful to recheck the source tree from time to time...
I don't think that the check could be fully automated, but with some
eyeballing it allows to maintain a more
Hello hackers,
Please consider fixing the last group (for now) of typos and
inconsistencies in the tree:
11.1 peforming -> performing
11.2 table_freeze_age -> freeze_table_age
11.3 TableInfoData -> TableDataInfo
11.4 TableStatus -> PgStat_TableStatus
11.5 TAG_VALID -> BM_TAG_VALID
11.6
Hello hackers,
Please consider fixing the next set of typos and inconsistencies in the
tree:
8.1. LABORT -> LIKE_ABORT
8.2. LagTrackerWriter -> LagTrackerWrite
8.3. lag_with_offset_and_default, * ->
window_lag_with_offset_and_default, window_* (in windowfuncs.c)
8.4. language-name ->
Hello Michael,
05.08.2019 6:15, Michael Paquier wrote:
>> 9.41. OWNER_TO -> OWNER TO
> This one needs a back-patch. I'll fix that separately.
>
I believe that all the fixes in doc/ should be back-patched too. If it's
not too late, I can produce such patches for the nearest releases.
>> 9.75.
05.08.2019 8:40, Michael Paquier wrote:
> On Mon, Aug 05, 2019 at 06:44:46AM +0300, Alexander Lakhin wrote:
>> I believe that all the fixes in doc/ should be back-patched too. If it's
>> not too late, I can produce such patches for the nearest releases.
> I think that's unfor
Hello hackers,
Please consider fixing the next pack of typos and inconsistencies in the
tree:
7.1. h04m05s06 -> h04mm05s06 (in fact it's broken since 6af04882, but
h04mm05s06.789 still accepted)
7.2. hasbucketcleanup -> hashbucketcleanup
7.3. _hashm_spare -> hashm_spares
7.4. hashtbl -> hash
Hello Michael,
22.07.2019 4:05, Michael Paquier wrote:
>> Also, I found e-mail headers in optimizer/plan/README not relevant, so I
>> propose to remove them.
> Not sure about that part.
I agree that the proposed fix is not complete, but just raises the
demand for a subsequent fix.
If you don't
Hello Tom,
22.07.2019 7:14, Tom Lane wrote:
>> Fixing both places sounds adapted to me. An alternative we could use
>> here is just to say something like that:
>> The effective resolution is only 1/HZ, which can be configured with
>> kernel parameter (see man 7 time), and is 4 milliseconds by
>>
Hello hackers,
Please consider fixing the next cluster of typos and inconsistencies in
the tree:
5.1. datetkntbl -> datetktbl
5.2. datminxmid -> datminmxid
5.3. DatumGetP -> DatumGetPointer
5.4. ECPG_COMPILE, DECPG_COMPILE -> remove (orphaned since 328d235)
5.5. defer_cleanup_age ->
Hello hackers,
I've noticed that the createuser utility supports two undocumented
options (--adduser, --no-adduser), that became obsolete in 2005.
I believe that their existence should come to end someday (maybe
today?). The patch to remove them is attached.
Best regards.
Alexander
diff --git
Hello hackers,
When dealing with an OS upgrade, a some kind of anomaly related to
collations was found.
Suppose, we have Debian 8 with postgresql 12 installed.
Then we create a custom collation:
CREATE COLLATION russian (provider=icu, locale='ru_RU');
and
SELECT oid, collname, collnamespace,
28.11.2019 23:25, Thomas Munro пишет:
> On Fri, Nov 29, 2019 at 9:08 AM Alexander Lakhin wrote:
>> So for now it seems dangerous to use predefined collations as their old
>> versions are not preserved by pg_upgrade and the user doesn't know which
>> indexes affected by the
Hello hackers,
19.04.2020 13:37, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> The HEAPDEBUGALL define has been broken since PG12 due to tableam
>> changes. Should we just remove this? It doesn't look very useful.
>> It's been around since Postgres95.
>> If we opt for removing: PG12 added an
21.04.2020 21:01, Peter Eisentraut wrote:
> On 2020-04-19 22:00, Alexander Lakhin wrote:
>> To the point, I've tried to use HAVE_ALLOCINFO on master today and it
>> failed too:
>
> Do you have a proposed patch?
>
As this is broken at least since the invention of the generat
Hello hackers,
I've found that gcov coverage data miss some information when a postgres
node stopped in 'immediate' mode.
For example, on the master branch:
make coverage-clean; time make check -C src/test/recovery/; make
coverage-html
generates a coverage report with 106193 lines/6318 functions
Hello Alvaro,
11.05.2020 06:42, Alvaro Herrera wrote:
> (Strangely, I was just thinking about these branches of mine as I
> closed my week last Friday...)
>
> On 2020-May-10, Alexander Lakhin wrote:
>
>> So if we want to make the coverage reports more precise, I see the three
Hello hackers,
Please consider fixing minor defects in the source code and documentation.
1. a missing dot in guc.c
"SELECT name, short_desc FROM pg_settings WHERE short_desc NOT LIKE
'%.'" finds only this one instance.
2. inrange -> in_range
the former spelling is unique
3. sigature -> signature
Hello Tom,
09.09.2020 18:29, Tom Lane wrote:
> Alexander Lakhin writes:
>> Please consider fixing minor defects in the source code and documentation.
> I agree with all of these, except the markup fixes in bgworker.sgml
> still seem not right; it shou
Hello hackers,
13.09.2020 21:37, Tom Lane wrote:
> I happened to try googling for other similar reports, and I found
> a very interesting recent thread here:
>
> https://github.com/nodejs/node/issues/33166
>
> It might not have the same underlying cause, of course, but it sure
> sounds familiar.
16.10.2020 19:18, Tom Lane wrote:
> Oh, very interesting.
> Now that you have it somewhat in captivity, maybe you could determine
> some things:
>
> 1. Is it only stdout that's affected? What of other stdio streams?
> (Note that testing stderr might be tricky because it's probably
>
17.10.2020 21:44, Tom Lane wrote:
> I propose the attached patch. If this doesn't cause buildfarm problems,
> perhaps we should back-patch it.
Thank you!
I've made a simple cmd script to reproduce problems seen on dory:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=dory=HEAD
FOR /L
18.10.2020 21:04, Tom Lane wrote:
> Alexander Lakhin writes:
>> @@ -0,0 +1 @@
>> +SQL error: descriptor "mydesc" not found on line 31
> does not look like the same kind of failure as what we've been dealing
> with up to now. So maybe what we've got is that we
Hello,
18.12.2020 19:02, Tom Lane wrote:
> "osumi.takami...@fujitsu.com" writes:
>> I have a question about how to execute valgrind with TAP tests
>> in order to check some patches in the community.
>> My main interest is testing src/test/subscription now but
>> is there any general way to do it
13.11.2020 23:16, Tom Lane wrote:
> Alexander Lakhin writes:
>> Shouldn't pg_ls_dir_files() retry stat() on ERROR_ACCESS_DENIED just
>> like the pgwin32_open() does to ignore files in "delete pending" state?
> That would soon lead us to changing every stat() caller in
Hello hackers,
31.03.2020 19:41, Tom Lane wrote:
> Justin Pryzby writes:
>> I suggest to leave stat() alone in your patch for stable releases. I think
>> it's okay if we change behavior so that a broken symlink is skipped instead
>> of
>> erroring (as a side effect of skipping ENOENT with
Hello hackers,
After fixing bug #16161 (pg_ctl inability to open just deleted
postmaster.pid) there are still some errors related to the same
Windows-only issue.
Namely, pg_upgradeCheck failures seen on
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren=REL_13_STABLE
Here
15.11.2020 04:11, Justin Pryzby wrote:
> On Sat, Nov 14, 2020 at 01:00:00PM +0300, Alexander Lakhin wrote:
>> As noted in [1], a sensible solution would be putting the same "retry on
>> ERROR_ACCESS_DENIED" action in a wrapper for stat().
>> And bed90759f brought in
Hello Tom,
18.11.2020 23:39, Tom Lane wrote:
> BTW ... scraping the buildfarm logs for "could not open ... Permission
> denied" failures suggests that pgwin32_open() isn't the pinnacle of
> perfection either. In the last three months I found these instances:
>
> dory | REL_11_STABLE |
19.11.2020 01:28, Tom Lane wrote:
> Alexander Lakhin writes:
>> 18.11.2020 23:39, Tom Lane wrote:
>>> Now, the ones on the 10 and 11 branches are all from pg_ctl, which
>>> does not use pgwin32_open() in those branches, only native open().
>>> So those aren
15.11.2020 08:00, Alexander Lakhin wrote:
> And it rises another question, what if pg_ls_dir_files() is called for a
> directory where hundreds or thousands of files are really inaccessible
> due to restrictions?
> I mean that using CreateFile() in the modified stat() implem
Hello Tom,
04.01.2021 08:47, Tom Lane wrote:
> Hm. There isn't anything about test_regex()'s API that I would want
> to expose to end users ;-) ... it's just designed to replicate the
> test API that Henry Spencer designed a couple decades ago, which IMO
> was not too clean even by the standards
Hello Michael,
06.07.2021 11:33, Michael Paquier wrote:
> On Sun, Mar 14, 2021 at 06:00:00PM +0300, Alexander Lakhin wrote:
>> I believe that the patch attached to [1] should fix this issue. The
>> patch still applies to master and makes the demotest (attached to [2])
>> pas
Hello,
While trying to use sqlsmith with postgres compiled from the master
branch, I've found that the PQerrorMessage() function now returns
non-informational but not empty error message after the successful
PQconnectdb() call.
conn = PQconnectdb(conninfo.c_str());
char *errmsg =
Hello Michael,
12.07.2021 08:52, Michael Paquier wrote:
> On Mon, Jul 12, 2021 at 02:09:41PM +0900, Michael Paquier wrote:
>> And fairywren, that uses MinGW, is unhappy:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren=2021-07-12%2004%3A47%3A13
>> Looking at it now.
> I am not
12.07.2021 09:23, Michael Paquier wrote:
> On Mon, Jul 12, 2021 at 09:06:01AM +0300, Alexander Lakhin wrote:
>> I'll take care of it and will prepare mingw-compatible patch tomorrow.
> Thanks. Do you have an environment with 32b or 64b MinGW?
Yes, I have VMs with 32- and 64-bit mingw
Hello Michael,
09.07.2021 08:52, Michael Paquier wrote:
> On Thu, Jul 08, 2021 at 11:00:00PM +0300, Alexander Lakhin wrote:
>> Beside the aforementioned test I can only propose the extended patch,
>> that incorporates the undo of the changes brought by bed90759f.
>> With
08.07.2021 10:47, Michael Paquier wrote:
> On Thu, Jul 08, 2021 at 07:00:01AM +0300, Alexander Lakhin wrote:
>> As Tom Lane noted above, the code added with bed90759f is dubious
>> (_NtQueryInformationFile() can not be used to handle the "delete
>> pending"
27.06.2021 23:07, Tom Lane wrote:
>> While trying to use sqlsmith with postgres compiled from the master
>> branch, I've found that the PQerrorMessage() function now returns
>> non-informational but not empty error message after the successful
>> PQconnectdb() call.
> Yeah, see thread here:
>
>
Hello hackers,
22.11.2020 18:59, Alexander Lakhin wrote:
> 19.11.2020 01:28, Tom Lane wrote:
>
>> Hmm, that is an interesting question isn't it. Here's a search going
>> back a full year. There are a few in v12 --- interestingly, all on
>> the statistics file, none
Hello hackers,
11.11.2020 04:04, Michael Paquier wrote:
> And this configuration matches exactly what you have with the host
> where the test passed.
>
> Now I do see a difference in the Windows 10 build involved, 10.0.19041
> fails but 10.0.18363 passes. I find rather hard to buy that this is
>
Hello hackers,
14.09.2021 04:32, Andres Freund wrote:
> On 2021-09-07 14:44:39 -0500, Justin Pryzby wrote:
>> On Tue, Sep 07, 2021 at 12:27:27PM -0700, Andres Freund wrote:
>>> I think this is a tad too strong. We should continue to clean up on exit as
>>> long as the error didn't happen while
06.09.2021 16:04, Thomas Munro wrote:
> On Mon, Sep 6, 2021 at 6:36 PM Michael Paquier wrote:
>> The last time I poked at the bear (54fb8c7d), there was a test posted
>> by Alexander Lakhin that was really useful in making sure that
>> concurrency is correctly handled wh
Hello Michael,
07.09.2021 09:05, Michael Paquier wrote:
> On Tue, Sep 07, 2021 at 09:00:01AM +0300, Alexander Lakhin wrote:
>> The new approach looks very promising. Knowing that the file is really
>> in the DELETE_PENDING state simplifies a lot.
>> I've tested the patch v2_
Hello Andres,
14.09.2021 08:05, Andres Freund wrote:
>
>> With LLVM 9 on the same Centos 7 I don't get such segfault. Also it
>> doesn't happen on different OSes with LLVM 7.
> That just like an llvm bug to me. Rather than the usage issue addressed in
> this thread.
But Justin seen this
Hello Michael,
12.07.2021 08:52, Michael Paquier wrote:
> On Mon, Jul 12, 2021 at 02:09:41PM +0900, Michael Paquier wrote:
>> And fairywren, that uses MinGW, is unhappy:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren=2021-07-12%2004%3A47%3A13
>> Looking at it now.
> I am not
Hello Mark,
04.10.2021 01:20, Mark Dilger wrote:
> The attached patch includes a test case for this, which shows the problems
> against the current pg_amcheck.c, and a new version of pg_amcheck.c which
> fixes the bug. Could you review it?
>
> Thanks for bringing this to my attention.
There is
Hello Mark, Peter, Robert,
05.10.2021 20:22, Peter Geoghegan пишет:
> On Tue, Oct 5, 2021 at 10:03 AM Mark Dilger
> wrote:
>> I took no offense. Actually, I owe you a thank-you for having put so much
>> effort into debating the behavior with me. I think the patch to fix bug
>> #17212 will be
Hello Andrew,
06.12.2021 17:56, Andrew Dunstan wrote:
> Yeah, quite annoying, especially because only some combinations of MSVC
> runtime / openssl version seem to trigger the problem.
>
>
> Adding a shutdown() before the closesocket() also fixes the issue.
>
Can you confirm that adding
04.01.2022 18:33, Tom Lane wrote:
> Alexander Lakhin writes:
>> It's hardly that important, but we (Postgres Pro) run this test
>> regularly to check for primary-standby compatibility. It's useful when
>> checking binary packages from different minor versions. For example, w
04.01.2022 22:19, Tom Lane wrote:
> Alexander Lakhin writes:
>> While testing the index-only scan fix, I've discovered that replacing
>> the index-only scan with the index scan changes contrib/btree_gist
>> output because index-only scan for btree_gist returns a string with
Hello Tom,
04.01.2022 00:50, Tom Lane wrote:
> The attached proposed patch removes some ancient infrastructure for
> manually testing hot standby. I doubt anyone has used this in years,
> because AFAICS there is nothing here that's not done better by the
> src/test/recovery TAP tests. (Or if
Hello Lars,
27.11.2021 14:39, Lars Kanis wrote:
>
> So I still think it's best to close the socket as proposed in the patch.
Please see also the previous discussion of the topic:
https://www.postgresql.org/message-id/flat/16678-253e48d34dc0c376%40postgresql.org
Best regards,
Alexander
Hello Alvaro,
14.10.2021 01:09, Alvaro Herrera wrote:
>> Yea, let's go for your patch then. I've verified that at least locally it
>> passes under valgrind.
> Ah great, thanks. Pushed then.
>
While translating messages I've noticed that the version of the patch
ported to
Hello Tom,
29.11.2021 22:16, Tom Lane wrote:
> Hm, yeah, that discussion seems to have slipped through the cracks.
> Not sure why it didn't end up in pushing something.
>
> After re-reading that thread and re-studying relevant Windows
> documentation [1][2], I think the main open question is
Hello Daniel and Michael,
02.12.2021 08:03, Michael Paquier wrote:
> On Wed, Dec 01, 2021 at 11:51:58AM +0100, Daniel Gustafsson wrote:
>> Michael, have you had a chance to look at the updated patch here? I'm moving
>> this patch entry from Waiting on Author to Needs Review.
> No, I haven't.
Hello Tom,
07.12.2021 19:25, Tom Lane wrote:
> Hmm. I wonder whether using SD_BOTH behaves any differently.
With shutdown(MyProcPort->sock, SD_BOTH) the test failed for me on
iterations 1, 2, 3, 16 (just as without shutdown() at all).
So shutdown with the SD_SEND flag definitely behaves much
06.12.2021 23:51, Andrew Dunstan wrote:
> I have been getting 100% failures on the SSL tests with closesocket()
> alone, and 100% success over 10 tests with this:
>
>
> diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c
> index 96ab37c7d0..5998c089b0 100644
> ---
Hello hackers,
While testing the index-only scan fix, I've discovered that replacing
the index-only scan with the index scan changes contrib/btree_gist
output because index-only scan for btree_gist returns a string without
padding.
A simple demonstration (based on btree_gist/sql/char.sql):
CREATE
Hello Tom,
09.01.2022 04:17, Tom Lane wrote:
>> So for some reason, on these machines detection of walsender-initiated
>> connection close is unreliable ... or maybe, the walsender didn't close
>> the connection, but is somehow still hanging around? Don't have much idea
>> where to dig beyond
10.01.2022 05:00, Thomas Munro wrote:
> On Mon, Jan 10, 2022 at 8:06 AM Thomas Munro wrote:
>> On Mon, Jan 10, 2022 at 12:00 AM Alexander Lakhin
>> wrote:
>>> Going down through the call chain, I see that at the end of it
>>> WaitForMultipleObjects() ha
13.01.2022 09:36, Thomas Munro wrote:
> Here's a draft attempt at a fix. First I tried to use recv(fd, , 1,
> MSG_PEEK) == 0 to detect EOF, which seemed to me to be a reasonable
> enough candidate, but somehow it corrupts the stream (!?), so I used
> Alexander's POLLHUP idea, except I pushed it
1 - 100 of 388 matches
Mail list logo
