On Mon, Oct 25, 2021 at 11:59:52AM -0400, Tom Lane wrote:
> I agree that we're not testing that area well enough. Proposed
> patch seems basically OK, but I think the test needs to be stricter
> about what the expected output looks like --- for instance, it
> wouldn't complain if tab_foobar were
On 2021-10-21 03:40, Mark Dilger wrote:
These patches have been split off the now deprecated monolithic
"Delegating superuser tasks to new security roles" thread at [1].
The purpose of these patches is to fix the CREATEROLE escalation
attack vector misfeature. (Not everyone will see CREATEROLE
On Mon, Sep 27, 2021 at 2:02 PM Amit Kapila wrote:
>
> On Sat, Sep 25, 2021 at 3:36 PM Tomas Vondra
> wrote:
> >
> > On 9/25/21 6:23 AM, Amit Kapila wrote:
> > > On Sat, Sep 25, 2021 at 3:30 AM Tomas Vondra
> > > wrote:
> > >>
> > >> On 9/24/21 7:20 AM, Amit Kapila wrote:
> > >>>
> > >>> I
On Thu, Sep 23, 2021 at 10:33 PM Tomas Vondra
wrote:
>
> 7) exprstate_list
>
> I'd just call the field / variable "exprstates", without indicating the
> data type. I don't think we do that anywhere.
Fixed in v34. [1]
>
>
> 8) RfCol
>
> Do we actually need this struct? Why not to track just name
On Mon, Oct 25, 2021 at 4:21 PM Amit Kapila wrote:
>
> On Thu, Oct 21, 2021 at 11:20 AM Dilip Kumar wrote:
> >
> > On Thu, Oct 21, 2021 at 9:11 AM Amit Kapila wrote:
> > >
> >
> > v5-0001, incorporates all the comment fixes suggested by Alvaro. and
> > 0001 is an additional patch which moves
>
On 2021/10/26 04:32, Yura Sokolov wrote:
And among others Adiantum looks best: it is fast even without hardware
acceleration,
No, AES is fast on modern high-end hardware.
on X86 AMD 3700X
type 1024 bytes 8192 bytes 16384 bytes
aes-128-ctr 8963982.50k 11124613.88k
On Tue, Oct 26, 2021 at 6:50 AM Michael Paquier wrote:
>
> On Mon, Oct 25, 2021 at 01:18:26PM -0400, Tom Lane wrote:
> > Robert Haas writes:
> >> ... But while I agree it's good to remove unused stuff in the
> >> master, it doesn't seem like we really need to back-patch it.
> >
> > Yeah,
At Mon, 25 Oct 2021 10:34:27 +0530, Amul Sul wrote in
> On Mon, Oct 25, 2021 at 7:02 AM Kyotaro Horiguchi
> wrote:
> >
> > At Fri, 22 Oct 2021 18:43:52 +0530, Amul Sul wrote in
> > > Any thoughts about the patch posted previously?
> >
> > Honestly, xlogreader looks fine with the current shape.
On Tue, 2021-10-26 at 00:07 +, Bossart, Nathan wrote:
> It feels a bit excessive to introduce a new predefined role just for
> this. Perhaps this could be accomplished with a new function that
> could be granted.
It would be nice if the syntax could be used, since it's pretty
widespread. I
On Tue, Oct 26, 2021 at 1:52 PM Andres Freund wrote:
> On 2021-10-26 13:39:53 +1300, Thomas Munro wrote:
> > According to my crystal ball, seawasp will shortly break again[1][2]
> > and the attached patch will fix it.
>
> That feels lot more convincing though. Based on past experience it's not
On Mon, Oct 25, 2021 at 01:18:26PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> ... But while I agree it's good to remove unused stuff in the
>> master, it doesn't seem like we really need to back-patch it.
>
> Yeah, exactly. I don't see any benefit that's commensurate with
> even a small
On Mon, Oct 25, 2021 at 05:46:57PM +0530, Bharath Rupireddy wrote:
> StreamLog() isn't reached for create and drop slot cases, see [1]. I
> suggest to remove replication_slot != NULL and have Assert(slot_name)
> in GetSlotInformation():
> /*
> * Try to get the starting point from
Hi,
On 2021-10-26 13:39:53 +1300, Thomas Munro wrote:
> On Mon, Sep 27, 2021 at 10:54 AM Thomas Munro wrote:
> > And pushed. Probably won't be the last change and seawasp only tests
> > master, so no back-patch for now.
>
> According to my crystal ball, seawasp will shortly break again[1][2]
>
On Mon, Sep 27, 2021 at 10:54 AM Thomas Munro wrote:
> And pushed. Probably won't be the last change and seawasp only tests
> master, so no back-patch for now.
According to my crystal ball, seawasp will shortly break again[1][2]
and the attached patch will fix it.
[1]
On 10/25/21, 4:40 PM, "Jeff Davis" wrote:
> On Mon, 2021-10-25 at 17:55 -0300, Alvaro Herrera wrote:
>> Maybe you just need pg_checkpointer.
>
> Fair enough. Attached simpler patch that only covers checkpoint, and
> calls the role pg_checkpointer.
It feels a bit excessive to introduce a new
On 10/25/21, 4:29 PM, "Jeff Davis" wrote:
> On Mon, 2021-10-25 at 14:30 -0700, Andres Freund wrote:
>> I don't get the reasoning behind the "except ..." logic. What does
>> this
>> actually protect against? A reasonable use case for this feature is
>> is to
>> monitor memory usage of all
On Mon, 2021-10-25 at 17:55 -0300, Alvaro Herrera wrote:
> Maybe you just need pg_checkpointer.
Fair enough. Attached simpler patch that only covers checkpoint, and
calls the role pg_checkpointer.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/ref/checkpoint.sgml
On Mon, 2021-10-25 at 14:30 -0700, Andres Freund wrote:
> I don't get the reasoning behind the "except ..." logic. What does
> this
> actually protect against? A reasonable use case for this feature is
> is to
> monitor memory usage of all backends, and this restriction practially
> requires
> to
On Mon, Oct 25, 2021 at 11:38:51AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 10/25/21 10:23, Tom Lane wrote:
> >> (Hmmm ... but disk space could
> >> become a problem, particularly on older machines with not so much
> >> disk. Do we really need to maintain a separate checkout for
Anyway, to get back to the original point ...
No one has spoken against moving up the cutoff for pg_dump support,
so I did a very quick pass to see how much code could be removed.
The answer is right about 1000 lines, counting both pg_dump and
pg_upgrade, so it seems like it's worth doing
On 2021-Oct-22, Aleksander Alekseev wrote:
> Hi hackers,
>
> During the discussion [1] it was discovered that we have two
> procedures in execTuples.c that do the same thing:
>
> * MakeSingleTupleTableSlot()
> * MakeTupleTableSlot()
>
> In fact, MakeSingleTupleTableSlot() is simply a wrapper
Hi,
On 2021-10-25 16:02:34 -0400, Tom Lane wrote:
> So I'd like a better idea, but I'm not sure that that one is better.
I guess we could move the prepared-statement handling into a query execution
helper. That could then use a hashtable or something similar to check if a
certain prepared
Hi,
On 2021-10-25 13:42:07 -0700, Jeff Davis wrote:
> Good idea. Attached a patch to remove the superuser check on
> pg_log_backend_memory_contexts(), except in the case when trying to log
> memory contexts of a superuser backend.
I don't get the reasoning behind the "except ..." logic. What
On 10/25/21, 1:43 PM, "Jeff Davis" wrote:
> On Mon, 2021-10-25 at 16:10 +0900, Michael Paquier wrote:
>> Hmm. Why don't you split the patch into two parts that can be
>> discussed separately then? There would be one to remove all the
>> superuser() checks you can think of, and a potential
> On Oct 24, 2021, at 7:49 AM, Bharath Rupireddy
> wrote:
>
> At this point, the idea of having a new role for maintenance work
> looks good. With this patch and Mark Dilger's patch introducing a
> bunch of new predefined roles, one concern is that we might reach to a
> state where we will
On 2021-Oct-25, Jeff Davis wrote:
> But CHECKPOINT right now has an explicit superuser check, and it would
> be nice to be able to avoid that.
>
> It's pretty normal to issue a CHECKPOINT right after a data load and
> before running a performance test, right? Shouldn't there be some way
> to do
On Mon, 2021-10-25 at 13:54 -0400, Stephen Frost wrote:
> Let's not forget that there are already existing non-superusers who
> can
> run things like REFRESH MATERIALIZED VIEW- the owner.
Right, that's one reason why I don't see a particular use case there.
But CHECKPOINT right now has an
On 2021-Oct-25, Tom Lane wrote:
> Yeah, I wasn't too happy with the static bools either. However, each
> function would need its own field in the struct, which seems like a
> maintenance annoyance, plus a big hazard for future copy-and-paste
> changes (ie, copy and paste the wrong flag name ->
On Mon, 2021-10-25 at 16:10 +0900, Michael Paquier wrote:
> Hmm. Why don't you split the patch into two parts that can be
> discussed separately then? There would be one to remove all the
> superuser() checks you can think of, and a potential second to grant
> those function's execution to some
On 10/25/21, 1:29 PM, "Robert Haas" wrote:
> On Mon, Oct 25, 2021 at 3:45 PM Bossart, Nathan wrote:
>> Alright, here is an attempt at that. With this revision, archive
>> libraries are preloaded (and _PG_init() is called), and the archiver
>> is responsible for calling _PG_archive_module_init()
On 10/25/21, 1:33 PM, "Robert Haas" wrote:
> On Mon, Oct 25, 2021 at 3:14 PM Bossart, Nathan wrote:
>> My compiler is complaining about oldXLogAllowed possibly being used
>> uninitialized in CreateCheckPoint(). AFAICT it can just be initially
>> set to zero to silence this warning because it
В Пн, 25/10/2021 в 12:12 -0400, Stephen Frost пишет:
> Greetings,
>
> * Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> > В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> > > I really don't think this is necessary. Similar to PageSetChecksumCopy
> > > and PageSetChecksumInplace, I'm sure
On Mon, Oct 25, 2021 at 3:14 PM Bossart, Nathan wrote:
> My compiler is complaining about oldXLogAllowed possibly being used
> uninitialized in CreateCheckPoint(). AFAICT it can just be initially
> set to zero to silence this warning because it will, in fact, be
> initialized properly when it is
On Mon, Oct 25, 2021 at 3:45 PM Bossart, Nathan wrote:
> Alright, here is an attempt at that. With this revision, archive
> libraries are preloaded (and _PG_init() is called), and the archiver
> is responsible for calling _PG_archive_module_init() to get the
> callbacks. I've also removed the
On 10/25/21 13:06, Andres Freund wrote:
> Hi,
>
> On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
>> Also, I concur with Andrew's point that we'd really have to have
>> buildfarm support. However, this might not be as bad as it seems.
>> In principle we might just need to add resurrected branches
On Mon, Oct 25, 2021 at 11:58:14AM -0400, Stephen Frost wrote:
> As for the specific encryption method to use, using CTR would be simpler
> as it doesn't require access to be block-based, though we would need to
> make sure to not re-use the IV across any of the temporary files being
> created
Andres Freund writes:
> On 2021-10-24 17:10:55 -0400, Tom Lane wrote:
>> +static bool query_prepared = false;
> I wonder if it'd be better to store this in Archive or such. The approach with
> static variables might run into problems with parallel pg_dump at some
> point. These objects
> On Oct 25, 2021, at 11:30 AM, Stephen Frost wrote:
> Consider instead:
>
> CREATE ROLE X;
> CREATE ROLE Y;
> CREATE ROLE Z;
>
> GRANT Y to X;
> GRANT Z to X;
>
> SET ROLE X;
> CREATE EVENT TRIGGER FOR Y do_stuff();
>
> Now, X has explicitly said that they want the event trigger to fire
Hi,
On 2021-10-24 17:10:55 -0400, Tom Lane wrote:
> 0004 is not committable as-is, because it assumes that the source
> server has single-array unnest(), which is not true before 8.4.
> We could fix that by using "oid = ANY(array-constant)" conditions
> instead, but I'm unsure about the
On Mon, Oct 25, 2021 at 2:30 PM Stephen Frost wrote:
> Does membership in role Y cause the event trigger to fire for that role?
> I'd argue that the answer is probably 'yes', but at least it's no longer
> tied back to membership in X (the owner of the trigger). That Noah
> explicitly mentioned
On 10/25/21, 7:50 AM, "Robert Haas" wrote:
> I've pushed 0001 and 0002 but I reversed the order of them and made a
> few other edits.
My compiler is complaining about oldXLogAllowed possibly being used
uninitialized in CreateCheckPoint(). AFAICT it can just be initially
set to zero to silence
Rebased and added a CF entry for Nov CF:
https://commitfest.postgresql.org/35/3376/.
On Thu, Oct 21, 2021 at 07:21 Stan Hu wrote:
> On Wed, Oct 20, 2021 at 9:01 PM Kyotaro Horiguchi
> wrote:
> >
> > lastOverflowedXid is the smallest subxid that possibly exists but
> > possiblly not known to the standby. So if all top-level transactions
> > older than lastOverflowedXid end, that
Hi,
On 2021-10-25 13:58:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> Seems like we need a less quick-and-dirty approach to dealing with
> >> unnecessary simplehash support functions.
>
> > I don't think the problem is unnecessary ones?
>
> I was thinking about the stuff like
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 25, 2021 at 12:20 PM Stephen Frost wrote:
> > > Exactly. That's the main point. Also, it's currently a best practice for
> > > only non-LOGIN roles to have members. The proposed approach invites
> > > folks to
> > >
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Independent of other things, getting to the point where everything can
> > be done in the database without the need for superuser is absolutely a
> > good goal to be striving for, not something to be avoiding.
> > I
> On 25 Oct 2021, at 20:01, Andres Freund wrote:
>
> On 2021-10-25 13:39:44 -0400, Tom Lane wrote:
>> Daniel Gustafsson writes:
>>> Since this will cause integer values to have different textual enum value
>>> representations in 14 and 15+, do we want to skip two numbers by assigning
>>> the
On 2021-10-25 13:39:44 -0400, Tom Lane wrote:
> Daniel Gustafsson writes:
> > Since this will cause integer values to have different textual enum value
> > representations in 14 and 15+, do we want to skip two numbers by assigning
> > the
> > next wait event the integer value of
Andres Freund writes:
> On 2021-10-22 16:32:39 -0400, Tom Lane wrote:
>> Hmm, harder than it sounds. If I remove "inline" from SH_SCOPE then
>> the compiler complains about unreferenced static functions, while
>> if I leave it there than adding pg_noinline causes a complaint about
>> conflicting
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Sun, 2021-10-24 at 21:32 +, Bossart, Nathan wrote:
> > My initial reaction was that members of pg_maintenance should be able
> > to do all of these things (VACUUM, ANALYZE, CLUSTER, REINDEX, and
> > CHECKPOINT).
>
> What about REFRESH
Stephen Frost writes:
> Independent of other things, getting to the point where everything can
> be done in the database without the need for superuser is absolutely a
> good goal to be striving for, not something to be avoiding.
> I don't think that makes superuser become 'dummy', but perhaps
Hi,
Thanks for pushing the error handling cleanup etc!
On 2021-10-22 16:32:39 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> Wonder if we should mark simplehash's grow as noinline? Even with a single
> >> caller it seems better to not inline it to remove register allocator
>
On 10/25/21, 10:18 AM, "Robert Haas" wrote:
> On Mon, Oct 25, 2021 at 1:14 PM Bossart, Nathan wrote:
>> IIUC this would mean that archive modules that need to define GUCs or
>> register background workers would have to separately define a
>> _PG_init() and be loaded via shared_preload_libraries
Greetings,
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> On Sun, Oct 24, 2021 at 3:15 AM Jeff Davis wrote:
> > Add new predefined role pg_maintenance, which can issue VACUUM,
> > ANALYZE, CHECKPOINT.
> >
> > Patch attached.
>
> At this point, the idea of having a new
Daniel Gustafsson writes:
> Since this will cause integer values to have different textual enum value
> representations in 14 and 15+, do we want to skip two numbers by assigning the
> next wait event the integer value of WAIT_EVENT_WAL_WRITE incremented by
> three?
> Or enum integer reuse not
> On 25 Oct 2021, at 19:18, Tom Lane wrote:
>
> Robert Haas writes:
>> ... But while I agree it's good to remove unused stuff in the
>> master, it doesn't seem like we really need to back-patch it.
>
> Yeah, exactly. I don't see any benefit that's commensurate with
> even a small risk of
Hi,
On 2021-10-23 12:57:02 -0700, Jeff Davis wrote:
> Simple patch to implement $SUBJECT attached.
>
> pg_signal_backend seems like the appropriate predefined role, because
> pg_log_backend_memory_contexts() is implemented by a sending signal.
I like the idea of making
On Mon, Oct 25, 2021 at 12:20 PM Stephen Frost wrote:
> > Exactly. That's the main point. Also, it's currently a best practice for
> > only non-LOGIN roles to have members. The proposed approach invites folks
> > to
> > abandon that best practice. I take the two smells as a sign that we'll
Hi,
On 2021-10-25 13:09:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'd really like us to adopt a "default" policy on this. I think it's a waste
> > to spend time every few years arguing what exact versions to drop. I'd much
> > rather say that, unless there are concrete reasons to
Robert Haas writes:
> ... But while I agree it's good to remove unused stuff in the
> master, it doesn't seem like we really need to back-patch it.
Yeah, exactly. I don't see any benefit that's commensurate with
even a small risk of breaking extensions --- and apparently, in
this case that's
On Mon, Oct 25, 2021 at 1:14 PM Bossart, Nathan wrote:
> IIUC this would mean that archive modules that need to define GUCs or
> register background workers would have to separately define a
> _PG_init() and be loaded via shared_preload_libraries in addition to
> archive_library. That doesn't
Hi,
On 2021-10-25 12:43:15 -0400, Tom Lane wrote:
> Agreed, that might be too much work compared to the value. But if we're
> to be selective about support for this, I'm unclear on how we decide
> which platforms are supported --- and, more importantly, how we keep
> that list up to date over
On 10/25/21, 10:02 AM, "Robert Haas" wrote:
> I don't see why this patch should need to make any changes to
> internal_load_library(), PostmasterMain(), SubPostmasterMain(), or any
> other central point of control, and I don't think it should.
> pgarch_archiveXlog() can just load the library at
Andres Freund writes:
> On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
>> It seems like a fresh checkout from the repo would be little more expensive
>> than the current copy-a-checkout process.)
> I haven't looked in detail, but from what I've seen in the logs the
> is-there-anything-new check
On Mon, Oct 25, 2021 at 12:38 PM Tom Lane wrote:
> Um ... the removed symbols were at the end of the WaitEventIO enum,
> so is there really an ABI break? I suppose if an extension contains
> actual references to the removed symbols, it would fail to recompile,
> which'd be annoying for a
Andres Freund writes:
> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>> Yeah. I checked into when it was that we dropped pre-8.0 support
>> from pg_dump, and the answer is just about five years ago (64f3524e2).
>> So moving the bar forward by five releases isn't at all out of line.
>> 8.4 would
Hi,
On 2021-10-25 10:23:40 -0400, Tom Lane wrote:
> Also, I concur with Andrew's point that we'd really have to have
> buildfarm support. However, this might not be as bad as it seems.
> In principle we might just need to add resurrected branches back to
> the branches_to_build list. Given my
On Sun, Oct 24, 2021 at 2:15 AM Bossart, Nathan wrote:
> Here is an attempt at doing this. Archive modules are expected to
> declare _PG_archive_module_init(), which can define GUCs, register
> background workers, etc. This function must at least define the
> archive callbacks. For now, I've
Hi,
On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
> Yeah. I checked into when it was that we dropped pre-8.0 support
> from pg_dump, and the answer is just about five years ago (64f3524e2).
> So moving the bar forward by five releases isn't at all out of line.
> 8.4 would be eight years past EOL
Alvaro Herrera writes:
> I do think you have moved the goalposts: to reiterate what I said above,
> I thought what we wanted was to have *some* server in order to test
> client-side changes with; not to be able to get a server running on
> every possible platform. I'm not really on board with
Robert Haas writes:
> On Wed, Oct 20, 2021 at 10:52 PM Amit Kapila wrote:
>> Remove unused wait events.
> This commit forces a recompile of every extension that knows about the
> integer values assigned to the enums in WaitEventIO. I know of 2
> extensions that are affected by this. I think
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Oct 21, 2021 at 11:05 PM Robert Haas wrote:
> > On Thu, Oct 21, 2021 at 4:29 PM Stephen Frost wrote:
> > > restore_command used to be in recovery.conf, which disappeared with v12
> > > and it now has to go into
On 2021-Oct-25, Tom Lane wrote:
> It's also unclear to me why we'd leave Windows out of this discussion.
> We keep saying we want to encourage Windows-based hackers to contribute,
> so doesn't that require testing it on the same basis as other platforms?
Testing of in-support branches, sure -- I
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, Oct 20, 2021 at 11:27:11AM -0700, Jeff Davis wrote:
> > On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote:
> > > I'd like to have a much clearer understanding of Noah's complaint
> > > first. There are multiple things to consider:
On Wed, Oct 20, 2021 at 10:52 PM Amit Kapila wrote:
> Remove unused wait events.
>
> Commit 464824323e introduced the wait events which were neither used by
> that commit nor by follow-up commits for that work.
This commit forces a recompile of every extension that knows about the
integer values
On 10/25/21, 2:21 AM, "Bharath Rupireddy"
wrote:
> On Mon, Oct 25, 2021 at 12:40 PM Michael Paquier wrote:
>> Hmm. Why don't you split the patch into two parts that can be
>> discussed separately then? There would be one to remove all the
>> superuser() checks you can think of, and a
Greetings,
* Yura Sokolov (y.soko...@postgrespro.ru) wrote:
> В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> > I really don't think this is necessary. Similar to PageSetChecksumCopy
> > and PageSetChecksumInplace, I'm sure we would have functions which are
> > called in the appropriate
On 10/24/21, 11:13 PM, "Jeff Davis" wrote:
> On Sun, 2021-10-24 at 21:32 +, Bossart, Nathan wrote:
>> My initial reaction was that members of pg_maintenance should be able
>> to do all of these things (VACUUM, ANALYZE, CLUSTER, REINDEX, and
>> CHECKPOINT).
>
> What about REFRESH MATERIALIZED
Michael Paquier writes:
> I was thinking on this one over the last couple of days, and doing a
> copy of shared deps from a template within createdb still feels
> natural, as of this patch:
> https://www.postgresql.org/message-id/yxdtl+pfsnqmb...@paquier.xyz
> Would somebody object to the
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 19, 2021 at 02:54:56PM -0400, Stephen Frost wrote:
> > * Sasasu (i...@sasa.su) wrote:
> > > A unified block-based I/O API sounds great. Has anyone tried to do this
> > > before? It would be nice if the front-end tools could also
On Tue, Oct 19, 2021 at 9:06 AM Nitin Jadhav
wrote:
> Thanks for sharing the patch. Overall approach looks good to me. But
> just one concern about using enable_timeout_every() functionality. As
> per my understanding the caller should calculate the first scheduled
> timeout (now + interval) and
Andrew Dunstan writes:
> On 10/25/21 10:23, Tom Lane wrote:
>> (Hmmm ... but disk space could
>> become a problem, particularly on older machines with not so much
>> disk. Do we really need to maintain a separate checkout for each
>> branch? It seems like a fresh checkout from the repo would be
On Sun, Oct 17, 2021 at 10:29:24AM -0400, Tom Lane wrote:
> Also, you haven't explained why the existing (and much safer) recycling
> logic in IpcSemaphoreCreate doesn't solve your problem.
I think I'll drop the diffs, you're right that current proven logic need
not to be changed for such rare
Hi,
On 10/25/21 16:07, Hayk Manukyan wrote:
Hi everyone. I want to do some feature request regarding indexes, as far as
I know this kind of functionality doesn't exists in Postgres. Here is my
problem :
I need to create following indexes:
Create index job_nlp_year_scan on
Alvaro Herrera writes:
> On 2021-Oct-25, Tom Lane wrote:
>> Also, I concur with Andrew's point that we'd really have to have
>> buildfarm support. However, this might not be as bad as it seems.
>> In principle we might just need to add resurrected branches back to
>> the branches_to_build list.
On 10/25/21 11:05, Alvaro Herrera wrote:
>
>> Also, I concur with Andrew's point that we'd really have to have
>> buildfarm support. However, this might not be as bad as it seems.
>> In principle we might just need to add resurrected branches back to
>> the branches_to_build list.
> Well, we
On 10/25/21 10:23, Tom Lane wrote:
>
> Also, I concur with Andrew's point that we'd really have to have
> buildfarm support. However, this might not be as bad as it seems.
> In principle we might just need to add resurrected branches back to
> the branches_to_build list. Given my view of what
Robert Haas writes:
> On Mon, Oct 25, 2021 at 11:00 AM Tom Lane wrote:
>> Actually, I think we do. If I want to test against 7.4, ISTM I want
>> to test against the last released 7.4 version, not something with
>> arbitrary later changes. Otherwise, what exactly is the point?
> 1. You're free
On 10/25/21 11:09, Robert Haas wrote:
> On Mon, Oct 25, 2021 at 11:00 AM Tom Lane wrote:
>> Actually, I think we do. If I want to test against 7.4, ISTM I want
>> to test against the last released 7.4 version, not something with
>> arbitrary later changes. Otherwise, what exactly is the
On Mon, Oct 25, 2021 at 11:00 AM Tom Lane wrote:
> Actually, I think we do. If I want to test against 7.4, ISTM I want
> to test against the last released 7.4 version, not something with
> arbitrary later changes. Otherwise, what exactly is the point?
1. You're free to check out any commit you
On 2021-Oct-25, Tom Lane wrote:
> Roughly speaking, I think the policy should be "no feature bug fixes,
> not even security fixes, for EOL'd branches; only fixes that are
> minimally necessary to make it build on newer platforms". And
> I want to have a sunset provision even for that. Fixing
On Thu, Oct 21, 2021 at 3:29 PM Robert Haas wrote:
> I think the correct fix for this particular problem is just to delete
> the initialization, as in the attached patch. I spent a long time
> studying this today and eventually convinced myself that there's just
> no way these initializations can
Robert Haas writes:
> On Mon, Oct 25, 2021 at 10:23 AM Tom Lane wrote:
>> Roughly speaking, I think the policy should be "no feature bug fixes,
>> not even security fixes, for EOL'd branches; only fixes that are
>> minimally necessary to make it build on newer platforms". And
>> I want to have
On Mon, Oct 25, 2021 at 3:05 AM Amul Sul wrote:
> Ok, did the same in the attached 0001 patch.
>
> There is no harm in calling LocalSetXLogInsertAllowed() calling
> multiple times, but the problem I can see is that with this patch user
> is allowed to call LocalSetXLogInsertAllowed() at the time
On Mon, Oct 25, 2021 at 10:23 AM Tom Lane wrote:
> What concerns me here is that we not get into a position where we're
> effectively still maintaining EOL'd versions. Looking at the git
> history yesterday reminded me that we had such a situation back in
> the early 7.x days. I can see that I
Hi everyone. I want to do some feature request regarding indexes, as far as
I know this kind of functionality doesn't exists in Postgres. Here is my
problem :
I need to create following indexes:
Create index job_nlp_year_scan on ingest_scans_stageing
(`job`,`nlp`,`year`,`scan_id`);
Robert Haas writes:
> Right. Well, we could leave it up to people who care to decide how
> much work they want to do, perhaps. But I do find it annoying that
> pg_dump is supposed to maintain compatibility with server releases
> that I can't easily build. Fortunately I don't patch pg_dump very
>
On Mon, Oct 25, 2021 at 8:29 AM Andrew Dunstan wrote:
> But we don't need to build them on modern platforms, just run them on
> modern platforms, ISTM.
I don't really agree with this.
> Some months ago I built binaries all the way back to 7.2 that with a
> little help run on modern Fedora and
On Sun, Oct 24, 2021 at 5:46 PM Tom Lane wrote:
> Hmm ... I guess the question is how much work we feel like putting
> into that, and how we'd track whether old branches still work,
> and on what platforms. It could easily turn into a time sink
> that's not justified by the value. I do see your
On 10/22/21 19:30, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Fri, Oct 22, 2021 at 3:42 PM Tom Lane wrote:
>>> Anyway, I think the default answer is "revert 92316a458 and keep the
>>> compatibility goalposts where they are". But I wanted to open up a
>>> discussion to see if anyone
1 - 100 of 134 matches
Mail list logo
