On Mon, Jun 17, 2024 at 07:00:51PM +0200, Michail Nikolaev wrote:
> The same issue may happen in case of CREATE/DROP INDEX CONCURRENTLY as well.
While looking at all that, I've been also curious about this specific
point, and it is indeed possible to finish in a state where a
duplicate key would b
On Thu, 20 Jun 2024 at 18:45, Amit Kapila wrote:
>
> On Wed, Jun 19, 2024 at 8:33 PM vignesh C wrote:
> >
> > On Tue, 18 Jun 2024 at 16:10, Amit Kapila wrote:
> > >
> > >
> > > Agreed and I am not sure which is better because there is a value in
> > > keeping the state name the same for both seq
Hi, Melanie! I'm glad to hear you that you have found a root case of the
problem) Thank you for that!
On 21.06.2024 02:42, Melanie Plageman wrote:
Hi,
If vacuum fails to remove a tuple with xmax older than
VacuumCutoffs->OldestXmin and younger than
GlobalVisState->maybe_needed, it will ERROR o
On 21/06/2024 03:02, Peter Geoghegan wrote:
On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
wrote:
If vacuum fails to remove a tuple with xmax older than
VacuumCutoffs->OldestXmin and younger than
GlobalVisState->maybe_needed, it will ERROR out when determining
whether or not to freeze the tup
It looks useful, for example, it can be used in sorting tests to make them more
interesting. I just have one question. Why are you using SRF_IS_FIRST CALL and
not _PG_init?
Best regards, Stepan Neretin.
On Sun, 2024-06-23 at 17:57 -0700, Gurjeet Singh wrote:
> Is there a desire to have a division operator / that takes dividend
> and divisor of types interval, and results in a quotient of type
> double precision.
>
> This would be helpful in calculating how many times the divisor
> interval can fi
Hi Tristan,
On Fri, 21 Jun 2024 at 18:16, Tristan Partin wrote:
>
> Hey Dave,
>
> I'm a maintainer for Meson, and am happy to help you in any way that
> I reasonably can.
>
Thank you!
>
> Let's start with the state of Windows support in Meson. If I were to
> rank Meson support for platforms, I
On Mon, Jun 24, 2024 at 2:04 PM Laurenz Albe
wrote:
> On Sun, 2024-06-23 at 17:57 -0700, Gurjeet Singh wrote:
> > Is there a desire to have a division operator / that takes dividend
> > and divisor of types interval, and results in a quotient of type
> > double precision.
> >
> > This would be he
Hi
On Sat, 22 Jun 2024 at 17:32, Andres Freund wrote:
> > I don't think it's unreasonable to not support static linking, but I take
> > your point.
>
> Separately from this thread: ISTM that on windows it'd be quite beneficial
> to
> link a few things statically, given how annoying dealing with
On Sun, 23 Jun 2024 at 10:24, fujii.y...@df.mitsubishielectric.co.jp
wrote:
> I attached the POC patch(the second one) which supports avg(int8) whose
> standard format is _numeric type.
Okay, very interesting. So instead of defining the
serialization/deserialization functions to text/binary, you
On Mon, 24 Jun 2024 at 04:38, wrote:
>
> In my local PoC patch, I have modified the output as follows, what do you
> think?
>
> =# EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM test WHERE id1 = 1 AND id2 = 101;
>QUERY PLAN
> -
Hi,
On 2024-06-24 09:54:51 +0100, Dave Page wrote:
> > The old system was a major bottleneck. For one, there was no way to run all
> > tests. And even the tests that one could run, would run serially, leading
> > to
> > exceedingly long tests times. While that could partially be addressed by
> > h
Hi! Looks good to me!
Best regards, Stepan Neretin.
+1 for the idea.
On Mon, 24 Jun 2024 at 11:11, Matthias van de Meent
wrote:
> I think this is too easy to confuse with the pre-existing 'Filter'
> condition, which you'll find on indexes with INCLUDE-d columns or
> filters on non-index columns.
Why not combine them? And both call them Filter? In
Thank you for reviewing.
On Mon, Jun 24, 2024 at 1:27 PM Li Japin wrote:
> + /*
> +* For now we do not support RIGHT_SEMI join in mergejoin or nestloop
> +* join.
> +*/
> + if (jointype == JOIN_RIGHT_SEMI)
> + return;
> +
>
> How about adding some
hi.
the following two queries should return the same result?
SELECT * FROM JSON_query (jsonb 'null', '$' returning jsonb);
SELECT * FROM JSON_value (jsonb 'null', '$' returning jsonb);
I've tried a patch to implement it.
(i raised the issue at
https://www.postgresql.org/message-id/CACJufxFWiCnG3Q
InjectionPointRun() acquires InjectionPointLock, looks up the hash
entry, and releases the lock:
LWLockAcquire(InjectionPointLock, LW_SHARED);
entry_by_name = (InjectionPointEntry *)
hash_search(InjectionPointHash, name,
HA
On 2024-06-24 Mo 12:00 AM, Alexander Lakhin wrote:
Hello hackers,
As recent caiman failures ([1], [2], ...) show, plperl.sql is
incompatible
with Perl 5.40. (The last successful test runs took place when cayman
had Perl 5.38.2 installed: [3].)
FWIW, I've found an already-existing fix for th
Hi,
On Sat, Jun 22, 2024 at 12:48:33PM +, Bertrand Drouvot wrote:
> 1. vacuuming indexes time has been longer on master because with v2, the
> leader
> has been interrupted 342605 times while waiting, then making v2 "faster".
>
> 2. the leader being interrupted while waiting is also already
On Sun, Nov 19, 2023 at 7:48 AM Andres Freund wrote:
>
> On 2023-11-19 02:15:33 +0100, Tomas Vondra wrote:
> >
> > If understand correctly, with the current code (which only gets
> > ShareUpdateExclusiveLock), we may end up in a situation like this
> > (sessions A and B):
> >
> > A: starts "ALTE
On Mon, 24 Jun 2024 at 11:58, Jelte Fennema-Nio wrote:
>
> +1 for the idea.
>
> On Mon, 24 Jun 2024 at 11:11, Matthias van de Meent
> wrote:
> > I think this is too easy to confuse with the pre-existing 'Filter'
> > condition, which you'll find on indexes with INCLUDE-d columns or
> > filters on
On Mon, Jun 24, 2024 at 5:05 PM jian he wrote:
> hi.
> the following two queries should return the same result?
>
> SELECT * FROM JSON_query (jsonb 'null', '$' returning jsonb);
> SELECT * FROM JSON_value (jsonb 'null', '$' returning jsonb);
>
> I've tried a patch to implement it.
> (i raised the
Hi,
On Mon, Jun 24, 2024 at 8:02 PM Stepan Neretin wrote:
> Hi!
>
> I also noticed a very strange difference in behavior in these two queries, it
> seems to me that although it returns a string by default, for the boolean
> operator it is necessary to return true or false
> SELECT * FROM JSON_v
Em dom., 23 de jun. de 2024 às 23:56, Richard Guo
escreveu:
> On Mon, Jun 24, 2024 at 7:51 AM Ranier Vilela wrote:
> > In src/include/access/xlogbackup.h, the field *name*
> > has one byte extra to store null-termination.
> >
> > But, in the function *do_pg_backup_start*,
> > I think that is a m
Em seg., 24 de jun. de 2024 às 00:27, Yugo NAGATA
escreveu:
> On Sun, 23 Jun 2024 22:34:03 -0300
> Ranier Vilela wrote:
>
> > Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela >
> > escreveu:
> >
> > > Em dom., 23 de jun. de 2024 às 22:05, Ranier Vilela <
> ranier...@gmail.com>
> > > escreveu
On Mon, Jun 24, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
wrote:
>
> When testing the patch, I noticed a bug that when reporting the conflict
> after calling ExecInsertIndexTuples(), we might find the tuple that we
> just inserted and report it.(we should only report conflict if there are
> other confl
Hi,
On Mon, Jun 24, 2024 at 7:04 PM jian he wrote:
>
> hi.
> the following two queries should return the same result?
>
> SELECT * FROM JSON_query (jsonb 'null', '$' returning jsonb);
> SELECT * FROM JSON_value (jsonb 'null', '$' returning jsonb);
I get this with HEAD:
SELECT * FROM JSON_query
On Sun, Jun 23, 2024 at 11:52 AM Noah Misch wrote:
>
> > +static void
> > +create_publication(PGconn *conn, struct LogicalRepInfo *dbinfo)
> > +{
>
> > + appendPQExpBuffer(str, "CREATE PUBLICATION %s FOR ALL TABLES",
> > + ipubname_esc);
>
> This tool's do
On Jun 22, 2024, at 14:10, David E. Wheeler wrote:
> I believe the former issue is caused by the latter: The jsonpath
> implementation uses the formatting strings to parse the timestamps[1], and
> since there is no formatting to support offsets with seconds, it doesn’t work
> at all in JSON ti
Hi,
sorry for the delayed reply, I suck at prioritizing things.
Re: Thomas Munro
> OK let me CC Christoph and ask the question this way: hypothetically,
> if RHEL users' PostgreSQL packages became automatically faster than
> Debian users' packages because of default -march choice in the
> toolcha
On Sat, 22 Jun 2024 at 17:35, Andres Freund wrote:
> Hi,
>
> On 2024-06-21 15:36:56 +0100, Dave Page wrote:
> > For giggles, I took a crack at doing that, manually creating .pc files
> for
> > everything I've been working with so far.
>
> Cool!
>
>
> > It seems to work as expected, except that un
Re: To Thomas Munro
> Or Debian might just bump the baseline. PostgreSQL asking for it might
> just be the reason we wanted to hear to make it happen.
Which level would PostgreSQL specifically want? x86-64-v2 or even
x86-64-v3?
Christoph
Hello hackers,
This patch is based on a suggestion from a separate thread [1]:
On Mon, Jun 24, 2024, at 01:46, Michael Paquier wrote:
> Rather unrelated to this patch, still this patch makes the situation
> more complicated in the docs, but wouldn't it be better to add ACL as
> a term in acronyms
On Mon, Jun 24, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
wrote:
>
> When testing the patch, I noticed a bug that when reporting the conflict
> after calling ExecInsertIndexTuples(), we might find the tuple that we
> just inserted and report it.(we should only report conflict if there are
> other confl
On Mon, 24 Jun 2024 at 13:02, Matthias van de Meent
wrote:
> It does not really behave similar: index scan keys (such as the
> id3=101 scankey) don't require visibility checks in the btree code,
> while the Filter condition _does_ require a visibility check, and
> delegates the check to the table
On Mon, Jun 24, 2024 at 8:08 AM wrote:
> > I am unable to decide whether reporting the bound quals is just enough
> to decide the efficiency of index without knowing the difference in the
> number of index tuples selectivity and heap tuple selectivity. The
> difference seems to be a better indica
On 24.06.24 02:34, Michael Paquier wrote:
On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote:
Peter Eisentraut writes:
On 18.06.24 13:43, Ranier Vilela wrote:
I found another implementation of strsep, it seems lighter to me.
I will attach it for consideration, however, I have not done a
On Fri, 21 Jun 2024 at 12:51, Peter Smith wrote:
>
> Hi, Here are some review comments for patch v9-0003
>
> ==
> Commit Message
>
> /fix/fixes/
Fixed
> ==
> 1.
> General. Is tablesync enough?
>
> I don't understand why is the patch only concerned about tablesync?
> Does it make sense to
Hi. Jelte, hackers.
Thank you for your proposal and comments.
> From: Jelte Fennema-Nio
> Sent: Monday, June 24, 2024 6:09 PM
> > 1. Generality
> > I believe we should develop a method that can theoretically apply to any
> aggregate function, even if we cannot implement it immediately. However,
Hi,
While doing some additional testing of (incremental) backups, I ran into
a couple regular failures. After pulling my hair for a couple days, I
realized the issue seems to affect regular backups, and incremental
backups (which I've been trying to test) are likely innocent.
I'm using a simple (
On 6/24/24 12:54, Amit Kapila wrote:
> ...
>>
I'm not sure there are any cases where using SRE instead of AE would cause
problems for logical decoding, but it seems very hard to prove. I'd be very
surprised if just using SRE would not lead to corrupted cache contents in
some
>>
On Mon, Jun 24, 2024 at 4:10 AM Alena Rybakina wrote:
>
> We can fix this by always removing tuples considered dead before
> VacuumCutoffs->OldestXmin. This is okay even if a reconnected standby
> has a transaction that sees that tuple as alive, because it will
> simply wait to replay the removal
On Mon, Jun 24, 2024 at 4:27 AM Heikki Linnakangas wrote:
>
> On 21/06/2024 03:02, Peter Geoghegan wrote:
> > On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
> > wrote:
> >
> >> The repro forces a round of index vacuuming after the standby
> >> reconnects and before pruning a dead tuple whose xm
Heikki Linnakangas writes:
> ... I can't do that, because InjectionPointRun() requires a PGPROC
> entry, because it uses an LWLock. That also makes it impossible to use
> injection points in the postmaster. Any chance we could allow injection
> points to be triggered without a PGPROC entry? Cou
On Sun, Jan 28, 2024 at 4:57 PM Tomas Vondra
wrote:
> For NUM_LOCK_PARTITIONS this is pretty simple (see 0001 patch). The
> LWLock table has 16 partitions by default - it's quite possible that on
> machine with many cores and/or many partitions, we can easily hit this.
> So I bumped this 4x to 64
On Mon, Jun 24, 2024 at 04:12:38PM +0200, Tomas Vondra wrote:
> The important observation is that this only happens if a database is
> created while the backup is running, and that it only happens with the
> FILE_COPY strategy - I've never seen this with WAL_LOG (which is the
> default since PG15).
On 6/24/24 16:53, Melanie Plageman wrote:
> On Mon, Jun 24, 2024 at 4:27 AM Heikki Linnakangas wrote:
>>
>> On 21/06/2024 03:02, Peter Geoghegan wrote:
>>> On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
>>> wrote:
>>>
The repro forces a round of index vacuuming after the standby
r
On Fri, Jun 21, 2024 at 6:52 PM Alena Rybakina
wrote:
> It's hard to tell, but I think it might be one of the good places to apply
> transformation. Let me describe a brief conclusion on the two approaches.
This explanation is somewhat difficult for me to follow. For example:
> In the first app
On 6/24/24 17:14, Nathan Bossart wrote:
> On Mon, Jun 24, 2024 at 04:12:38PM +0200, Tomas Vondra wrote:
>> The important observation is that this only happens if a database is
>> created while the backup is running, and that it only happens with the
>> FILE_COPY strategy - I've never seen this with
On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
wrote:
> We can fix this by always removing tuples considered dead before
> VacuumCutoffs->OldestXmin.
I don't have a great feeling about this fix. It's not that I think
it's wrong. It's just that the underlying problem here is that we have
heap_pa
On Mon, Jun 24, 2024 at 02:32:27PM +0200, Joel Jacobson wrote:
> This patch is based on a suggestion from a separate thread [1]:
>
> On Mon, Jun 24, 2024, at 01:46, Michael Paquier wrote:
>> Rather unrelated to this patch, still this patch makes the situation
>> more complicated in the docs, but w
On Mon, 24 Jun 2024 at 14:42, Jelte Fennema-Nio wrote:
>
> On Mon, 24 Jun 2024 at 13:02, Matthias van de Meent
> wrote:
> > It does not really behave similar: index scan keys (such as the
> > id3=101 scankey) don't require visibility checks in the btree code,
> > while the Filter condition _does_
On Mon, Jun 24, 2024 at 8:44 AM Nathan Bossart
wrote:
> On Mon, Jun 24, 2024 at 02:32:27PM +0200, Joel Jacobson wrote:
> > This patch is based on a suggestion from a separate thread [1]:
> >
> > On Mon, Jun 24, 2024, at 01:46, Michael Paquier wrote:
> >> Rather unrelated to this patch, still this
On Mon, Jun 24, 2024 at 11:28 AM Robert Haas wrote:
> > It needs to transform all similar constants to one type, because some
> > constants of "OR" expressions can belong others, like the numeric and int
> > types. Due to the fact that array structure demands that all types must be
> > belonged
On Thu, Apr 11, 2024 at 01:52:26PM -0400, David E. Wheeler wrote:
> I realize this probably isn´t going to happen for 17, given the freeze,
> but I would very much welcome feedback and pointers to address concerns
> about providing a second directory for extensions and DSOs. Quite a few
> people ha
On Mon, Jun 24, 2024 at 11:44 AM Robert Haas wrote:
> I don't have a great feeling about this fix. It's not that I think
> it's wrong. It's just that the underlying problem here is that we have
> heap_page_prune_and_freeze() getting both GlobalVisState *vistest and
> struct VacuumCutoffs *cutoffs,
On Mon, Jun 24, 2024 at 12:43 PM Peter Geoghegan wrote:
> The problem here is that OldestXmin is supposed to be more
> conservative than vistest, which it almost always is, except in this
> one edge case. I don't think that plugging that hole changes the basic
> fact that there is one source of tr
On Mon, Jun 24, 2024 at 12:09 PM Peter Geoghegan wrote:
> But what about cases like this:
>
> SELECT * FROM mytable WHERE columna = 1_000_000_000 or columna =
> 5_000_000_000; -- columna is int4
>
> This is using two types, of course. 1_000_000_000 is int4, while
> 5_000_000_000 is bigint. If the
On Mon, Jun 24, 2024 at 1:05 PM Robert Haas wrote:
> On Mon, Jun 24, 2024 at 12:43 PM Peter Geoghegan wrote:
> > The problem here is that OldestXmin is supposed to be more
> > conservative than vistest, which it almost always is, except in this
> > one edge case. I don't think that plugging that
On Mon, Jun 24, 2024 at 1:29 PM Robert Haas wrote:
> I am not against handling this kind of case if we can do it, but it's
> more important that the patch doesn't cause gratuitous failures than
> that it handles more cases.
I agree, with the proviso that "avoid gratuitous failures" should
include
On Wed, Apr 3, 2024 at 3:13 AM Alvaro Herrera wrote:
> I support the idea of there being a second location from where to load
> shared libraries ... but I don't like the idea of making it
> runtime-configurable. If we want to continue to tighten up what
> superuser can do, then one of the things
On Mon, Jun 24, 2024 at 1:46 PM Peter Geoghegan wrote:
> BTW, did you know MySQL has long supported the latter? It has a <=>
> operator, which is basically a non-standard spelling of IS NOT
> DISTINCT FROM. Importantly, it is indexable, whereas right now
> Postgres doesn't support indexing IS NOT
Hello,
Hope you are doing well.
I've been playing a bit with the incremental backup feature which might
come as
part of the 17 release, and I think I hit a possible bug in the WAL
summarizer
process.
The issue that I face refers to the summarizer process getting into a hung
state.
When the issue
I'm attaching the files which I missed in the original email.
>
19:34:17.437626 epoll_wait(5, [], 1, 8161) = 0 <8.171542>
19:34:25.610176 rt_sigprocmask(SIG_SETMASK, [URG], NULL, 8) = 0 <0.000334>
19:34:25.611012 openat(AT_FDCWD, "pg_wal/0001000200B3", O_RDONLY) =
-1 ENOENT (No such f
Xcode 16 beta was released on 2024-06-10 and ships with macOS SDK 15.0
[1]. It appears PostgreSQL does not compile due to typedef redefiniton
errors in the regex library:
/tmp/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-Wall -Wmissing-prototypes -Wpointer-a
On Mon, Jun 24, 2024 at 1:47 PM Peter Geoghegan wrote:
> I agree, with the proviso that "avoid gratuitous failures" should
> include cases where a query that got the optimization suddenly fails
> to get the optimization, due only to some very innocuous looking
> change. Such as a change from using
On Fri, Jun 21, 2024 at 11:40 AM Nathan Bossart
wrote:
> Done.
If you look at how the varlistentries begin, there are three separate patterns:
* Some document a single role and start with "Allow doing blah blah blah".
* Some document a couple of rolls so there are several paragraphs,
each begin
On Mon, Jun 17, 2024 at 6:38 PM David E. Wheeler wrote:
> Is it? ISTM that there is the intention not to break things that don’t need
> to be broken, though that doesn’t rule out interface improvements.
I suppose that it's true that we try to avoid gratuitous breakage, but
I feel like it would b
On Mon, Jun 24, 2024 at 2:28 PM Robert Haas wrote:
> On Mon, Jun 24, 2024 at 1:47 PM Peter Geoghegan wrote:
> > I agree, with the proviso that "avoid gratuitous failures" should
> > include cases where a query that got the optimization suddenly fails
> > to get the optimization, due only to some
> On 24 Jun 2024, at 11:14, Stepan Neretin wrote:
>
> Hi! Looks good to me!
Thanks for review. I have this on my TODO for when the tree branches, it
doesn't seem like anything worth squeezing in before then.
--
Daniel Gustafsson
On Wed, 2024-06-19 at 08:53 +0530, Ashutosh Sharma wrote:
> For standalone functions, users can easily adjust the search_path
> settings as needed. However, managing this becomes challenging for
> functions created via extensions. Extensions are relocatable, making
> it difficult to determine and a
On Mon, Jun 24, 2024 at 1:05 PM Robert Haas wrote:
>
> On Mon, Jun 24, 2024 at 12:43 PM Peter Geoghegan wrote:
> > The problem here is that OldestXmin is supposed to be more
> > conservative than vistest, which it almost always is, except in this
> > one edge case. I don't think that plugging tha
It appears in macOS SDK 14.5, there were include guards in
$SDK_ROOT/usr/include/xlocale/_regex.h:
#ifndef _XLOCALE__REGEX_H_
#define _XLOCALE__REGEX_H_
#ifndef _REGEX_H_
#include <_regex.h>
#endif // _REGEX_H_
#include <_xlocale.h>
In macOS SDK 15.5, these include guards are gone:
#ifndef _XLO
On Mon, Jun 24, 2024 at 3:23 PM Melanie Plageman
wrote:
> I had always thought it was because the vacuuming backend's
> GlobalVisState will get updated periodically throughout vacuum and so,
> assuming the oldest running transaction changes, our horizon for
> vacuum would change.
I believe that i
On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
wrote:
>
> If vacuum fails to remove a tuple with xmax older than
> VacuumCutoffs->OldestXmin and younger than
> GlobalVisState->maybe_needed, it will ERROR out when determining
> whether or not to freeze the tuple with "cannot freeze committed
> xm
On Jun 24, 2024, at 1:53 PM, Robert Haas wrote:
> Is "tighten up what the superuser can do" on our list of objectives?
> Personally, I think we should be focusing mostly, and maybe entirely,
> on letting non-superusers do more things, with appropriate security
> controls. The superuser can ultima
Greetings,
While testing pgjdbc I noticed the following
pgdb-1 | Will execute command on database postgres:
pgdb-1 | SELECT pg_drop_replication_slot(slot_name) FROM
pg_replication_slots WHERE slot_name = 'replica_one';
pgdb-1 | DROP USER IF EXISTS replica_one;
pgdb-1 |
On Mon, Jun 24, 2024, at 18:02, David G. Johnston wrote:
> On Mon, Jun 24, 2024 at 8:44 AM Nathan Bossart
> wrote:
>> I think we could omit "i.e. privileges list."
>>
>
> Agreed. Between the docs and code we say "privileges list" once and
> that refers to the dumputIls description of the argum
On Jun 19, 2024, at 05:42, Peter Eisentraut wrote:
>>> https://postgr.es/m/CAH2-Wzm-W6hSn71sUkz0Rem=qdeu7tnfmc7_jg2djrlfef_...@mail.gmail.com
>>>
>>> Theoretically anybody can do this themselves. In practice they don't.
>>> So something as simple as providing automated reports about ABI
>>> chan
On Jun 24, 2024, at 14:51, Robert Haas wrote:
> I suppose that it's true that we try to avoid gratuitous breakage, but
> I feel like it would be weird to document that.
I see how that can seem weird to a committer deeply familiar with the
development process and how things happen. But people ou
On Mon, Jun 24, 2024 at 12:46 PM Joel Jacobson wrote:
> On Mon, Jun 24, 2024, at 18:02, David G. Johnston wrote:
>
> > The page we link to uses "permissions" while we consistently use
> > "privileges" to describe the contents of the list. This seems like an
> > obvious synonym, but as the point
On Jun 19, 2024, at 05:41, Peter Eisentraut wrote:
> This is probably a bit confusing. This might as well mean client application
> code against libpq. Better something like "server plugin code that uses the
> PostgreSQL server APIs".
That works.
> But now we're talking about API. That mig
On Mon, Jun 24, 2024 at 3:37 PM David E. Wheeler wrote:
> I guess the question then is what security controls are appropriate for this
> feature, which after all tells the postmaster what directories to read files
> from. It feels a little outside the scope of a regular user to even be aware
>
On 21/06/2024 02:32, Jacob Champion wrote:
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas wrote:
By "negotiation" I mean the server's response to the startup packet.
I.e. "supported"/"not supported"/"error".
Ok, I'm still a little confused, probably a terminology issue. The
server doesn't
Hi!
Let me join the review process.
I am no expert in execution plans, so there would not be much help in doing
even better optimization. But I can read the code, as a person who is not
familiar
with this area and help making it clear even to a person like me.
So, I am reading v25-0001-Transf
On Mon, Jun 24, 2024 at 3:23 PM Melanie Plageman
wrote:
> Are you more concerned about having a single horizon for pruning or
> about having a horizon that does not move backwards after being
> established at the beginning of vacuuming the relation?
I'm not sure I understand. The most important t
On Jun 24, 2024, at 4:28 PM, Robert Haas wrote:
> As long as the GUC is superuser-only, I'm not sure what else there is
> to do here. The only question is whether there's some reason to
> disallow this even from the superuser, but I'm not quite seeing such a
> reason.
I can switch it back from r
On Mon, Jun 24, 2024 at 3:36 PM Melanie Plageman
wrote:
> One thing I don't understand is why it is okay to freeze the xmax of a
> dead tuple just because it is from an aborted update.
We don't do that with XID-based xmaxs. Though perhaps we should, since
we'll already prune-away the successor tu
On Mon, 24 Jun 2024 at 15:03, fujii.y...@df.mitsubishielectric.co.jp
wrote:
> I see. I maybe got your proposal.
> Refer to your proposal, for avg(int8),
> I create a new native type like state_int8_avg
> with the new typsend/typreceive functions
> and use them to transmit the state value, right?
On Mon, Jun 24, 2024, at 21:51, David G. Johnston wrote:
> On Mon, Jun 24, 2024 at 12:46 PM Joel Jacobson wrote:
>> On Mon, Jun 24, 2024, at 18:02, David G. Johnston wrote:
>>
>> > The page we link to uses "permissions" while we consistently use
>> > "privileges" to describe the contents of the
On Mon, Jun 24, 2024 at 4:42 PM Peter Geoghegan wrote:
>
> On Mon, Jun 24, 2024 at 3:36 PM Melanie Plageman
> wrote:
> > One thing I don't understand is why it is okay to freeze the xmax of a
> > dead tuple just because it is from an aborted update.
>
> We don't do that with XID-based xmaxs. Thou
On Mon, Jun 24, 2024 at 4:36 PM Robert Haas wrote:
> I'm not sure I understand. The most important thing here is fixing the
> bug. But if we have a choice of how to fix the bug, I'd prefer to do
> it by having the pruning code test one horizon that is always correct,
> rather than (as I think the
Hi!
Let me join the review process.
I am no expert in execution plans, so there would not be much help in doing
even better optimization. But I can read the code, as a person who is not
familiar
with this area and help making it clear even to a person like me.
So, I am reading v25-0001-Transf
On Mon, Jun 24, 2024 at 4:51 PM Peter Geoghegan wrote:
>
> On Mon, Jun 24, 2024 at 4:36 PM Robert Haas wrote:
> > I thought the idea was that the GlobalVisTest stuff would force a
> > recalculation now and then, but maybe it doesn't actually do that?
>
> It definitely can do that. Just not in a w
On Mon, Jun 24, 2024 at 1:49 PM Joel Jacobson wrote:
> How about?
>
> +
> + The linked page uses "permissions" while we consistently use the
> synonym
> + "privileges", to describe the contents of the list. For avoidance of
> + doubt and clarity, these two terms are equivalent
On Thu, 11 Apr 2024 at 19:52, David E. Wheeler wrote:
> I realize this probably isn’t going to happen for 17, given the freeze, but I
> would very much welcome feedback and pointers to address concerns about
> providing a second directory for extensions and DSOs. Quite a few people have
> talke
On Mon, 24 Jun 2024 at 18:11, Nathan Bossart wrote:
> At first glance, the general idea seems reasonable to me. I'm wondering
> whether there is a requirement for this directory to be prepended or if it
> could be appended to the end. That way, the existing ones would take
> priority, which migh
On Jun 24, 2024, at 17:17, Jelte Fennema-Nio wrote:
> If you want to only change $libdir during CREATE EXTENSION (or ALTER
> EXTENSION UPDATE), then why not just change it there. And really you'd
> only want to change it when creating an extension from which the
> control file is coming from exte
On Mon, 24 Jun 2024 at 22:42, David E. Wheeler wrote:
> >> BINDIR
> >> DOCDIR
> >> HTMLDIR
> >> PKGINCLUDEDIR
> >> LOCALEDIR
> >> MANDIR
> >>
> >> I can imagine an extension wanting or needing to use any and all of these.
> >
> > Are these really all relevant to backend code?
>
> Oh I think so. Es
Prior to macOS SDK 15, there were include guards in
$SDK_ROOT/usr/include/xlocale/_regex.h:
#ifndef _REGEX_H_
#include <_regex.h>
#endif // _REGEX_H_
#include <_xlocale.h>
In macOS SDK 15.5, these include guards are gone:
#include <_regex.h>
#include <_xlocale.h>
Because _REGEX_H_ w
1 - 100 of 141 matches
Mail list logo
