Hello Michael,
18.02.2022 06:07, Michael Paquier wrpte:
> On Thu, Feb 17, 2022 at 09:00:20PM -0600, Justin Pryzby wrote:
>> BRIN can also crash if passed a non-brin index.
>>
>> I've been sitting on this one for awhile. Feel free to include it in your
>> patchset.
> Ugh. Thanks! I am keeping a
Hello Michael,
16.03.2022 10:39, Michael Paquier wrote:
On Mon, Feb 21, 2022 at 10:00:00AM +0300, Alexander Lakhin wrote:
Could you please confirm before committing the patchset that it fixes
the bug #16527 [1]? Or maybe I could check it?
(Original patch proposed by Daria doesn't cover
Hello Michael,
18.03.2022 05:06, Michael Paquier wrote:
Okay. I'll try to look more closely at that, then. It feels like we
are just missing a MAXALIGN() in those code paths. Are you using any
specific CFLAGS or something environment-sensitive (macos, 32b, etc.)?
No, just x86_64, Ubuntu 20.04,
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
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
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 stat()
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() calle
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&br=REL_13_STABLE
Here pg_
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
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() implementat
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 | 2020-0
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
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 o
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
> d
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 whethe
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. Befo
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 shutdown(My
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
> --- a/src/backend/lib
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 bette
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 ther
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
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
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
Hello,
07.01.2022 09:26, Japin Li wrote:
> On Fri, 07 Jan 2022 at 03:21, Tom Lane wrote:
>
> In any case, if we do need same() to implement the identical
> behavior to bpchareq(), then the other solution isn't sufficient
> either.
>
> So in short, it seems like we ought to do some compatibility te
07.01.2022 12:00, Alexander Lakhin wrote:
> Hello,
> 07.01.2022 09:26, Japin Li wrote:
>> On Fri, 07 Jan 2022 at 03:21, Tom Lane wrote:
>>
>> In any case, if we do need same() to implement the identical
>> behavior to bpchareq(), then the other solution isn'
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 that
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
10.01.2022 12:40, Thomas Munro wrote:
> This is super quick-and-dirty code (and doesn't handle some errors or
> socket changes correctly), but does it detect the closed socket?
Yes, it fixes the behaviour and makes the 002_standby test pass (100 of
100 iterations). I'm yet to find out whether the o
10.01.2022 23:52, Thomas Munro wrote:
>> I'm yet to find out whether the other
>> WaitLatchOrSocket' users (e. g. postgres_fdw) can suffer from the
>> disconnected socket state, but this approach definitely works for
>> walreceiver.
> I see where you're going: there might be safe call sequences an
13.01.2022 09:36, Thomas Munro wrote:
> On Wed, Jan 12, 2022 at 8:00 PM Alexander Lakhin wrote:
>> By the look of things, you are right and this is the localhost-only issue.
> But can't that be explained with timing races? You change some stuff
> around and it becomes less l
13.01.2022 09:36, Thomas Munro wrote:
> Here's a draft attempt at a fix. First I tried to use recv(fd, &c, 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
Hello Andres,
15.01.2022 01:44, Andres Freund wrote:
> What about instead giving WalReceiverConn an internal WaitEventSet, and using
> that consistently? I've attached a draft for that.
>
> Alexander, could you test with that patch applied?
Unfortunately, this patch doesn't fix the issue. The test
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 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 REL9_6_STABLE..REL_13_STAB
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
see the patch attached), it works, but this fix is only suited for
installcheck.
So if this 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
02.04.2018 12:12, Alexander Lakhin wrote:
Is it a supported scenario to make installcheck-world without
performing "make" first?
(If I do "make -C src/interfaces/ecpg" and then "make
installcheck-world", then this error is gone. And when I set up all
th
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 scenari
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
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 a/
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
>>> https://commitfest.postgresql
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 -> language_name
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 (or
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. Poin
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&#x
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 -> remo
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 TarDirecto
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 consis
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
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, collp
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 b
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 -> A
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 (user-visi
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 woul
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 incon
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.
>
>>
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
>
10.01.2024 13:37, Amit Kapila wrote:
But tomorrow it could be for other tables and if we change this
TRUNCATE logic for pg_largeobject (of which chances are less) then
there is always a chance that one misses changing this comment. I feel
keeping it generic in this case would be better as the pro
Hello Alexander,
I've discovered one more instability in the event_trigger_login test.
Please look for example at case [1]:
ok 213 + event_trigger 28946 ms
not ok 214 - event_trigger_login 6430 ms
ok 215 - fast_default
Hello Robert,
12.01.2024 17:50, Robert Haas wrote:
On Thu, Jan 11, 2024 at 8:00 PM Shinoda, Noriyoshi (HPE Services Japan
- FSIP) wrote:
Thank you for developing the new tool. I have attached a patch that corrects
the spelling of the --individual option in the SGML file.
Thanks, committed.
Hello Michael and Bertrand,
15.01.2024 06:59, Michael Paquier wrote:
The WAL records related to standby snapshots are playing a lot with
the randomness of the failures we are seeing. Alexander has mentioned
offlist something else: using SIGSTOP on the bgwriter to avoid these
records and make th
Hello hackers,
[ reporting this bug here due to limitations of the bug reporting form ]
When a node, that acted as a primary, becomes a standby as in the
following script:
[ ... some WAL-logged activity ... ]
$primary->teardown_node;
$standby->promote;
$primary->enable_streaming($standby);
$pri
Hello,
15.01.2024 12:00, Alexander Lakhin wrote:
If this approach looks promising to you, maybe we could add a submodule to
perl/PostgreSQL/Test/ and use this functionality in other tests (e.g., in
019_replslot_limit) as well.
Personally I think that having such a functionality for using in
Hi Aleksander,
19.01.2024 14:45, Aleksander Alekseev wrote:
it might not go online, due to the error:
new timeline N forked off current database system timeline M before current
recovery point X/X
[...]
In this case, node1 wrote to it's WAL record 0/304DC68, but sent to node2
only record 0/30
Hello Andres,
22.01.2024 23:41, Andres Freund wrote:
Hi,
I noticed that I was getting core dumps while executing the tests, without the
tests failing. Backtraces are vriations of this:
...
ISTM that we shouldn't basically silently overlook shutdowns due to crashes in
the tests. How to not do s
Hi Aleksander,
[ I'm writing this off-list to minimize noise, but we can continue the
discussion in -hackers, if you wish ]
22.01.2024 14:00, Aleksander Alekseev wrote:
Hi,
But node1 knows that it's a standby now and it's expected to get all the
WAL records from the primary, doesn't it?
Ye
Hello Alexander and Daniel,
Please look at the following query, which triggers an assertion failure on
updating the field dathasloginevt for an entry in pg_database:
SELECT format('CREATE DATABASE db1 LOCALE_PROVIDER icu ICU_LOCALE en ENCODING
utf8
ICU_RULES ''' || repeat(' ', 20) || ''' TEM
23.01.2024 20:30, Andres Freund wrote:
I don't think that's viable and would cause more problems than it solves, it'd
make us think that we might have an old postgres process hanging around that
needs to be terminted before we can start up. And I simply don't see the point
- we already record whe
Hello hackers,
After determining a possible cause for intermittent failures of the test
subscription/031_column_list [1], I was wondering what makes another
subscription test (014_binary) fail on the buildfarm:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snakefly&dt=2024-01-22%2001%3A
Hello,
27.01.2024 00:09, Tom Lane wrote:
David Rowley writes:
On Sat, 27 Jan 2024 at 09:41, Tom Lane wrote:
drongo and fairywren are consistently failing the test case added
by this commit. I'm not quite sure why the behavior of Memoize
would be platform-specific when we're dealing with int
Hello Robert,
26.01.2024 21:37, Robert Haas wrote:
On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart
wrote:
On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote:
Here is v2 with that addition.
Looks reasonable.
Thanks for the report & review. I have committed that version.
While try
24.01.2024 20:46, Robert Haas wrote:
This is weird. There's a little more detail in the log file,
regress_log_002_blocks, e.g. from the first failure you linked:
[11:18:20.683](96.787s) # before insert, summarized TLI 1 through 0/14E09D0
[11:18:21.188](0.505s) # after insert, summarized TLI 1 th
Hello Peter,
26.01.2024 16:42, Peter Eisentraut wrote:
I have committed all this. These are great improvements.
Please look at the segmentation fault triggered by the following query since
4d969b2f8:
CREATE TABLE t1(a text COMPRESSION pglz);
CREATE TABLE t2(a text);
CREATE TABLE t3() INHERI
Hello,
30.01.2024 18:57, Tristan Partin wrote:
Patch 1:
Passing NULL as a second argument to memcpy breaks ubsan, ...
Maybe you would like to fix also one more similar place, reached with:
create extension xml2;
select xslt_process('',
$$http://www.w3.org/1999/XSL/Transform";>
$$);
varlena
Hello Vignesh and Hou-san,
01.02.2024 07:59, vignesh C wrote:
Here is an updated patch which changes the boolean variable to a
tri-state enum and set stable state to valid only if no invalidations
have been occurred while the list is being prepared.
While testing the v3 patch, I observed anot
Hello Heikki,
08.11.2023 14:37, Heikki Linnakangas wrote:
Fixed these, and pushed. Thanks everyone for reviewing!
Please try the following script:
mkdir /tmp/50m
sudo mount -t tmpfs -o size=50M tmpfs /tmp/50m
export PGDATA=/tmp/50m/tmpdb
initdb
pg_ctl -l server.log start
cat << 'EOF' | psq
Hello Alvaro,
Please look at an anomaly introduced with b0e96f311.
The following script:
CREATE TABLE a ();
CREATE TABLE b (i int) INHERITS (a);
CREATE TABLE c () INHERITS (a, b);
ALTER TABLE a ADD COLUMN i int NOT NULL;
results in:
NOTICE: merging definition of column "i" for child "b"
NOTICE
Hello Tom and Noah,
03.02.2024 04:24, Tom Lane wrote:
I'm still wondering how come the failure seems to have suddenly gotten
way more common. The only changes that are in vaguely-related places
and fit the time frame are Amit's 732924043 and 776621a5e, but I sure
don't see a connection.
I thi
Hello Alexander,
05.02.2024 02:51, Alexander Korotkov wrote:
Usage of heap_inplace_update() seems appropriate for me here. It
avoids trouble with both TOAST and row-level locks. Alexander, could
you please recheck this fixes the problem.
I've re-tested the last problematic scenario and can
Hello Amit,
05.02.2024 15:20, Amit Kapila wrote:
If this can be reproduced frequently then we can even try to test the
patch in that thread by Osumi-San [1] (I haven't tested that it
applies cleanly but shouldn't be difficult to make it work) based on
the theory that walsender is starting up at
06.02.2024 09:48, Amit Kapila wrote:
cool, is it possible to see whether this patch changes the runtime of
this test in any noticeable way?
Yes, unfortunately it does.
I've measured duration of 100 tests runs without the patch (with pristine
bgwriter and with NO_TEMP_INSTALL):
real 6m46,031
05.02.2024 13:13, vignesh C wrote:
Thanks for the steps for the issue, I was able to reproduce this issue
in my environment with the steps provided. The attached patch has a
proposed fix where the latch will not be set in case of the apply
worker exiting immediately after starting.
It looks lik
Hello,
Please look at errors, which produced by the following script, starting
from 6566133c5:
for i in `seq 100`; do (echo "CREATE USER u; DROP USER u;"); done | psql >psql-1.log
2>&1 &
for i in `seq 100`; do (echo "CREATE USER u; DROP USER u;"); done | psql >psql-2.log
2>&1 &
wait
ERROR: co
08.02.2024 12:25, vignesh C wrote:
Yes, the wakeup call sent by the "CREATE SUBSCRIPTION" command was
getting missed in this case. The wakeup call can be sent during
subscription creation/modification and when the apply worker exits.
WaitForReplicationWorkerAttach should not reset the latch here
Hello Andres,
05.04.2023 21:48, Andres Freund wrote:
I just saw the following failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2023-04-05%2017%3A47%3A03
after a commit of mine. The symptoms look unrelated though.
[17:54:42.188](258.345s) # poll_query_until timed out e
Hello,
05.03.2023 02:31, Joseph Koshakow wrote:
I also don't have a copy of ISO 8601 and wasn't able to find anything
about this variant on Google. I did find this comment in datetime.c
/*
* Was this an "ISO date" with embedded field labels? An
* example is "y2001m02d04" - thomas 2001-02-04
*/
10.03.2023 03:26, Tom Lane wrote:
Joseph Koshakow writes:
Also I removed some dead code from the previous patch.
That's a little weird, or maybe even a lot weird, but it's not
inherently nonsensical so I'm hesitant to stop accepting it.
However, if UNITS acts that way, then why is ISOTIME diff
Hello,
23.02.2023 23:24, Tomas Vondra wrote:
On 2/23/23 16:26, Tomas Vondra wrote:
Thanks for v30 with the updated commit messages. I've pushed 0001 after
fixing a comment typo and removing (I think) an unnecessary change in an
error message.
I'll give the buildfarm a bit of time before pushing
Hi Georgios,
11.03.2023 13:50, gkokola...@pm.me wrote:
I can not answer about the buildfarms. Do you think that adding an explicit
check for this warning in meson would help? I am a bit uncertain as I think
that type-limits are included in extra.
@@ -1748,6 +1748,7 @@ common_warning_flags = [
12.03.2023 10:18, Thomas Munro wrote:
And again:
TRAP: failed Assert("PMSignalState->PMChildFlags[slot] ==
PM_CHILD_ASSIGNED"), File: "../src/backend/storage/ipc/pmsigna...
https://cirrus-ci.com/task/6558324615806976
https://api.cirrus-ci.com/v1/artifact/task/6558324615806976/testrun/build/test
Hi,
14.03.2023 01:20, Andres Freund wrote:
I am yet to construct a reproduction of the case, but it seems to me that
the race condition is not impossible here.
I suspect the issue could be made much more likely by adding a sleep before
the pg_queue_signal(SIGCHLD) in pgwin32_deadchild_callback()
Hi,
15.03.2023 11:43, Thomas Munro wrote:
On Wed, Mar 15, 2023 at 9:00 PM Alexander Lakhin wrote:
The result depends on some OS conditions (it reproduced pretty well
immediately after VM reboot), but it's enough to test the patch proposed.
And I can confirm that the Assert is not obs
Hello,
13.03.2023 17:15, Andrew Dunstan wrote:
On 2022-12-02 Fr 09:11, Israel Barth Rubio wrote:
Hello all,
I'm submitting a new version of the patch. Instead of changing signature
of several functions in order to use the defaults parameter, it is now storing
that in the cstate structure, whic
16.03.2023 00:13, Thomas Munro wrote:
Thanks. We were wondering if the retry mechanism might somehow be
hiding this in non-assert builds, but, looking more closely, that is
tied specifically to the memory reservation operation.
As to hiding, when analyzing the Assert issue, I was wondered if
Hi,
18.03.2023 07:26, Tom Lane wrote:
Amit Kapila writes:
Peter Smith has recently reported a BF failure [1]. AFAICS, the call
stack of failure [2] is as follows:
Note the assertion report a few lines further up:
TRAP: failed Assert("pg_atomic_read_u32(&entry_ref->shared_entry->refcount) ==
Hello,
26.09.2022 17:46, Peter Eisentraut wrote:
On 22.09.22 23:21, Tom Lane wrote:
Anyway, this is a bit far afield from the stated topic of this
thread. I think we should commit something approximately like
what I posted and then start a new thread specifically about
what we'd like to do abo
Hello Thomas and Michael,
14.03.2024 06:16, Thomas Munro wrote:
Yeah, I was wondering if its checkpoint delaying logic might have
got the checkpointer jammed or something like that, but I don't
currently see how. Yeah, the replay of bulk newpages could be
relevant, but it's not exactly new tec
Hello Anton,
14.03.2024 23:36, Anton A. Melnikov wrote:
On 13.03.2024 10:41, Anton A. Melnikov wrote:
Here is a version updated for the current master.
During patch updating i mistakenly added double counting of deallocatated
blocks.
That's why the tests in the patch tester failed.
Fixed i
1 - 100 of 547 matches
Mail list logo
