On 08.01.24 16:06, Peter Eisentraut wrote:
On 08.01.24 15:04, Aleksander Alekseev wrote:
[...] so I quickly wrote some (wrong) instrumentation to try to test
your patch.
Yep, it confused me too at first.
Since the encoding happens right before exit() call, maybe it's worth
changing $b in-plac
On Fri, 2 Dec 2022 at 05:05, Kohei KaiGai wrote:
>
> > > IIUC, we already can use ctid in the where clause on the latest
> > > PostgreSQL, can't we?
> >
> > Oh, sorry, I missed the TidRangeScan. My apologies for the noise.
> >
> I made the ctidscan extension when we developed CustomScan API
> towa
On Tue, 15 Aug 2023 at 08:09, Peter Smith wrote:
>
> A rebase was needed due to a recent push [1].
I have changed the status of the patch to "Waiting on Author" as
Amit's queries at [1] have not been verified and concluded. Please
feel free to address them and change the status back again.
[1] -
Hi, Dmitry!
On Sat, Jan 13, 2024 at 7:33 PM Dmitry Koval wrote:
> Thank you, there is one small point left (in the comment): can you
> replace "guarantteed to be to be newer" to "guaranteed to be newer",
> file src/backend/storage/ipc/procarray.c?
Fixed. Thank you for catching this.
--
Reg
Hi Euler,
On Fri, Jan 12, 2024 at 6:16 AM Euler Taveira wrote:
>
> On Thu, Jan 11, 2024, at 9:18 AM, Hayato Kuroda (Fujitsu) wrote:
>
> I have been concerned that the patch has not been tested by cfbot due to the
> application error. Also, some comments were raised. Therefore, I created a
> patc
Hi!
I think this is a demanding and long-waited feature. The thread is
pretty long, but mostly it was disputes about how to save the errors.
The present patch includes basic infrastructure and ability to ignore
errors, thus it's pretty simple.
On Sat, Jan 13, 2024 at 4:20 PM jian he wrote:
> On
On Saturday, January 13, 2024, Nathan Bossart
wrote:
> On Sat, Jan 13, 2024 at 01:39:50PM +0300, Aleksander Alekseev wrote:
>
> > Should we remove --config-file from the error message to avoid any
> > confusion? Should we correct --help output? Should we update the
> > documentation?
>
> It might
On Thu, Jan 11, 2024 at 10:44 PM Peter Eisentraut wrote:
>
> On 31.12.23 09:51, Paul Jungwirth wrote:
> > On Wed, Dec 6, 2023 at 12:59 AM Peter Eisentraut
> > wrote:
> > >
> > > On 02.12.23 19:41, Paul Jungwirth wrote:
> > > > So what do you think of this idea instead?:
> > > >
> > > > We co
On Sat, Jan 13, 2024 at 01:39:50PM +0300, Aleksander Alekseev wrote:
> OK, let's check section "20.1.4. Parameter Interaction via the Shell"
> [1] of the documentation. Currently it doesn't tell anything about the
> ability to specify GUCs --like-this, unless I missed something.
It appears to be d
On Fri, Jan 12, 2024 at 01:45:55PM -0600, Nathan Bossart wrote:
> On Fri, Jan 12, 2024 at 11:13:46PM +0530, Abhijit Menon-Sen wrote:
>> At 2024-01-12 11:21:52 -0600, nathandboss...@gmail.com wrote:
>>> + Each backend sould obtain a pointer to the reserved shared memory by
>>
>> sould → should
Hi.
While there are plans to remove the sockets functions (Windows) [1], I
believe it is worth fixing possible current bugs.
In the pgwin32_socket function (src/backend/port/win32/socket.c), there is
a possible socket leak if the socket cannot be made non-blocking.
Trivial patch attached.
Best
On Sat, Jan 13, 2024 at 01:49:08PM +0300, Aleksander Alekseev wrote:
> That's much better, thanks.
>
> I think the patch could use another pair of eyes, ideally from a
> native English speaker. But if no one will express any objections for
> a while I suggest merging it.
Great. I've attached a v
I wrote:
> Xiaoran Wang writes:
>> Hmm, how about first checking if any invalidated shared messages have been
>> accepted, then rechecking the tuple's visibility?
>> If there is no invalidated shared message accepted during
>> 'toast_flatten_tuple',
>> there is no need to do then visibility check,
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.
Hi!
Thank you, there is one small point left (in the comment): can you
replace "guarantteed to be to be newer" to "guaranteed to be newer",
file src/backend/storage/ipc/procarray.c?
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On Fri, Jan 12, 2024 at 3:15 PM Cary Huang wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting it to
> a huge number without knowing the consequences.
>
> It is true that max_connections can increas
Xiaoran Wang writes:
> Hmm, how about first checking if any invalidated shared messages have been
> accepted, then rechecking the tuple's visibility?
> If there is no invalidated shared message accepted during
> 'toast_flatten_tuple',
> there is no need to do then visibility check, then it can sav
On 13/01/2024 4:51 pm, Tomas Vondra wrote:
On 1/12/24 20:30, Konstantin Knizhnik wrote:
On 12/01/2024 7:03 pm, Tomas Vondra wrote:
On 10/21/23 14:16, Konstantin Knizhnik wrote:
Hi hackers,
EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS,
COST,...) which help to provide useful
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
On Fri, 5 Jan 2024 at 10:49, Peter Smith wrote:
>
> Here are some review comments for patch v1-0001.
>
> ==
> doc/src/sgml/ref/pgupgrade.sgml
>
> 1. GENERAL - blank lines
>
> Most (but not all) of your procedure steps are preceded by blank lines
> to make them more readable in the SGML. Add th
I intended to look into this part of the code more, but the tests show a
> difference between PostgreSQL v.15 and v.16, which causes changes in the
> code of this feature.
Makes sense. I've incorporated your changes into the patchset.
--
Regards,
Alexander Korotkov
0001-Gener
On 1/12/24 20:30, Konstantin Knizhnik wrote:
>
> On 12/01/2024 7:03 pm, Tomas Vondra wrote:
>> On 10/21/23 14:16, Konstantin Knizhnik wrote:
>>> Hi hackers,
>>>
>>> EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS,
>>> COST,...) which help to provide useful details of query execut
On Thu, 2 Nov 2023 at 10:52, Anthonin Bonnefoy
wrote:
> The main goal is to provide more ways to test extended protocol in
> regression tests
> similarly to what \bind is doing.
I think this is a great addition. One thing that I think should be
added for completeness though is the ability to deal
Em ter., 9 de jan. de 2024 às 06:31, John Naylor
escreveu:
> On Thu, Dec 28, 2023 at 7:58 PM Ranier Vilela wrote:
> > I think it would be more productive to initialize the entire array with
> -1, and avoid flagging, one by one, the items that should be -1.
>
> This just moves an operation from o
On Fri, Jan 12, 2024 at 10:59 AM torikoshia wrote:
>
>
> Thanks for reviewing!
>
> Updated the patch merging your suggestions except below points:
>
> > + cstate->num_errors = 0;
>
> Since cstate is already initialized in below lines, this may be
> redundant.
>
> | /* Allocate workspace and
> On Mon, Jan 08, 2024 at 05:10:20PM +0100, Dmitry Dolgov wrote:
> > On Sat, Jan 06, 2024 at 09:04:54PM +0530, vignesh C wrote:
> >
> > CFBot shows documentation build has failed at [1] with:
> > [07:44:55.531] time make -s -j${BUILD_JOBS} -C doc
> > [07:44:57.987] postgres.sgml:572: element xref:
On Fri, 5 Jan 2024 at 09:08, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Vignesh,
>
> Thanks for making a patch! Below part is my comments.
>
> 1.
> Only two steps were added an id, but I think it should be for all the steps.
> See [1].
I have added wherever it is required as of now.
> 2.
> I'm not
Hello all,
Currently PostgreSQL doesn't support data change delta tables. For example, it
doesn't support this type of query:
SELECT * FROM NEW TABLE (
INSERT INTO phone_book
VALUES ( 'Peter Doe', '555-2323' )
) AS t
PostgreSQL has RETURNING that provides only a subset of this function
On Sat, Jan 13, 2024 at 2:02 AM Jeff Davis wrote:
>
> On Tue, 2023-10-17 at 14:17 +0530, Amit Kapila wrote:
> > > Fair enough. I'll wait till early next week (say till Monday EOD)
> > > to
> > > see if anyone thinks otherwise and push this patch to HEAD after
> > > some
> > > more testing and revi
On Fri, Jan 12, 2024 at 3:36 PM Bharath Rupireddy
wrote:
>
> On Fri, Jan 12, 2024 at 9:28 AM Amit Kapila wrote:
> >
> > On Thu, Jan 11, 2024 at 10:03 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Thu, Jan 11, 2024 at 4:35 PM vignesh C wrote:
> > > >
> > > > On further analysis, it was found th
On Fri, Jan 12, 2024 at 12:02 PM Hayato Kuroda (Fujitsu)
wrote:
>
> I didn't review all items but ...
>
> 1.
> An option --port was added to control the port number for physical standby.
> Users can specify a port number via the option, or an environment variable
> PGSUBPORT.
> If not specified,
Hi,
Thanks for the updated patch.
> > I see what you mean, but I don't think the problem is the word "each." I
> > think the problem is the use of passive voice. What do you think about
> > something like
> >
> > Each backend will execute the registered shmem_startup_hook shortly
> >
Hi,
A friend of mine complained about strange behavior of `postgres`. When
executed without any arguments the following error is shown:
```
$ postgres
postgres does not know where to find the server configuration file.
You must specify the --config-file or -D invocation option or set the
PGDATA e
On 11/1/2024 18:30, Alexander Korotkov wrote:
Hi!
On Tue, Jan 9, 2024 at 1:14 PM Pavel Borisov wrote:
Hmm, I don't see this old code in these patches. Resend 0002-* because
of trailing spaces.
AFAIK, cfbot does not seek old versions of patchset parts in previous messages.
So for it to run
Hmm, how about first checking if any invalidated shared messages have been
accepted, then rechecking the tuple's visibility?
If there is no invalidated shared message accepted during
'toast_flatten_tuple',
there is no need to do then visibility check, then it can save several
CPU cycles.
i
Hi,
On Fri, Jan 12, 2024 at 04:13:27PM +0100, Jelte Fennema-Nio wrote:
> But I'm not sure that such a pg_manage_extensions role would have any
> fewer permissions than superuser in practice.
Note that just being able to create an extension does not give blanket
permission to use it. I did a few
36 matches
Mail list logo
