Hi,
On Sat, Jun 25, 2022 at 10:19:30AM -0500, Justin Pryzby wrote:
> commit f2553d43060edb210b36c63187d52a632448e1d2 says >=1500 in a few places,
> but in pg_upgrade says <=1500, which looks wrong for upgrades from v15.
> I think it should say <= 1400.
>
> On Wed, Feb 02, 2022 at 02:01:23PM
Hi,
On 2022-06-26 10:48:24 +0800, Julien Rouhaud wrote:
> Anyway, per the nearby discussions I don't see much interest, especially not
> in
> the context of varlena identifiers (I should have started a different thread,
> sorry about that), so I don't think it's worth investing more efforts into
On Thu, Jun 23, 2022 at 10:19:44AM -0400, Robert Haas wrote:
> On Thu, Jun 23, 2022 at 6:13 AM Julien Rouhaud wrote:
>
> > And should record_in / record_out use the logical position, as in:
> > SELECT ab::text FROM ab / SELECT (a, b)::ab;
> >
> > I would think not, as relying on a possibly
On Tue, May 17, 2022 at 3:31 PM Thomas Munro wrote:
> On Mon, May 16, 2022 at 3:45 PM Japin Li wrote:
> > Maybe use the __illumos__ macro more accurity.
> >
> > +#elif defined(WAIT_USE_EPOLL) && defined(HAVE_SYS_SIGNALFD_H) && \
> > + !defined(__sun__)
>
> Thanks, updated, and with a new
Having a superuser.conf file could also be used to solve another issue
- currently, if you remove the SUPERUSER attribute from all users your
only option to get it back would be to run in single-user mode. With
conf file one could add an "always" option there which makes any
matching user
What are your ideas of applying a change similar to above to actually
being a superuser ?
That is adding a check for "superuser being currently available" to
function superuser() in
./src/backend/utils/misc/superuser.c ?
It could be as simple as a flag that can be set only at startup for
maximum
> On 23 Jun 2022, at 00:27, Nikolay Samokhvalov wrote:
>
> Since you're talking to yourself, just wanted to support you – this is an
> important thing, definitely should be very useful for many projects; I hope
> to find time to test it in the next few days.
Thanks Nikolay!
> On 23 Jun
> On 25 Jun 2022, at 03:08, Hannu Krosing wrote:
>
> Currently the file system access is controlled via being a SUPREUSER
My 2 cents. Ongoing work on making superuser access unneeded seems much more
relevant to me.
IMO superuser == full OS access available from postgres process. I think
On Thu, Jun 23, 2022 at 10:45:40PM -0700, Noah Misch wrote:
> On Wed, Jun 22, 2022 at 11:03:22AM -0400, Andrew Dunstan wrote:
> > On 2022-06-22 We 03:21, Noah Misch wrote:
> > > On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
> > >> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
>
Now that I've gotten your attention..
I expect pg_upgrade to fail if I run it twice in a row.
It would be reasonable if it were to fail during the "--check" phase,
maybe by failing like this:
| New cluster database "..." is not empty: found relation "..."
But that fails to happen if the cluster
On Sat, Jun 25, 2022 at 1:13 AM Andres Freund wrote:
>
> On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
> > Currently the file system access is controlled via being a SUPREUSER
> > or having the pg_read_server_files, pg_write_server_files and
> > pg_execute_server_program roles. The problem
(please don't top-post. Surely you've been around this community long
enough to know that)
On Sat, Jun 25, 2022 at 1:59 AM Hannu Krosing wrote:
> My understanding was that unless activated by admin these changes
> would change nothing.
>
That is assuming you can do this with changing just a
commit f2553d43060edb210b36c63187d52a632448e1d2 says >=1500 in a few places,
but in pg_upgrade says <=1500, which looks wrong for upgrades from v15.
I think it should say <= 1400.
On Wed, Feb 02, 2022 at 02:01:23PM +0100, Peter Eisentraut wrote:
> --- a/src/bin/pg_dump/pg_dump.c
> +++
On Fri, Jun 24, 2022 at 9:30 PM Andres Freund wrote:
> If we "inline" RelFileNumber, it's probably worth reorder the members so that
> the most distinguishing elements come first, to make it quicker to detect hash
> collisions. It shows up in profiles today...
>
> I guess it should be blockNum,
> On 25 Jun 2022, at 01:28, Justin Pryzby wrote:
>
> But what I wrote already shows what you want.
Just tested that, you are right. My version was printing name, I didn't know
regproc prints so nice definition.
> this is my latest.
>
On Sat, 25 Jun 2022 at 04:39, Tom Lane wrote:
>
> Well, if we want to clean this up a bit rather than just doing the
> minimum safe fix ... I spent some time why we were bothering with the
> FLATCOPY step at all, rather than just mutating the Query* pointer.
> I think the reason is to not fail if
On Sat, 25 Jun 2022 at 10:18, Heikki Linnakangas wrote:
>
> On 24/06/2022 04:43, Andres Freund wrote:
> > On 2022-06-23 22:03:27 +0300, Heikki Linnakangas wrote:
> >> In summary, I think we should:
> >> - commit and backpatch Simon's
> >> just_remove_TransactionIdIsKnownCompleted_call.v1.patch
>
On 24/06/2022 04:43, Andres Freund wrote:
On 2022-06-23 22:03:27 +0300, Heikki Linnakangas wrote:
In summary, I think we should:
- commit and backpatch Simon's
just_remove_TransactionIdIsKnownCompleted_call.v1.patch
- fix pg_xact_status() to check TransactionIdIsInProgress()
- in v15, remove
Hello Thomas,
llvmjit.c:1233:81: error: too few arguments to function call, expected 3,
have 2
ref_gen =
LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
Ah yes, I hadn't seen that one yet. That function grew a "Dispose"
argument, which we can just pass
19 matches
Mail list logo
