On Sat, Jan 15, 2022 at 12:46 AM Bossart, Nathan wrote:
>
> On 1/14/22, 3:43 AM, "Maxim Orlov" wrote:
> > The code seems to be in good condition. All the tests are running ok with
> > no errors.
>
> Thanks for your review.
>
> > I like the whole idea of shifting additional checkpointer jobs as
> 15 янв. 2022 г., в 03:20, Shawn Debnath написал(а):
>
> On Fri, Jan 14, 2022 at 05:28:38PM +0800, Julien Rouhaud wrote:
>>> PFA rebase of the patchset. Also I've added a patch to combine
>>> page_number, page_status, and page_dirty together to touch less
>>> cachelines.
>>
>> The cfbot
I tried to pg_upgrade from a v13 instance like:
time make check -C src/bin/pg_upgrade oldsrc=`pwd`/13
oldbindir=`pwd`/13/tmp_install/usr/local/pgsql/bin
I had compiled and installed v13 into `pwd`/13.
First, test.sh failed, because of an option in initdb which doesn't exist in
the old version:
Hi,
On Tue, Jan 11, 2022 at 11:05:26AM +0100, Ronan Dunklau wrote:
>
> Done, and I added anoher commit per your suggestion to add this comment.
The cfbot reports that the patchset doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3293.log
=== Applying patches on top of PostgreSQL commit
Hi,
On Mon, Jan 10, 2022 at 09:46:23AM +0530, Amul Sul wrote:
>
> Thanks for the note, I can see the same test is failing on my centos
> vm too with the latest master head(376ce3e404b). The failing reason is
> the "recovery_target_inclusive = off" setting which is unnecessary for
> this test,
Hi,
On Sat, Nov 20, 2021 at 05:51:16PM -0800, Paul A Jungwirth wrote:
>
> Here are updated patches. They are rebased and clean up some of my TODOs.
The cfbot reports that the patchset doesn't apply anymore:
http://cfbot.cputube.org/patch_36_2048.log
=== Applying patches on top of PostgreSQL
Hi,
On Tue, Jan 11, 2022 at 04:14:25PM +0900, Michael Paquier wrote:
> The CF bot is unhappy, so here is a rebase, with some typo fixes
> reported by Justin offlist.
The cfbot still complains about this patch on Windows:
https://cirrus-ci.com/task/6411385683836928
Hi,
On Fri, Dec 17, 2021 at 01:03:06PM +0530, Shruthi Gowda wrote:
>
> I have updated the DBOID preserve patch to handle this case and
> generated the latest patch on top of your v7-001-preserve-relfilenode
> patch.
The cfbot reports that the patch doesn't apply anymore:
On Sat, Jan 15, 2022 at 12:13:39AM -0500, Tom Lane wrote:
>
> The discussion just upthread was envisioning not only that we'd add
> infrastructure for this, but then that other projects would build
> more infrastructure on top of that. That's an awful lot of work
> that will become useless ---
Julien Rouhaud writes:
> On Fri, Jan 14, 2022 at 07:42:29PM +, Bossart, Nathan wrote:
>> On 1/14/22, 8:26 AM, "Tom Lane" wrote:
>>> It feels to me like far too much effort is being invested in fundamentally
>>> the wrong direction here.
> Agreed, it would be better but if that leads to
On 2022/01/12 1:07, Tomas Vondra wrote:
I explored the idea of using page LSN a bit
Many thanks!
The patch from 22/12 simply checks if the change should/would wait for
sync replica, and if yes it WAL-logs the sequence increment. There's a
couple problems with this, unfortunately:
Yes,
On Mon, Dec 13, 2021 at 09:40:09PM +0100, Tomas Vondra wrote:
> 1) If the table is a separate relation (not part of an inheritance
> tree), this should make no difference. -> OK
>
> 2) If the table is using "old" inheritance, this reverts back to
> pre-regression behavior. So people will keep
Hi,
On Wed, Dec 15, 2021 at 11:10:14PM +0100, Daniel Gustafsson wrote:
>
> I've attached a v50 which fixes the issues found by Joshua upthread, as well
> as
> rebases on top of all the recent SSL and pgcrypto changes.
The cfbot reports that the patchset doesn't apply anymore:
Hi,
On Wed, Dec 08, 2021 at 04:39:11PM +, Simon Riggs wrote:
>
> This patch shows where I'm going, with changes in GetSnapshotData()
> and XidInMVCCSnapshot() and XactLockTableWait().
> Passes make check, but needs much more, so this is review-only at this
> stage to give a flavour of what
On Fri, Jan 14, 2022 at 07:42:29PM +, Bossart, Nathan wrote:
> On 1/14/22, 8:26 AM, "Tom Lane" wrote:
> >
> > It feels to me like far too much effort is being invested in fundamentally
> > the wrong direction here. If the subxact overflow business is causing
> > real-world performance
On Fri, Jan 14, 2022 at 7:08 PM Alvaro Herrera wrote:
>
> On 2022-Jan-14, Amit Kapila wrote:
>
> > 1. Replica Identity handling: Currently the column filter patch gives
> > an error during create/alter subscription if the specified column list
> > is invalid (Replica Identity columns are
On Thu, Jan 6, 2022 at 10:21 AM Peter Geoghegan wrote:
> The patch bitrot again, so attached is a rebased version, v3.
I pushed a version of this patch earlier. This final version didn't go
quite as far as v3 did: it retained a few VACUUM VERBOSE only INFO
messages (it didn't demote them to
On Fri, Jan 14, 2022 at 04:53:12PM -0500, Robert Haas wrote:
> On Thu, Jan 13, 2022 at 10:23 PM Michael Paquier wrote:
>> Using --compression-level=NUMBER and --server-compress=METHOD to
>> specify a server-side compression method with a level is fine by me,
>> but I find the reuse of --compress
Hi,
On 2022-01-15 13:19:42 +1300, Thomas Munro wrote:
> On Sat, Jan 15, 2022 at 11:44 AM Andres Freund wrote:
> > > The patch Alexander tested most recently uses a tri-state eof flag [...]
> >
> > What about instead giving WalReceiverConn an internal WaitEventSet, and
> > using
> > that
I'd recently been thinking about monitoring how many bytes behind a
logical slot was and realized that's not really possible to compute
currently. That's easy enough with a physical slot because we can get
the current WAL LSN easily enough and the slot exposes the current LSN
positions of the
On Sat, Jan 15, 2022 at 9:47 AM Andres Freund wrote:
> Walreceiver only started using WES in
> 2016-03-29 [314cbfc5d] Add new replication mode synchronous_commit =
> 'remote_ap
>
> With that came the following comment:
>
> /*
> * Ideally we would reuse a
On Sat, Jan 15, 2022 at 11:44 AM Andres Freund wrote:
> > The patch Alexander tested most recently uses a tri-state eof flag [...]
>
> What about instead giving WalReceiverConn an internal WaitEventSet, and using
> that consistently? I've attached a draft for that.
>
> Alexander, could you test
On Fri, Jan 14, 2022 at 03:34:11PM -0800, Andres Freund wrote:
> Hi,
>
> On 2022-01-13 15:27:40 -0500, Andrew Dunstan wrote:
> > I can probably adjust to whatever we decide to do. But I think we're
> > really just tinkering at the edges here. What I think we really need is
> > the moral
Hi,
On 2022-01-15 02:32:35 +1300, Thomas Munro wrote:
> 1. The way I invoke pg_regress doesn't seem to work correctly under
> the build farm client (though it works fine under make), not sure why
> yet, but reproduced here and will figure it out tomorrow.
I think it's just a problem of the
Hi,
On 2022-01-13 15:27:40 -0500, Andrew Dunstan wrote:
> I can probably adjust to whatever we decide to do. But I think we're
> really just tinkering at the edges here. What I think we really need is
> the moral equivalent of `make check-world` in one invocation of
> vcregress.pl.
I agree
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 record, after
Thomas Munro writes:
> (That patch is assuming that we're looking for something simple to
> back-patch, in the event that we decide not to just revert the
> graceful shutdown patch from back branches. Reverting might be a
> better idea for now, and then we could fix all this stuff going
>
I wrote:
> Oh ... experimenting on macOS (with the system-provided libedit)
> shows no bug here. So I guess we'll need to make this conditional
> somehow, perhaps on USE_FILENAME_QUOTING_FUNCTIONS. That's another
> reason for not going overboard.
After further fooling with that, I concluded
Hi,
On 2022-01-15 10:59:00 +1300, Thomas Munro wrote:
> On Sat, Jan 15, 2022 at 9:28 AM Andres Freund wrote:
> > I think it doesn't even need to touch socket.c to cause breakage. Using two
> > different WaitEventSets is enough.
>
> Right. I was interested in your observation because so far we'd
On Sat, Jan 15, 2022 at 10:59 AM Thomas Munro wrote:
> (That patch is assuming that we're looking for something simple to
> back-patch, in the event that we decide not to just revert the
> graceful shutdown patch from back branches. Reverting might be a
> better idea for now, and then we could
On Sat, Jan 15, 2022 at 9:28 AM Andres Freund wrote:
> I think it doesn't even need to touch socket.c to cause breakage. Using two
> different WaitEventSets is enough.
Right. I was interested in your observation because so far we'd
*only* been considering the two-consecutive-WaitEventSets case,
On Thu, Jan 13, 2022 at 10:23 PM Michael Paquier wrote:
> Using --compression-level=NUMBER and --server-compress=METHOD to
> specify a server-side compression method with a level is fine by me,
> but I find the reuse of --compress to specify a compression method
> confusing as it maps with the
Hi,
On 2022-01-14 12:28:48 -0800, Andres Freund wrote:
> But once all the data is read, walsender.c will do another
> WaitLatchOrSocket(), which does WSAEventSelect(), clearing the "internal event
> record" and loosing the FD_CLOSE.
Walreceiver only started using WES in
2016-03-29 [314cbfc5d]
Hi,
On 2022-01-14 20:31:22 +1300, Thomas Munro wrote:
> Andres and I chatted about this stuff off list and he pointed out
> something else about the wrappers in socket.c: there are more paths in
> there that work with socket events, which means more ways to lose the
> precious FD_CLOSE event.
I
On 1/14/22, 8:26 AM, "Tom Lane" wrote:
> Julien Rouhaud writes:
>> Like many I previously had to investigate a slowdown due to sub-transaction
>> overflow, and even with the information available in a monitoring view (I had
>> to rely on a quick hackish extension as I couldn't patch postgres)
>
> We intend to do the following work on the patch soon:
> 1. Write a detailed README
> 2. Split the patch into several pieces including a separate part for
> XID_FMT. But if committers meanwhile choose to commit Jim's XID_FMT patch
> we also appreciate this and will rebase our patch accordingly.
On Mon, Nov 15, 2021 at 10:01 AM Robert Haas wrote:
>
> On Wed, Nov 3, 2021 at 1:34 PM James Coleman wrote:
> > As I understand the current code, parallel plans are largely chosen
> > based not on where it's safe to insert a Gather node but rather by
> > determining if a given path is parallel
On 1/14/22, 3:43 AM, "Maxim Orlov" wrote:
> The code seems to be in good condition. All the tests are running ok with no
> errors.
Thanks for your review.
> I like the whole idea of shifting additional checkpointer jobs as much as
> possible to another worker. In my view, it is more
On Fri, Dec 3, 2021 at 2:35 AM Michael Paquier wrote:
>
> On Mon, Nov 15, 2021 at 10:01:37AM -0500, Robert Haas wrote:
> > On Wed, Nov 3, 2021 at 1:34 PM James Coleman wrote:
> >> As I understand the current code, parallel plans are largely chosen
> >> based not on where it's safe to insert a
I'd like to ask your opinion for next small questions
1) May be, we could add toasteroid to pg_type to for default toaster for
datatype. ALTER TYPE type SET DEFAULT TOASTER toaster;
2) The name of default toaster is deftoaster, which was choosen at
night, may be heap_toaster is better? heap
In my understanding, we want to be able to
1. Access data from a toasted object one slice at a time, by using
knowledge of the structure
2. If toasted data is updated, then update a minimum number of
slices(s), without rewriting the existing slices
3. If toasted data is expanded, then allownew
Hi
I like this feature, but I don't like the introduction of double + too
much. I think it is confusing.
Is it really necessary? Cannot be enough just reorganization of \dn and
\dn+.
Regards
Pavel
pá 14. 1. 2022 v 17:35 odesílatel Justin Pryzby
napsal:
> Rebased before Julian asks.
>
Rebased before Julian asks.
>From cf57143c85a2a6088fe6038e6d41771fd60aae34 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subject: [PATCH 1/4] Add pg_am_size(), pg_namespace_size() ..
See also: 358a897fa, 528ac10c7
---
src/backend/utils/adt/dbsize.c | 130
Julien Rouhaud writes:
> Like many I previously had to investigate a slowdown due to sub-transaction
> overflow, and even with the information available in a monitoring view (I had
> to rely on a quick hackish extension as I couldn't patch postgres) it's not
> terribly fun to do this way. On top
I see a CF entry has been created already, and the cfbot doesn't like
my PoC. To prevent confusion, I've taken the liberty of switching the
author to myself and set to Waiting on Author. FWIW, my local build
passed make check-world after applying Justin's fix and changing a
couple other things.
On Fri, Jan 14, 2022 at 1:17 PM Julien Rouhaud wrote:
> On Thu, Jan 13, 2022 at 10:27:31PM +, Bossart, Nathan wrote:
> > Thanks for the new patch!
> >
> > +
> > +Returns a record of information about the backend's
> subtransactions.
> > +The fields returned are
On Friday, January 14, 2022, Tomas Vondra
wrote:
> ,
>
> On 1/14/22 00:02, Petar Dambovaliev wrote:
>
>>
>> the error code is `-1` and the error text is `invalid ordering of
>> speculative insertion changes`
>>
>
> Which Postgres version is this, exactly? Was the WAL generated by that
> same
Hello,
On Sun, 2022-01-02 at 13:28 -0800, Andres Freund wrote:
> Hi,
>
> This fails with an assertion failure:
> https://cirrus-ci.com/task/5567540742062080?logs=cores#L55
>
>
Andres, thank you for your test! I've missed it. Fixed in attached
patch v5.
On Wed, 2021-12-22 at 04:25 +0300, Anton
if it takes little work for you, can you please send me a piece of code
with the change needed to do the test
Thanks
Regards,
Fabrice
On Fri, Jan 14, 2022 at 1:03 PM Amit Kapila wrote:
> On Fri, Jan 14, 2022 at 3:47 PM Fabrice Chapuis
> wrote:
> >
> > If I can follow you, I have to make the
> On 14. Jan 2022, at 13:21, Peter Eisentraut
> wrote:
>
> There is nothing in there that says that certain branches of the UNION in a
> recursive query mean certain things. In fact, it doesn't even require the
> query to contain a UNION at all. It just says to iterate on evaluating the
Resending some language fixes to the public documentation.
>From 28b8532976ddb3e8b617ca007fae6b4822b36527 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 13 Nov 2021 12:11:46 -0600
Subject: [PATCH] f!typos
---
doc/src/sgml/mvcc.sgml | 8 ++---
Thanks for the comments.
> > The conditions under which B-M-H can be used are as follows.
> >
> > (1) B-M-H in LIKE search supports only single-byte character sets and
UTF8.
> > Multibyte character sets does not support, because it may contain
another
> > characters in the byte sequence. For
On Fri, Jan 14, 2022 at 8:55 AM Bharath Rupireddy
wrote:
>
> The function CreateCheckPoint is specified as CreateCheckpoint in some
> of the code comments whereas in other places it is correctly
> mentioned. Attaching a tiny patch to use CreateCheckPoint consistently
> across code comments.
>
Hi,
On 1/14/22 00:02, Petar Dambovaliev wrote:
Hello,
I am using the libpq to consume a replication slot.
Very rarely, i would get a very strange error that i can't find any
information on.
It is not mentioned in any documentation and i don't know under what
conditions it triggers.
Any help
On Thu, Jan 6, 2022 at 3:45 PM Amul Sul wrote:
> Here are few comments for v1 patch:
Thanks Amul. I'm thinking about Robert's latest comments addressing
which may need some rethinking of this whole design, but I decided to
post a v2 taking care of your comments.
> + /* Caller error if we get
On 2022-Jan-14, Amit Kapila wrote:
> 1. Replica Identity handling: Currently the column filter patch gives
> an error during create/alter subscription if the specified column list
> is invalid (Replica Identity columns are missing). It also gives an
> error if the user tries to change the replica
On Sat, Jan 15, 2022 at 12:39 AM Thomas Munro wrote:
> On Wed, Dec 22, 2021 at 11:41 AM Thomas Munro wrote:
> > Rebased and updated based on feedback. Responses to multiple emails below:
>
> Pushed, but the build farm doesn't like it with a couple of different
> ways of failing. I'll collect
On Thu, Jan 13, 2022 at 11:50 AM Bharath Rupireddy
wrote:
> Thanks. IMO, the following format of logging is better, so attaching
> the v2-0001-Add-checkpoint-and-redo-LSN-to-LogCheckpointEnd-l.patch as
> .patch
>
> 2021-12-28 02:52:24.464 UTC [2394396] LOG: checkpoint completed at
>
On Friday, January 14, 2022 7:52 PM Amit Kapila wrote:
>
> On Wed, Jan 12, 2022 at 2:40 AM Justin Pryzby wrote:
> >
> > Is there any coordination between the "column filter" patch and the "row
> > filter" patch ? Are they both on track for PG15 ? Has anybody run them
> > together ?
> >
>
>
Hello all,
I've just read this thread as I googled for "*how to give to autovacuum
priority on a table*"
I'm looking this because I have large table with lot of inserts/updates,
and to improve the system I want to force the first free autovacuum worker
to work on that table, of course if
On 11.01.22 12:33, Denis Hirn wrote:
I have been studying this a bit more. I don't understand your argument here.
Why would this query have different semantics than, say
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
VALUES (2)
UNION ALL
SELECT n+1 FROM t WHERE n <
Hi,
On Mon, Nov 15, 2021 at 04:01:51PM +0300, Alexander Pyhalov wrote:
>
> I've updated patch - removed catversion dump.
This version of the patchset doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3369.log
=== Applying patches on top of PostgreSQL commit ID
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)
Hi,
On Thu, Sep 09, 2021 at 02:12:08AM +, houzj.f...@fujitsu.com wrote:
>
> Attach new version patch set which remove the workaround patch.
This version of the patchset doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3143.log
=== Applying patches on top of PostgreSQL commit ID
On Fri, Jan 14, 2022 at 7:49 AM Masahiko Sawada wrote:
>
> On Wed, Jan 12, 2022 at 11:10 PM vignesh C wrote:
> >
> > On Wed, Jan 12, 2022 at 11:32 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jan 12, 2022 at 12:21 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Jan 12, 2022 at 5:49
On Fri, Jan 14, 2022 at 3:47 PM Fabrice Chapuis wrote:
>
> If I can follow you, I have to make the following changes:
>
No, not like that but we can try that way as well to see if that helps
to avoid your problem. Am, I understanding correctly even after
modification, you are seeing the problem.
On Wed, Jan 12, 2022 at 2:40 AM Justin Pryzby wrote:
>
> Is there any coordination between the "column filter" patch and the "row
> filter" patch ? Are they both on track for PG15 ? Has anybody run them
> together ?
>
The few things where I think we might need to define some common
behavior
The code seems to be in good condition. All the tests are running ok with
no errors.
I like the whole idea of shifting additional checkpointer jobs as much
as possible to another worker. In my view, it is more appropriate to call
this worker "bg cleaner" or "bg file cleaner" or smth.
It could be
On Wed, Dec 22, 2021 at 11:41 AM Thomas Munro wrote:
> Rebased and updated based on feedback. Responses to multiple emails below:
Pushed, but the build farm doesn't like it with a couple of different
ways of failing. I'll collect some results and revert shortly.
pá 14. 1. 2022 v 11:49 odesílatel Marcos Pegoraro
napsal:
> For example, if I define a variable called "relkind", then psql's \sv
>> meta-command is broken because the query it performs can't distinguish
>> between the column and the variable.
>>
>> If variables use : as prefix you´ll never have
Hi,
On Fri, Jan 14, 2022 at 07:49:09AM -0300, Marcos Pegoraro wrote:
> >
> > For example, if I define a variable called "relkind", then psql's \sv
> > meta-command is broken because the query it performs can't distinguish
> > between the column and the variable.
> >
> If variables use : as prefix
>
> For example, if I define a variable called "relkind", then psql's \sv
> meta-command is broken because the query it performs can't distinguish
> between the column and the variable.
>
> If variables use : as prefix you´ll never have these conflicts.
select relkind from pg_class where relkind
On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
wrote:
>
> On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> > The Attached v15 patch has the fixes for the same.
>
> Thanks. The v15 patch LGTM and the cf bot is happy hence marking it as RfC.
The patch was not applying because of the recent
Op 13-01-2022 om 13:43 schreef Alvaro Herrera:
Apologies, there was a merge failure and I failed to notice. Here's the
correct patch.
(This is also in github.com/alvherre/postgres/tree/merge-15)
[v6-0001-MERGE-SQL-Command-following-SQL-2016]
I read though the MERGE-docs; some typos:
If I can follow you, I have to make the following changes:
1. In walsender.c:
static void
WalSndUpdateProgress(LogicalDecodingContext *ctx, XLogRecPtr lsn,
TransactionId xid)
{
static TimestampTz sendTime = 0;
TimestampTz now = GetCurrentTimestamp();
/* Keep the worker process alive */
Hello,
I am using the libpq to consume a replication slot.
Very rarely, i would get a very strange error that i can't find any
information on.
It is not mentioned in any documentation and i don't know under what
conditions it triggers.
Any help is appreciated.
The function i am calling is :
Hi,
On Wed, Sep 08, 2021 at 07:38:25AM +, shinya11.k...@nttdata.com wrote:
> >Thanks for letting me know, I've attached a rebased v4 of this patch, no
> >other
> >changes.
> I tried it, but when I used set command, tab completion did not work properly
> and an error occurred.
Also, the
On 02.12.2021 22:31, Tom Lane wrote:
I'll push the close-only change in a little bit.
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
Hi,
The cfbot reports some clang warning on the last version of the patchset:
https://cirrus-ci.com/task/6721617647632384
[16:35:24.444] partprune.c:2775:8: error: explicitly assigning value of
variable of type 'int' to itself [-Werror,-Wself-assign]
[16:35:24.444] off
Hi,
On Sun, Dec 26, 2021 at 03:09:59PM +0500, Andrey Borodin wrote:
>
>
> PFA rebase of the patchset. Also I've added a patch to combine page_number,
> page_status, and page_dirty together to touch less cachelines.
The cfbot reports some errors on the latest version of the patch:
Op 13-01-2022 om 13:43 schreef Alvaro Herrera:
Apologies, there was a merge failure and I failed to notice. Here's the
correct patch.
(This is also in github.com/alvherre/postgres/tree/merge-15)
[20220113/v6-0001-MERGE-SQL-Command-following-SQL-2016.patch]
Good morning,
I got into this
pá 14. 1. 2022 v 3:44 odesílatel Julien Rouhaud napsal:
> Hi,
>
> On Thu, Jan 13, 2022 at 07:32:26PM +0100, Pavel Stehule wrote:
> > čt 13. 1. 2022 v 19:23 odesílatel Dean Rasheed >
> > napsal:
> >
> > > On Thu, 13 Jan 2022 at 17:42, Pavel Stehule
> > > wrote:
> > > >
> > > > I like the idea
Hello,
There are some places in the pg_state_statement's regress test where the
bool result of comparison between the number of rows obtained and
wal_records generated by query should be displayed.
Now counting the number of wal_records for some query in
pg_state_statement is done by the
Hi,
On Fri, Jan 14, 2022 at 08:55:26AM +0100, Dmitry Dolgov wrote:
>
> FYI, I've attached this thread to the CF item as an informational one,
> but as there are some patches posted here, folks may get confused. For
> those who have landed here with no context, I feel obliged to mention
> that
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
85 matches
Mail list logo
