On 27 February 2018 at 14:41, Anastasia Lubennikova
wrote:
> Small patch in the attachment implements logfile reopeninig on SIGHUP.
> It only affects the file accessed by logging collector, which name you can
> check with pg_current_logfile().
HUP will cause Postgres to reload its config files.
On 6 February 2018 at 03:13, Craig Ringer wrote:
> On 6 February 2018 at 09:51, Joshua D. Drake wrote:
>>
>> On 02/05/2018 04:09 PM, David Fetter wrote:
>>
>>> Does this seem worth coding up in its current form?
>>
>> No. The pg_upgrade utility is awesome and I have commended Bruce on
>> multiple
On 27 February 2018 at 16:50, Greg Stark wrote:
> On 27 February 2018 at 02:04, Michael Paquier wrote:
>> On Mon, Feb 26, 2018 at 05:38:56PM +0000, Greg Stark wrote:
>>
>> Hm. I have just loaded jsonlog on a 9.6 and 10 instance where
>> log_checkpoints is enabled
I've often wanted something similar. But I've struggled to come up
with a good way to decide which parameters to keep. And as someone
mentioned, there's the question of how to deal with very large
constants.
The other day I was poking around with pg_stat_statements and jsonlog
and I thought of ano
On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas wrote:
>
> On 20/01/2023 03:28, Jacob Champion wrote:
> > On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
> >> * "Service Mesh" type tools that hide multiple services behind a
> >> single host/port (&
So I'm not sure if I'll be CFM this month but I'm assuming I will be
at this point
Regardless, Commitfest 2023-03 starts tomorrow!
So this is a good time to check your submitted patches and ensure
they're actually in building and don't need a rebase. Take a look at
http://cfbot.cputube.org/ f
On Tue, 28 Feb 2023 at 05:13, Kartyshov Ivan wrote:
>
> Below I provide the implementation of patches for the first three types.
> I propose to discuss this feature again/
Oof, that doesn't really work with the cfbot. It tries to apply all
three patches and of course the second and third fail to
On Tue, 14 Mar 2023 at 13:59, Tom Lane wrote:
>
> "Gregory Stark (as CFM)" writes:
> > It looks like this needs a big rebase in fea-uth.c fe-auth-scram.c and
> > fe-connect.c. Every hunk is failing which perhaps means the code
> > you're patching has been moved or refactored?
>
> The cfbot is giv
On Tue, 17 Jan 2023 at 14:52, Tomas Vondra
wrote:
>
> On 1/17/23 19:46, Andres Freund wrote:
>
> > I think a "hybrid" explain mode might be worth thinking about. Use the
> > "current" sampling method for the first execution of a node, and for the
> > first
> > few milliseconds of a query (or perh
I notice a number of places in fe-connect.c have copied this idiom
where if an option is present they validate the legal options and
otherwise they strdup a default value. This strdup of the default
option I think is being copied from sslmode's validation which is a
bit special but afaics the follo
ion combinations -- namely
sslnegotiation=direct and default gssencmode and sslmode results in a
counter-intuitive behaviour. But I don't see a better option that
doesn't mean making the defaults less useful.
From b07e19223bee52b7bb9b50afea39e4baaa0a46f3 Mon Sep 17 00:00:00 2001
From: Gr
On Wed, 15 Mar 2023 at 14:29, Gregory Stark (as CFM)
wrote:
>
> These patches that are "Needs Review" and have received no comments at
> all since before March 1st are these. If your patch is amongst this
> list I would suggest any of:
>
> 1) Move it yourself to the next CF (or withdraw it)
> 2) P
On Fri, 17 Mar 2023 at 10:39, Tom Lane wrote:
>
> You've listed a lot of small features here that still have time to
> get some love --- it's not like we're hard up against the end of the CF.
> If they'd been in Waiting on Author state for awhile, I'd agree with
> booting them, but not when they'r
The next level of this would be something like notifying the committer
with a list of patches in the CF that a commit broke. I don't
immediately see how to integrate that with our workflow but I have
seen something like this work well in a previous job. When committing
code you often went and updat
TOP_ALL. Nor why we would want ON_ERROR_STOP_SHELL which
stops only on shell errors, rather than, say, ON_ERROR_STOP_SQL to do
the converse which would at least match the historical behaviour?
From 1f0feb9daf106721cb7fcba39ef7d663178f8ed1 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023
On Mon, 20 Mar 2023 at 16:08, Thomas Munro wrote:
>
> On Tue, Mar 21, 2023 at 3:15 AM Greg Stark wrote:
> > The next level of this would be something like notifying the committer
> > with a list of patches in the CF that a commit broke. I don't
> > immediately see h
changed (modulo a free() that I missed in the
client before). They still have the semi-open issues I mentioned in
the previous email.
--
greg
From 32185020927824c4b57af900100a37f92ae6a040 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023 14:09:30 -0400
Subject: [PATCH v3 4/4] a
Sorry, checking the cfbot apparently I had a typo in the #ifndef USE_SSL case.
From 4b6e01c7f569a919d660cd80ce64cb913bc9f220 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023 14:09:30 -0400
Subject: [PATCH v4 4/4] alpn support
---
src/backend/libpq/be-secure-openssl.c| 65
So back in 2002 in 7.3 there was a commit 2c6b34d9598 which added a
GUC db_user_namespace which is stored in a variable Db_user_namespace.
All that seems fine except...
The variable this GUC is stored in is Db_user_namespace which... is
actually declared in pqcomm.h which is intended to be "Defini
On Tue, 21 Mar 2023 at 05:59, Alvaro Herrera wrote:
>
> On 2023-Mar-20, Thomas Munro wrote:
>
> This led me to suggesting that perhaps we need to be more lenient when
> it comes to new contributors. As I said, for seasoned contributors,
> it's not a problem to keep up with our requirements, howev
The CFBot says there's a function be_gssapi_get_proxy() which is
undefined. Presumably this is a missing #ifdef or a definition that
should be outside an #ifdef.
[14:05:21.532] dblink.c: In function ‘dblink_security_check’:
[14:05:21.532] dblink.c:2606:38: error: implicit declaration of
function ‘
So a week later
Status summary: March 15March 22
Needs review: 152 128
Waiting on Author: 42 36
Ready for Committer: 39 32
Committed: 61 82
Moved to next CF: 4 15
Withdrawn: 17
On Thu, 27 Oct 2022 at 07:10, Simon Riggs wrote:
>
> In the past, developers have wondered how we can provide "--dry-run"
> functionality
That would be an awesome functionality, indeed. I have concerns of how
feasible it is in general but I think providing features to allow
developers to build it
So of the patches with no emails since August-December 2022:
* New hooks in the connection path
* Add log messages when replication slots become active and inactive
- Peter Smith and Alvaro Herrera have picked up this one
* Remove dead macro exec_subplan_get_plan
- Minor cleanup
* Consider
On Thu, 23 Mar 2023 at 23:30, Bharath Rupireddy
wrote:
>
> > + ereport(log_replication_commands ? LOG : DEBUG3,
> > + (errmsg("acquired physical replication slot \"%s\"",
> > + slotname)));
So this is just a bit of bike-shedding but I don't feel like these log
messages really meet the standard we
On Wed, 7 Dec 2022 at 22:02, Greg Stark wrote:
> > Seems like this should just be in
> > heapam_relation_nontransactional_truncate()?
So here I've done it that way. It is a bit of an unfortunate layering
since it means the heapam_handler is doing the catalog change but it
does
On Sat, 5 Nov 2022 at 15:34, Tom Lane wrote:
>
> Greg Stark writes:
> > Simple Rebase
>
> I took a little bit of a look through these.
>
> * I find 0001 a bit scary, specifically that it's decided it's
> okay to apply extract_autovac_opts, pgstat_fetc
> You do have to lock a table in order to update its pg_class row,
> though, whether the table is temporary or not. Otherwise, another
> session could drop it while you're doing something with it, after
> which bad things would happen.
I was responding to this from Andres:
> Is that actually true
I had a conversation a while back with Heikki where he expressed that
it was annoying that we negotiate SSL/TLS the way we do since it
introduces an extra round trip. Aside from the performance
optimization I think accepting standard TLS connections would open the
door to a number of other opportun
On Mon, 20 Mar 2023 at 16:31, Greg Stark wrote:
>
> Here's a first cut at ALPN support.
>
> Currently it's using a hard coded "Postgres/3.0" protocol
Apparently that is explicitly disrecommended by the IETF folk. They
want something like "TBD" so people
And the cfbot wants a small tweak
From 3d0a502c25504da32b7a362831c700b4e891f79b Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Fri, 31 Mar 2023 02:31:31 -0400
Subject: [PATCH v6 5/6] Allow pipelining data after ssl request
---
src/backend/postmaster/postmaster.c | 54
On Sun, 2 Apr 2023 at 11:38, Tom Lane wrote:
>
> Even if all that infrastructure sprang into existence, is this really any
> more useful than basing your switching on the host's resolved IP address?
> I'm doubtful that there's enough win there to justify pushing this rock
> to the top of the mount
On Mon, 30 Jan 2023 at 18:31, Nathan Bossart wrote:
>
> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> distributions for various workloads, and he mentioned that it would be nice
> to have an easy way to do $SUBJECT. I've attached a patch that adds a
> pg_buffercache
On Tue, 4 Apr 2023 at 11:18, Tom Lane wrote:
>
> > * clean up permission checks after 599b33b94
>
> I believe that the actual bug fixes are in, and what's left is just a test
> case that people weren't very excited about adding. So maybe this should
> get closed out as committed.
I'm not super c
On Wed, 29 Mar 2023 at 17:48, Justin Pryzby wrote:
>
> The patch still occasionally fails its tests under freebsd.
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/42/3358
So on the one hand, I don't think the plan is to actually commit the
tests. They're very specific to one
On Wed, 5 Apr 2023 at 01:41, Greg Stark wrote:
>
> On Wed, 29 Mar 2023 at 17:48, Justin Pryzby wrote:
> >
> > The patch still occasionally fails its tests under freebsd.
> > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/42/3358
>
> I wonder
On Mon, 3 Apr 2023 at 19:32, Tom Lane wrote:
>
> Or we could rethink the design goal of not allowing enable_foo switches
> to cause us to fail to make a plan. That might be unusable though.
Off the top of my head I don't see why. It's not like the possible
plans are going to change on you often,
On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
>
> This feature can significantly increase log size, so it's disabled by default.
> For testing or development environments it's recommended to enable it if you
> use session variables.
I think it's generally not practical to have warnings for
On Wed, 5 Apr 2023 at 11:15, Andres Freund wrote:
>
> The freebsd test that failed is running tests in parallel, against an existing
> cluster. In that case it's expected that there's some concurrency.
>
> Why does this cause your tests to fail? They're in separate databases, so the
> visibility e
On Wed, 5 Apr 2023 at 13:42, Andres Freund wrote:
>
> Not if you determine a relation specific xmin, and the relation is not a
> shared relation.
>
> ISTM that the problem here really is that you're relying on RecentXmin, rather
> than computing something more accurate. Why not use
> GetOldestNonR
As announced on this list feature freeze is at 00:00 April 8 AoE.
That's less than 24 hours away. If you need to set your watches to AoE
timezone it's currently:
$ TZ=AOE+12 date
Fri 07 Apr 2023 02:05:50 AM AOE
As we stand we have:
Status summary:
Needs review: 82
Waiting on Auth
So here we are at the end of the CF:
Status summary: March 15March 22March 28April 4 April 8
Needs review: 152 128 116 96 74
Waiting on Author: 42 36 30 21 14
Ready for Committer: 39 32
On Wed, 22 Feb 2023 at 13:38, Kirk Wolak wrote:
>
> I already requested ONLY the HH24 format. 8 characters of output. no
> options. It's a waste of time.
> After all these years, sqlplus still has only one setting (show it, or not).
> I am asking the same here.
> And I will gladly defend not
So here's the list of CF entries that I thought *might* still get
committed either because they're an Open Issue or they're one of those
other categories. I had intended to go through and add them all to the
Open Issues but it turns out I only feel confident in a couple of them
qualifying for that:
On Fri, 17 Feb 2023 at 15:38, Tom Lane wrote:
>
> Hmm, so Stephen was opining that the extension's objects shouldn't
> have gotten these privs attached in the first place. I'm not
> quite convinced about that one way or the other, but if you buy it
> then maybe this situation is unreachable once
On Wed, 12 Apr 2023 at 11:02, Robert Haas wrote:
>
> I mostly just wanted to say that I disagreed with Tom about the
> particular point on postmaster.pid, without really expressing an
> opinion about anything else.
I don't object to using the pid file as the mechanism -- but it is a
bit of an awk
On Wed, 5 Apr 2023 at 13:42, Andres Freund wrote:
>
> ISTM that the problem here really is that you're relying on RecentXmin, rather
> than computing something more accurate. Why not use
> GetOldestNonRemovableTransactionId(rel) - It's a bit more expensive, but I
> don't think it'll matter compare
On Wed, Apr 12, 2023, 19:30 Daniel Gustafsson wrote:
>
> The issue we have is that we cannot get PGconn in
> verify_cb so logging an error is tricky.
Hm, the man page talks about a "ex_data mechanism" which seems to be
referring to this Rube Goldberg device
https://www.openssl.org/docs/man3.1/m
On Thu, 13 Apr 2023 at 13:01, Peter Geoghegan wrote:
>
> On Thu, Apr 13, 2023 at 9:45 AM Robert Haas wrote:
> >
> > On Wed, Apr 12, 2023 at 4:23 PM Greg Stark wrote:
> > > Am I crazy or is the parenthetical comment there exactly backwards? If
> > > the horizo
On Fri, 14 Apr 2023 at 09:47, Jonathan S. Katz wrote:
>
> Let me restate [1] in a different way.
>
> Using a large enough dataset, I did qualitatively look at overall usage
> of both "vacuum_defer_cleanup_age" and compared to
> "hot_standby_feedback", given you can use both to accomplish similar
>
On Wed, 11 May 2022 at 06:19, Peter Eisentraut
wrote:
>
> After that, these configure options don't have an equivalent yet:
>
> --enable-profiling
Afaics this still doesn't exist? Is there a common idiom to enable
this? Like, if I add in something to cflags is that enough? I seem to
recall we had
On Fri, 14 Apr 2023 at 13:15, Laurenz Albe wrote:
>
> On Fri, 2023-04-14 at 18:43 +0200, Alvaro Herrera wrote:
> > On 2023-Apr-14, Greg Stark wrote:
> > > I assume people would use hot_standby_feedback if they have streaming
> > > replication.
> >
> > Yes
lementation behaves in the specific way it was
> > written to.
>
> To me it seems important to test that your change actually does what it
> intends to. Possibly the test needs to be relaxed some, but I do think we want
> tests for the change.
>
> Greetings,
>
&
Hm, in an optimized build using kernel perf I see this. But I don't
know how to find what the call sites are for LWLockAcquire/Release. If
it's the locks on pgproc that would be kind of bad.
I wonder if I should be gathering horizons once in the
PrecommitActions and then just using those for every
On Mon, 17 Apr 2023 at 17:45, Thomas Munro wrote:
>
> Reasons: (1) There will always be a
> few file systems that refuse O_DIRECT (Linux tmpfs is one such, as we
> learned in this thread; if fails with EINVAL at open() time), and
So why wouldn't we just automatically turn it off (globally or for
On Mon, 17 Apr 2023 at 16:22, Tom Lane wrote:
>
> I tend to agree with the proposition that we aren't going to add new
> message types very often, as long as we're careful to make them general
> purpose. Don't forget that adding a new message type isn't just a matter
> of writing some spec text -
Including the pre-truncation length in the wal record is the obviously
solid approach and I none of the below is a good substitution for it.
But
On Tue, 25 Apr 2023 at 13:30, Andres Freund wrote:
>
> It isn't - but the alternatives aren't great either. It's not that easy to hit
> this scenari
On Wed, 3 May 2023 at 18:50, Peter Geoghegan wrote:
>
> What about "XID allocation overload"? The implication that I'm going
> for here is that the system was misconfigured, or there was otherwise
> some kind of imbalance between XID supply and demand.
Fwiw while "wraparound" has pitfalls I think
On Thu, 11 May 2023 at 05:37, Peter Eisentraut
wrote:
>
> Maybe it was never meant that way and only works accidentally? Maybe
> hash indexes are broken?
It's explicitly documented to be this way. And I think it has to work
this way for recovery to work.
I think the reason you and Bharath and A
On Thu, 11 May 2023 at 10:04, Joel Jacobson wrote:
>
> The parser currently accepts quoting within an unquoted field. This can lead
> to
> data misinterpretation when the quote is part of the field data (e.g.,
> for inches, like in the example).
I think you're thinking about it differently than
On Thu, 11 May 2023 at 16:41, Peter Geoghegan wrote:
>
> > I say "exhaustion" or "overload" are meaningless because their meaning
> > is entirely dependent on context. It's not like memory exhaustion or
> > i/o overload where it's a finite resource and it's just the sheer
> > amount in use that ma
On Sat, 13 May 2023 at 09:46, Tom Lane wrote:
>
> Andrew Dunstan writes:
> > I could see an argument for a STRICT mode which would disallow partially
> > quoted fields, although I'd like some evidence that we're dealing with a
> > real problem here. Is there really a CSV producer that produces ou
Awesome to see this get committed, thanks Tomas.
Is there anything left or shall I update the CF entry to committed?
It looks like this discussion has reached a bit of an impasse with Tom
being against this approach and Michael and Daniel being for it. It
doesn't look like it's going to get committed this commitfest, shall
we move it forward or mark it returned with feedback?
Great to see the first of the two patches committed.
It looks like the second patch got some feedback from Peter in
February and has been marked "Waiting on author" ever since.
Remi, will you have a chance to look at this this month?
Peter, are these comments blocking if Remi doesn't have a chan
Development of this seems to have stalled with the only review of this
patch expressing some skepticism about whether it's needed at all.
Unless anyone steps forward and says it's interesting I'm going to
mark it rejected?
I don't actually think it's a terrible idea myself but I think every
use c
This patch seems to have gotten some feedback but development has
stalled. It's marked "waiting on author" but I'm not clear exactly
what is expected from the authors here. It seems there isn't really
consensus on the design at the moment. There's been no emails in over
a month.
Fwiw I find the id
This doesn't seem to be getting any further attention. It sounds like
Julien didn't agree with the scope of the text. Bharath do you think
Julien's comments make sense? Will you have a chance to look at this?
This patch is marked "waiting on author" in the CF. However the most
recent emails have patches and it's not clear to me what's left from
previous reviews that might not be addressed yet. Should this patch be
marked "Needs Review"?
Anastasia and Alexander are marked as reviewers. Are you still abl
It seems development on this has stalled. If there's no further work
happening I guess I'll mark the patch returned with feedback. Feel
free to resubmit it to the next CF when there's progress.
I'm going to mark this returned with feedback.
If you have a chance to update the patch moving the documentation to
xfunc.sgml the way Tom describes make sure to create a new commitfest
entry. I would suggest submitting the patch as a followup on this
thread so when it's added to the commitfest it
In the interests of trying to clean up the CF and keep things moving
I'll mark the patch rejected.
That doesn't mean the decision can't change or that nobody's allowed
to keep discussing it. It's just that that seems to be the decision
right now and there are too many patches queued up to keep thi
This patch got some very positive feedback and some significant amount
of work earlier in the release cycle. The feedback from Julien earlier
this month seemed pretty minor.
Ekaterina, is there any chance you'll be able to work on this this
week and do you think it has a chance of making this rele
I notice a number of patches have a failure in the cfbot on the
027_stream_regress test. I think these are related to a bug in that
test being discussed in a thread somewhere though I don't have it
handy. Is that right?
I think it doesn't indicate anything wrong with the individual patches right?
This patch is currently showing up with a test failure in the CFBot
however I do *not* believe this is a bug in the patch. I think it's a
bug in that test which is being discussed elsewhere.
It's also a very short and straightforward patch that a committer
could probably make a decision about whet
On Tue, 22 Mar 2022 at 09:52, Michail Nikolaev
wrote:
>
> Thanks for notifying me. BTW, some kind of automatic email in case of
> status change could be very helpful.
I agree but realize the cfbot is quite new and I guess the priority is
to work out any kinks before spamming people with false pos
On Mon, 28 Mar 2022 at 05:17, Daniel Gustafsson wrote:
>
> named to match the git format-patch output
> since I think the CFBot just applies the patches in alphabetical order).
The first patch doesn't seem to actually apply though so it doesn't
get to the subsequent patches.
http://cfbot.cputube
FYI I think the patch failure in the cfbot is spurious because the
cfbot got confused by Erik's patch.
a9cb4265a2debabeb94cd32b47 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Tue, 22 Mar 2022 15:54:59 -0400
Subject: [PATCH v4 2/2] Add test for truncating temp tables advancing
relfrozenxid
This test depends on other transactions not running at the same time
so that relfrozenxid can advance so
Fwiw the cfbot is failing due to a duplicate OID. Traditionally we
didn't treat duplicate OIDs as reason to reject a patch because
they're inevitable as other patches get committed and the committer
can just renumber them.
I think the cfbot kind of changes this calculus since it's a pain lose
the
On Mon, 28 Mar 2022 at 16:30, Andres Freund wrote:
>
> > Make ON COMMIT DELETE ROWS reset relfrozenxmin and other table stats
> > like normal truncate. Otherwise even typical short-lived transactions
> > using temporary tables can easily cause them to reach relfrozenxid.
>
> Might be w
FYI this patch no longer applies.
Given it's a Tom patch and due to its nature it'll bitrot rapidly
anyways I'm don't see a point in updating the status though.
Sadly the cfbot is showing a patch conflict again. It's just a trivial
conflict in the regression test schedule so I'm not going to update
the status but it would be good to rebase it so we continue to get
cfbot testing.
On Mon, 28 Feb 2022 at 17:50, Tom Lane wrote:
>
> Chapman Flack writes:
> > In the current state of affairs, what's considered the ur-source of that
> > information?
>
> The source code for the type's send/receive functions :-(. One could
> wish for something better, but no one has stepped up to
This patch is now failing in the sqljson regression test. It looks
like it's just the ordering of the elements in json_arrayagg() calls
which may actually be a faulty test that needs more ORDER BY clauses
rather than any issues with the code. Nonetheless it's something that
needs to be addressed be
Since the previous update 30 additional patches have been committed
from the CF. This leaves us with 120 Needs Review and 20 Ready for
Committer. There's only a few days left until the end of the month.
* Add comment about startup process getting a free procState array slot always
* Consistent use
It looks like this patch received a review from Andres and hasn't been
updated since. I'm not sure but the review looks to me like it's not
ready to commit and needs some cleanup or at least to check on a few
things.
I guess it's not going to get bumped in the next few days so I'll move
it to the
According to the cfbot this patch needs a rebase
The patch is currently not applying.
And it looks like there hasn't been any discussion since Alvaro's
comments last december. I'm marking the patch Returned with Feedback.
On Fri, 24 Dec 2021 at 16:49, Alvaro Herrera wrote:
>
> On 2021-Dec-21, Mark Dilger wrote:
>
> > Rebased patch attached:
>
Well I still think this would be a good candidate to get reviewed.
But it currently needs a rebase and it's the last day of the CF so I
guess it'll get moved forward again. I don't think "returned with
feedback" is helpful given there's been basically no feedback :(
I see several commits referencing this entry. Can we mark it committed
or are there still chunks of commits to go?
he same transaction.
From 63801cbb7c20676df98be47c52269bb6d7cf7b06 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Thu, 31 Mar 2022 15:49:19 -0400
Subject: [PATCH v5 2/3] Update relfrozenxmin when truncating temp tables
Make ON COMMIT DELETE ROWS reset relfrozenxmin and other table stats
like normal truncate. Otherwise
It looks like it's still not actually building on some compilers. I
see a bunch of warnings as well as an error:
[03:53:24.660] dummy_toaster.c:97:2: error: void function
'dummyDelete' should not return a value [-Wreturn-type]
Also the "publication" regression test needs to be adjusted as it
incl
On Mon, 22 Nov 2021 at 02:14, Andy Fan wrote:
>
> _I_ think there is no way to bypass that. I guess Tom has a bigger plan on
> Var (not only for notnull), but no time to invest in them so far. If
> that is the case,
> personally I think we can go ahead with my method first and continue the
> re
So the last commitfest often runs over and "feature freeze" isn't
scheduled until April 7. Do committers want to keep the commitfest
open until then? Or close it now and focus it only on a few pending
features they're already working on?
--
greg
Patch doesn't apply again...
[image: 1jfj7m.jpg]
The cfbot is testing the last patch posted to this thread which is the
remove-self-own patch which was already committed. I gather that
there's still (at least one) patch under discussion.
Could I suggest reposting the last version of the main patch, perhaps
rebasing it. That way the cfbot would a
This patch has bitrotted, presumably after the other JSON patchset was
applied. It looks like it's failing in the json header file so it may
be as simple as additional functions added on nearby lines.
Please rebase. Reminder, it's the last week of the commitfest so time
is of the essence
This patch has bitrotted due to some other patch affecting trigger.c.
Could you post a rebase?
This is the last week of the CF before feature freeze so time is of the essence.
This patch still has code warnings on the cfbot and I don't think
they're platform-specific:
[00:28:28.236] gram.y: In function ‘base_yyparse’:
[00:28:28.236] gram.y:2851:58: error: passing argument 2 of
‘makeDefElemExtended’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
[00:
101 - 200 of 356 matches
Mail list logo
