On Mon, Dec 02, 2024 at 09:14:11AM -0500, Robert Haas wrote:
> On Thu, Nov 28, 2024 at 2:53 AM Anthonin Bonnefoy
> wrote:
>> Sorry about that. I didn't have a strong need for this to be
>> backpatched and should have made this clearer.
>
> FWIW, I don't think you did anything wrong. To me, the th
On Thu, Nov 28, 2024 at 2:53 AM Anthonin Bonnefoy
wrote:
> On Thu, Nov 28, 2024 at 12:26 AM Michael Paquier wrote:
> > I don't mind being more careful here based on your concerns, so I'll
> > go remove that in the stable branches.
>
> Sorry about that. I didn't have a strong need for this to be
>
On Thu, Nov 28, 2024 at 12:26 AM Michael Paquier wrote:
> I don't mind being more careful here based on your concerns, so I'll
> go remove that in the stable branches.
Sorry about that. I didn't have a strong need for this to be
backpatched and should have made this clearer.
On Wed, Nov 27, 2024 at 04:20:10PM -0500, Bruce Momjian wrote:
> Yeah, I was surprised too, even though the author was clear they wanted
> to backpatch. I couldn't figure out why it was being backpatched, so I
> figured I was missing something.
The set of inconsistencies of how we decide if one c
On Wed, Nov 27, 2024 at 03:54:24PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > I'm very surprised that this was back-patched. I think we should
> > revert it from the back-branches before it gets into a minor release.
> > It seems like a clear definitional change, which has no business in a
>
Robert Haas writes:
> I'm very surprised that this was back-patched. I think we should
> revert it from the back-branches before it gets into a minor release.
> It seems like a clear definitional change, which has no business in a
> minor release.
I was troubled by that too. Maybe this can be pa
On 2024-11-27 15:41:14 -0500, Robert Haas wrote:
> On Tue, Nov 26, 2024 at 7:42 PM Michael Paquier wrote:
> > On Tue, Nov 26, 2024 at 04:24:58PM +0900, Michael Paquier wrote:
> > > Tweaks of the tests across multiple stable branches happen all the
> > > time, and adding one specific to 17~ is no b
On Tue, Nov 26, 2024 at 7:42 PM Michael Paquier wrote:
> On Tue, Nov 26, 2024 at 04:24:58PM +0900, Michael Paquier wrote:
> > Tweaks of the tests across multiple stable branches happen all the
> > time, and adding one specific to 17~ is no big issue. I'm in the
> > middle of it but I'm lacking th
On Wed, 27 Nov 2024 at 01:42, Michael Paquier wrote:
> I've edited the whole, added this extra test based on \syncpipeline in
> 17~, kept the remaining tests in 14~ where pgbench is able to handle
> them, and backpatched that down to 13. Let's see now what we can do
> with the psql bits.
FYI: it
On Wed, Nov 27, 2024 at 1:42 AM Michael Paquier wrote:
> I've edited the whole, added this extra test based on \syncpipeline in
> 17~, kept the remaining tests in 14~ where pgbench is able to handle
> them, and backpatched that down to 13. Let's see now what we can do
> with the psql bits.
Thank
On Tue, Nov 26, 2024 at 04:24:58PM +0900, Michael Paquier wrote:
> Tweaks of the tests across multiple stable branches happen all the
> time, and adding one specific to 17~ is no big issue. I'm in the
> middle of it but I'm lacking the steam to do so today. Will likely
> finish tomorrow.
I've ed
On Mon, Nov 25, 2024 at 02:35:25PM +0100, Anthonin Bonnefoy wrote:
> 0001: Use implicit transaction block for the implicit pipeline
> transaction. I've added tests in pgbench that covered the same checks
> I did in psql. I've avoided using \syncpipeline since it was
> introduced in 17. I've also sl
Thanks for the review!
On Mon, Nov 25, 2024 at 7:39 AM Michael Paquier wrote:
>
> This breaks an existing property of psql. One example: \edit where we
> should keep the existing query buffer rather than discard it if a
> failure happens. This patch forcibly removes the contents of the
> query
On Wed, Nov 20, 2024 at 06:03:12PM +0100, Anthonin Bonnefoy wrote:
> 0001: This is a small bug I've stumbled upon. The query buffer is not
> cleared on a backslash error. For example, "SELECT 1 \parse" would
> fail due to a missing statement name but would leave "SELECT 1\n" in
> the query buffer w
Some minor changes: I forgot to add the new pipeline meta-commands to
psql's help output, this is now added in 0002. I've also reworded the
doc a bit.
v04-0001-Reset-query-buffer-on-a-backslash-error.patch
Description: Binary data
v04-0002-Add-pipeline-support-in-psql.patch
Description: Binary
On Tue, Nov 5, 2024 at 6:50 AM Michael Paquier wrote:
> It would be nice to document all these behaviors with regression
> tests in pgbench as it is the only place where we can control that
> with error pattern checks.
It's not the first time I wanted to be able to do pipelining in psql
as relying
On Mon, Nov 04, 2024 at 10:42:36AM +0100, Anthonin Bonnefoy wrote:
> This allows the removal of the XACT_FLAGS_PIPELINING check in
> IsInTransactionBlock and PreventInTransactionBlock since the
> transaction state will correctly reflect the ongoing implicit block.
> Additionally, it will reuse the
On Sat, Nov 2, 2024 at 4:11 AM Michael Paquier wrote:
> Now, here is a fancy case: SAVEPOINT and its two brothers. An error
> would be reported on HEAD if attempting a SAVEPOINT, complaining that
> we are not in a transaction block. The patch causes a different, more
> confusing, failure:
> FATA
On Thu, Oct 31, 2024 at 03:32:39PM +0900, Michael Paquier wrote:
> @Tom added in CC: Is there a specific reason why CheckTransactionBlock()
> did not include a check based on XACT_FLAGS_PIPELINING when it got
> introduced in 20432f873140, while IsInTransactionBlock() considers it?
This also makes
On Wed, Oct 30, 2024 at 04:06:20PM +0100, Jelte Fennema-Nio wrote:
> On Wed, 30 Oct 2024 at 10:15, Anthonin Bonnefoy
> wrote:
>> The attached patch adds the detection of implicit transactions started
>> by a pipeline in CheckTransactionBlock, avoiding warnings when
>> commands like `set local` are
On Wed, 30 Oct 2024 at 10:15, Anthonin Bonnefoy
wrote:
> The attached patch adds the detection of implicit transactions started
> by a pipeline in CheckTransactionBlock, avoiding warnings when
> commands like `set local` are called within a pipeline, and making the
> detection of transaction block
Hi,
When using pipelining with implicit transaction, a transaction will
start from the first command and be committed with the Sync message.
Functions like IsInTransactionBlock and PreventInTransactionBlock
already assimilate this implicit transaction as a transaction block,
relying on the XACT_FL
22 matches
Mail list logo