On Fri, 29 Dec 2023 at 19:38, Tom Lane wrote:
> > 2. It paves the way for GUCs that can only be set using a protocol
> > message (and not using SET).
>
> This is assuming facts not in evidence.
How about instead of talking about protocol-only GUCs (which are
indeed currently a theoretical
On Fri, 29 Dec 2023 at 19:38, Tom Lane wrote:
>> Jelte Fennema-Nio writes:
> > 1. Protocol messages are much easier to inspect for connection poolers
> > than queries
>
> Unless you somehow forbid clients from setting GUCs in the old way,
> exactly how will that help a pooler?
A co-operating
On Tue, 2023-09-05 at 12:08 -0700, Jeff Davis wrote:
> OK, so we could have a built-in FDW called pg_connection that would
> do
> the right kinds of validation; and then also allow other FDWs but the
> subscription would have to do its own validation.
Attached a rough rebased version implementing
On Fri, 29 Dec 2023 at 19:32, Jeff Davis wrote:
> On Fri, 2023-12-29 at 18:29 +0100, Jelte Fennema-Nio wrote:
> > There's definitely still some more work that needs to be done
> > (docs for new libpq APIs, protocol version bump, working protocol
> > version negotiation).
>
> That is my biggest
On 12/29/23 17:27, Corey Huinker wrote:
> But maybe it's enough to just do what you did - if we get an MCELEM
> slot, can it ever contain anything else than array of elements of the
> attribute array type? I'd bet that'd cause all sorts of issues, no?
>
>
> Thanks for the explanation
On Thu, 2023-12-28 at 22:00 +0300, Alexander Lakhin wrote:
> But looking at the result with the comment above that "do" block, I
> wonder
> whether this successful CREATE COLLATION command is so important to
> perform
> it that tricky way, if we want to demonstrate that nondeterministic
>
Jeff Davis writes:
> On Fri, 2023-12-29 at 13:38 -0500, Tom Lane wrote:
>> This is assuming facts not in evidence. Why would we want such a
>> thing?
> The problem came up during the binary_formats GUC discussion: it
> doesn't really make sense to change that with a SQL query, and doing so
>
On 22.12.23 22:33, Peter Eisentraut wrote:
On 12.09.23 07:42, Peter Eisentraut wrote:
On 10.08.23 07:58, Peter Eisentraut wrote:
There are also a couple of issues in the MSVC legacy build system
that would need to be tightened up in order to survive with fatal
Perl warnings. Obviously, there
On Fri, 2023-12-29 at 13:38 -0500, Tom Lane wrote:
> > 2. It paves the way for GUCs that can only be set using a protocol
> > message (and not using SET).
>
> This is assuming facts not in evidence. Why would we want such a
> thing?
The problem came up during the binary_formats GUC discussion:
On Thu, 2023-06-15 at 15:08 -0400, Joe Conway wrote:
> > I haven't studied the details yet but +1 for this idea. It models
> > what we are actually doing.
>
> +1 agreed
I am combining this discussion with my "built-in CTYPE provider"
proposal here:
Jelte Fennema-Nio writes:
> Currently the only way to set GUCs from a client is by using SET
> commands or set them in the StartupMessage. I think it would be very
> useful to be able to change settings using a message at the protocol
> level. For the following reasons:
> 1. Protocol messages
On Fri, 2023-12-29 at 18:29 +0100, Jelte Fennema-Nio wrote:
> 2. It paves the way for GUCs that can only be set using a protocol
> message (and not using SET).
That sounds useful for GUCs that can interfere with the client, such as
client_encoding or the proposed GUC in you referred to at [1].
>
Heikki Linnakangas writes:
> On 29/12/2023 01:42, Tom Lane wrote:
>> I didn't stop to trace the details but I'm pretty sure this is why
>> you're getting the bogus extra projections shown in the 0005 patch.
> They're not bogus. With the patches, projecting away the junk columns is
> visible in
Hi
pá 29. 12. 2023 v 18:29 odesílatel Jelte Fennema-Nio napsal:
> Currently the only way to set GUCs from a client is by using SET
> commands or set them in the StartupMessage. I think it would be very
> useful to be able to change settings using a message at the protocol
> level. For the
I wrote:
> Hao Zhang writes:
>> IMHO, there are other error reports in the function
>> BeginInternalSubTransaction(), like
> Sure, but all the other ones are extremely hard to hit, which is why
> we didn't bother to worry about them to begin with. If we want to
> make this more formally
On Wed, Dec 27, 2023 at 10:52:15PM +0100, Peter Eisentraut wrote:
> On 27.12.23 02:04, Bruce Momjian wrote:
> > I did_not_ change the user API, so CREATE/ALTER ROLE still uses
> > [ENCRYPTED] PASSWORD, the GUC is still called password_encryption, and
> > the libpq function is still called
On 29/12/2023 01:42, Tom Lane wrote:
I wrote:
Yeah, fair point. I'll try to take a look at your patchset after
the holidays.
I spent some time looking at this patch, and I'm not very pleased
with it. My basic complaint is that this is a band-aid that only
touches things at a surface level,
Currently the only way to set GUCs from a client is by using SET
commands or set them in the StartupMessage. I think it would be very
useful to be able to change settings using a message at the protocol
level. For the following reasons:
1. Protocol messages are much easier to inspect for
Em sex., 29 de dez. de 2023 às 08:53, Ranier Vilela
escreveu:
> Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra <
> tomas.von...@enterprisedb.com> escreveu:
>
>>
>>
>> On 12/27/23 12:37, Ranier Vilela wrote:
>> > Em ter., 26 de dez. de 2023 às 19:07, Tomas Vondra
>> >
>
> But maybe it's enough to just do what you did - if we get an MCELEM
> slot, can it ever contain anything else than array of elements of the
> attribute array type? I'd bet that'd cause all sorts of issues, no?
>
>
Thanks for the explanation of why it wasn't working for me. Knowing that
the
On Fri, 29 Dec 2023 at 11:02, Andrey M. Borodin wrote:
> This patchset allows sending CompressionMethod message, which allows to set
> another codec\level picked from the set of negotiated codec sets (during
> startup).
Did you mean to attach a patchset? I don't see the CompressionMethod
On Wed, Dec 20, 2023 at 9:33 PM Nathan Bossart wrote:
>
> On Wed, Dec 20, 2023 at 03:28:38PM +0530, Bharath Rupireddy wrote:
> > Isn't the worker_spi best place to show the use of the DSM registry
> > instead of a separate test extension? Note the custom wait event
> > feature that added its
Hi,
This idea first came from remove_useless_groupby_columns does not need to
record constraint dependencie[0] which points out that
unique index whose columns all have NOT NULL constraints could also take the
work with primary key when removing useless GROUP BY columns.
I study it and
On 12/29/23 14:53, Ranier Vilela wrote:
>
>
> Em sex., 29 de dez. de 2023 às 10:33, Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> escreveu:
>
>
>
> On 12/29/23 12:53, Ranier Vilela wrote:
> > Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra
> >
Em sex., 29 de dez. de 2023 às 10:33, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 12/29/23 12:53, Ranier Vilela wrote:
> > Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > escreveu:
> >
> >
> >
> > On 12/27/23 12:37, Ranier
On Fri, 29 Dec 2023, 13:49 Maxim Orlov, wrote:
> Hi!
>
> As were discussed in [0] our overall goal is to make Postgres 64 bit
> XIDs. It's obvious, that such a big patch set
> couldn't possible to commit "at once". SLUR patch set [1] was committed a
> short while ago as a first significant
>
On 12/29/23 12:53, Ranier Vilela wrote:
> Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> escreveu:
>
>
>
> On 12/27/23 12:37, Ranier Vilela wrote:
> > Em ter., 26 de dez. de 2023 às 19:07, Tomas Vondra
> >
Hi!
Recently, one of our customers came to us with the question: why do reindex
utility does not support multiple jobs for indices (-i opt)?
And, of course, it is because we cannot control the concurrent processing
of multiple indexes on the same relation. This was
discussed somewhere in [0], I
Hi!
As were discussed in [0] our overall goal is to make Postgres 64 bit XIDs.
It's obvious, that such a big patch set
couldn't possible to commit "at once". SLUR patch set [1] was committed a
short while ago as a first significant
step in this direction.
This thread is a next step in this
Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 12/27/23 12:37, Ranier Vilela wrote:
> > Em ter., 26 de dez. de 2023 às 19:07, Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > escreveu:
> >
> >
> >
> > On 12/26/23 19:10, Ranier
On Mon, 13 Nov 2023 at 09:20, Anthonin Bonnefoy
wrote:
> \syncpipeline
> tps = 2607.587877 (without initial connection time)
> ...
> \endpipeline
> \startpipeline
> tps = 2290.527462 (without initial connection time)
Those are some nice improvements. And I think once this patch is in,
it would
On Sun, 12 Nov 2023 at 14:37, Anton Kirilov wrote:
> Since there haven't been any comments from the other people who have
> chimed in on this e-mail thread, I will assume that there is consensus
> (we are doing a U-turn with the implementation approach after all), so
> here is the updated version
> On 29 Dec 2023, at 16:00, Junwang Zhao wrote:
>
> After exploring the code, I found scheduling the timeout in
> `StartTransaction` might be a reasonable idea, all the chain
> commands will call this function.
>
> What concerns me is that it is also called by StartParallelWorkerTransaction,
On Fri, Dec 29, 2023 at 6:00 PM Andrey M. Borodin wrote:
>
>
>
> > On 28 Dec 2023, at 21:02, Junwang Zhao wrote:
> >
> > Seems V5~V17 doesn't work as expected for Nikolay's case:
> >
>
> Yeah, that's a problem.
> > So I propose the following change, what do you think?
> This breaks COMMIT AND
Hi Andrei,
29.12.2023 12:58, Andrei Lepikhov wrote:
Thanks for the report!
The problem is with the resultRelation field. We forget to replace the relid
here.
Could you check your issue with the patch in the attachment? Does it resolve
this case?
Yes, with the patch applied I see no error.
On Fri, Dec 29, 2023 at 5:22 PM David Rowley wrote:
> On Fri, 29 Dec 2023 at 21:07, Richard Guo wrote:
> > It seems to me that the former scenario also makes sense in some cases.
> > For instance, let's say there are two pointers in two structs, s1->p and
> > s2->p, both referencing the same
On Fri, Dec 29, 2023 at 09:20:52AM +0530, Amit Kapila wrote:
> Does anyone have a preference for a column name? The options on the
> table are conflict_cause, conflicting_cause, conflict_reason. Any
> others? I was checking docs for similar usage and found
> "pg_event_trigger_table_rewrite_reason"
> On 21 Dec 2023, at 05:30, Jelte Fennema-Nio wrote:
>
> One thing I'm wondering: should it be possible for the client to change the
> compression it wants mid-connection?
This patchset allows sending CompressionMethod message, which allows to set
another codec\level picked from the set of
> On 28 Dec 2023, at 21:02, Junwang Zhao wrote:
>
> Seems V5~V17 doesn't work as expected for Nikolay's case:
>
Yeah, that's a problem.
> So I propose the following change, what do you think?
This breaks COMMIT AND CHAIN.
PFA v18: I've added a test for Nik's case and for COMMIT AND CHAIN.
On 29/12/2023 12:00, Alexander Lakhin wrote:
Hi Alexander,
23.10.2023 14:29, Alexander Korotkov wrote:
Fixed all of the above. Thank you for catching this!
I've discovered that starting from d3d55ce57 the following query:
CREATE TABLE t(a int PRIMARY KEY);
WITH tt AS (SELECT * FROM t)
On Fri, 29 Dec 2023 at 21:07, Richard Guo wrote:
> It seems to me that the former scenario also makes sense in some cases.
> For instance, let's say there are two pointers in two structs, s1->p and
> s2->p, both referencing the same bitmapset. If we modify the bitmapset
> via s1->p (even if no
Hi,
Commitfest 2024-01 is starting in 3 days!
Please register the patches which have not yet registered. Also if
someone has some pending patch that is not yet submitted, please
submit and register for 2024-01 Commitfest.
I will be having a look at the commitfest entries, correcting the
status if
On Thu, 28 Dec 2023 at 15:59, Amit Kapila wrote:
>
> On Wed, Dec 13, 2023 at 12:09 PM vignesh C wrote:
> >
> > Thanks for the comments, the attached v25 version patch has the
> > changes for the same.
> >
>
> I have looked at it again and made some cosmetic changes like changing
> some comments
On Fri, Dec 29, 2023 at 9:15 AM David Rowley wrote:
> I looked into this a bit more and I just can't see why the current
> code feels like it must do the reallocation in functions such as
> bms_del_members(). We don't repalloc the set there, ever, so why do
> we need to do it when building with
44 matches
Mail list logo
