On Mon, Oct 4, 2021 at 6:01 AM Masahiko Sawada wrote:
>
> On Fri, Oct 1, 2021 at 5:32 PM Amit Kapila wrote:
> >
> > On Fri, Oct 1, 2021 at 6:30 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Oct 1, 2021 at 5:05 AM Peter Eisentraut
> > > wrote:
> > > >
> > > > On 30.09.21 07:45, Masahiko
>-Original Message-
>From: Fujii Masao
>Sent: Monday, October 4, 2021 1:59 PM
>To: bt21tanigaway ; RDH 加藤 慎也/Kato,
>Shinya (NTT DATA)
>Cc: pgsql-hackers@lists.postgresql.org
>Subject: Re: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet
>implemented
>
>
>
>On 2021/10/04 11:17,
Hello Tom,
As I threatened in another thread, I've looked through all of the
oldest commitfest entries to see which ones should maybe be tossed,
on the grounds that they're unlikely to ever get committed so we
should stop pushing them forward to the next CF.
psql - add SHOW_ALL_RESULTS
On Thu, Sep 30, 2021 at 11:12:21AM +0900, Michael Paquier wrote:
> There is also no need for tests on 1.9, which is the latest version.
> Tests for this one should be added once we bump the code to the next
> version. At the end I finish with the attached, counting for the
> back-and-forth game
On Fri, Oct 1, 2021 at 6:23 PM Alvaro Herrera wrote:
>
> On 2021-Oct-01, Amit Kapila wrote:
>
> > AFAICS, there are two possibilities w.r.t global variables: (a) use
> > curinsert_flags which we are doing now, (b) another is to introduce a
> > new global variable, set it after we make the
On 2021/10/04 11:17, bt21tanigaway wrote:
else if (Matches("LOCK", MatchAny, "IN", "ACCESS|ROW") ||
- Matches("LOCK", "TABLE", MatchAny, "IN", "ACCESS|ROW"))
+ Matches("LOCK", "TABLE", MatchAny, "IN", "ACCESS|ROW") ||
+ Matches("LOCK", "ONLY", MatchAny,
On Sun, Oct 3, 2021 at 5:05 PM Dilip Kumar wrote:
>
> On Sat, Oct 2, 2021 at 8:10 PM Alvaro Herrera wrote:
> >
> > On 2021-Oct-02, Dilip Kumar wrote:
> >
> > > I have written two patches, Approach1 is as you described using a
> > > static boolean and Approach2 as a local variable to
В Пт, 01/10/2021 в 15:46 -0700, Zhihong Yu wrote:
>
>
> On Fri, Oct 1, 2021 at 3:26 PM Yura Sokolov
> wrote:
> > Good day.
> >
> > I found some opportunity in Buffer Manager code in BufferAlloc
> > function:
> > - When valid buffer is evicted, BufferAlloc acquires two partition
> > lwlocks:
ne 3. 10. 2021 v 22:16 odesílatel Tom Lane napsal:
> Erik Rijkers writes:
> > Op 03-10-2021 om 21:14 schreef Tom Lane:
> >> I looked at entries that are at least 10 CFs old, as indicated by
> >> the handy sort field. That's a pretty small population: 16 items
> >> out of the 317 listed in the
Hi
schema variables, LET command 18
> Last substantive discussion 2021-09, currently passing cfbot
>
> Seems to be actively worked on, but is it ever going to get
> committed?
>
>
This patch was originally very dirty with a strange design - something
between command and
else if (Matches("LOCK", MatchAny, "IN", "ACCESS|ROW") ||
-Matches("LOCK", "TABLE", MatchAny, "IN", "ACCESS|ROW"))
+Matches("LOCK", "TABLE", MatchAny, "IN", "ACCESS|ROW")
||
+Matches("LOCK", "ONLY", MatchAny, "IN",
On Fri, Oct 1, 2021 at 5:32 PM Amit Kapila wrote:
>
> On Fri, Oct 1, 2021 at 6:30 AM Masahiko Sawada wrote:
> >
> > On Fri, Oct 1, 2021 at 5:05 AM Peter Eisentraut
> > wrote:
> > >
> > > On 30.09.21 07:45, Masahiko Sawada wrote:
> > > > I've attached updated patches that incorporate all
> On Oct 3, 2021, at 10:04 AM, Mark Dilger wrote:
>
>> On Oct 2, 2021, at 10:32 AM, Peter Geoghegan wrote:
>>
>> On Sat, Oct 2, 2021 at 4:49 AM PG Bug reporting form
>> wrote:
>>> Although you can add --exclude-relation=*.pg_temp*.*, this behaviour differs
>>> from the behaviour of pg_dump
On Sun, Oct 3, 2021 at 1:30 PM Tom Lane wrote:
> Hm, perhaps. You're right that the classification might be slippery.
> I do feel it's useful to distinguish "this is a bad idea overall,
> we don't want to see follow-on patches" from "this needs work, please
> send a follow-on patch when you've
Updated patch that removes the "Maybe"
--
Kevin Burke
phone: 925-271-7005 | kevin.burke.dev
On Sat, Oct 2, 2021 at 11:19 AM Tom Lane wrote:
> Daniel Gustafsson writes:
> >> On 2 Oct 2021, at 02:09, Kevin Burke wrote:
> >> This patch amends the error message to give help to the user.
>
> >
> On 3 Oct 2021, at 06:05, Andres Freund wrote:
> Did you run those tests on windows?
Sorry, failed to mention I only compile it for now, I hadn't reached trying to
run the tests yet. I see you started on that in this thread, so thank you for
that!
--
Daniel Gustafsson
Peter Geoghegan writes:
> On Sun, Oct 3, 2021 at 12:15 PM Tom Lane wrote:
>> Perhaps we should create a new closure state?
> I'd rather go in the opposite direction here: merge "Rejected" and
> "Returned with Feedback" into a single "Patch Returned" category
> (without adding a third category).
On Sun, Oct 3, 2021 at 12:15 PM Tom Lane wrote:
> An important note to make here is that we don't have any explicit
> mechanism for saying "sorry, this patch is perhaps useful but it
> seems that nobody is going to take an interest in it". Closing
> such a patch as "rejected" seems harsh, but
Erik Rijkers writes:
> Op 03-10-2021 om 21:14 schreef Tom Lane:
>> I looked at entries that are at least 10 CFs old, as indicated by
>> the handy sort field. That's a pretty small population: 16 items
>> out of the 317 listed in the 2021-09 CF. A quick look in recent
>> CFs shows that it's very
Hi,
+ pg_log_error("\\pset: allowed xheader_width values are full
(default), column, page, or an number specifying exact width.");
an number specifying -> a number specifying
Cheers
Fixed, attaching the updated patch. Thank you!
Best regards,
Platon Pronkodiff --git
Op 03-10-2021 om 21:14 schreef Tom Lane:
As I threatened in another thread, I've looked through all of the
oldest commitfest entries to see which ones should maybe be tossed,
on the grounds that they're unlikely to ever get committed so we
should stop pushing them forward to the next CF.
An
As I threatened in another thread, I've looked through all of the
oldest commitfest entries to see which ones should maybe be tossed,
on the grounds that they're unlikely to ever get committed so we
should stop pushing them forward to the next CF.
An important note to make here is that we don't
Dear all
Just for my understanding - and perhaps as input for the documentation of this:
Are Foreign Key Arrays a means to implement "Generic Foreign Keys" as
in Oracle [1] and Django [2], and of "Polymorphic Associations" as
they call this in Ruby on Rails?
Yours, Stefan
[1] Steven Feuerstein
Hi,
On 2021-10-03 10:18:31 -0700, Andres Freund wrote:
> As you can see in the test output, every mismatch prints the whole file,
> despite only intending to show the tail. Which appears to be because the
> windows portion of 3c5b0685b921 doesn't actually work. The reason for that in
> turn is
Hi,
On 2021-10-02 21:05:17 -0700, Andres Freund wrote:
> Got the build part working (although the state of msvc compatible openssl
> distribution on windows seems a bit scary). However the ssl tests don't
> fully succeed:
>
> https://cirrus-ci.com/task/6264790323560448?logs=ssl#L655
>
> I
On Sat, 4 Sept 2021 at 20:28, Tom Lane wrote:
> We have two things that we need to worry about when considering
> reducing ALTER TABLE lock levels:
>
> 1. Is it semantically okay (which is what you claim above)?
>
> 2. Will onlooker processes see sufficiently-consistent catalog data
> if they
On Sun, Oct 03, 2021 at 11:20:21AM -0500, Jaime Casanova wrote:
> On Sat, Oct 02, 2021 at 11:32:01AM -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2021-Oct-02, Tom Lane wrote:
> > >> Yeah. I have been thinking of looking through the oldest CF entries
> > >> and proposing that we
On Sat, Oct 02, 2021 at 12:20:09PM -0300, Alvaro Herrera wrote:
> On 2021-Oct-02, Tom Lane wrote:
>
> > Yeah. I have been thinking of looking through the oldest CF entries
> > and proposing that we just reject any that look permanently stalled.
> > It doesn't do much good to leave things in the
On Sat, Oct 02, 2021 at 11:32:01AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Oct-02, Tom Lane wrote:
> >> Yeah. I have been thinking of looking through the oldest CF entries
> >> and proposing that we just reject any that look permanently stalled.
>
> > I was just going to say
On Sun, Oct 3, 2021 at 5:57 AM Platon Pronko
wrote:
> On 2021-09-24 14:42, Andrew Dunstan wrote:
> >
> > On 9/24/21 12:49 AM, Platon Pronko wrote:
> >> On 2021-09-23 22:28, Andrew Dunstan wrote:
> >>>
> >>> 2. It would possibly be better to pass the relevant parts of the
> options
> >>> to
Magnus Hagander writes:
> On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier wrote:
>> That's the tricky part. It does not really make sense either to keep
>> moving patches that are waiting on author for months.
> I'm pretty sure this is the original reason for adding this -- to enforce
> that
On 2021-09-24 14:42, Andrew Dunstan wrote:
On 9/24/21 12:49 AM, Platon Pronko wrote:
On 2021-09-23 22:28, Andrew Dunstan wrote:
2. It would possibly be better to pass the relevant parts of the options
to print_aligned_vertical_line() rather than the whole options
structure. It feels odd to
On 10/2/21 11:34 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/2/21 5:03 PM, Tom Lane wrote:
>>> IIUC, the only problem for a non-updated animal would be that it'd
>>> run the test twice? Or would it actually fail? If the latter,
>>> we'd need to sit on the patch rather longer.
>> The
On Sat, Oct 2, 2021 at 8:10 PM Alvaro Herrera wrote:
>
> On 2021-Oct-02, Dilip Kumar wrote:
>
> > I have written two patches, Approach1 is as you described using a
> > static boolean and Approach2 as a local variable to XLogAssembleRecord
> > as described by Amit, attached both of them for your
On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier wrote:
> On Fri, Oct 01, 2021 at 08:29:08PM +0200, Daniel Gustafsson wrote:
> > Correct, if one looks at the activity log for an old entry the pattern of
> > moving to needs review, then to the next CF, then WoA is clearly visible.
>
> That's the
On Sat, Oct 02, 2021 at 11:32:01AM -0400, Tom Lane wrote:
> Right. Michael and Jaime have been doing some of that too in the last
> few days, but obviously a CFM should only do that unilaterally in very
> clear-cut cases of patch abandonment. I was intending to go after some
> where maybe a bit
On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
> Maybe we could leave test.sh in place for awhile? I'd rather
> not cause a flag day for buildfarm owners. (Also, how do we
> see this working in the back branches?)
I would be fine with test.sh staying around for now.
If we do that,
37 matches
Mail list logo
