On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> values instead of a macro. Should we refactor these pieces
> accordingly? PFA another patch.
I don't see why not for the places you are changing here, we
On 4/12/24 06:44, Tom Lane wrote:
If this patch were producing better results I'd be more excited
about putting more work into it. But on the basis of what I'm
seeing right now, I think maybe we ought to give up on it.
Let me show current cases where users have a profit with this tiny
On Sun, Apr 21, 2024 at 10:36 PM Richard Guo wrote:
> I didn't spend much time digging into it, but I wonder if this Assert is
> sensible. I noticed that before commit 5bf748b86b, the two datatypes
> were not equal to each other either (anyrange vs. int4range).
The assertion is wrong. It is
I came across an assert failure in _bt_preprocess_array_keys regarding
the sanity check on the datatype of the array elements. It can be
reproduced with the query below.
create table t (c int4range);
create unique index on t (c);
select * from t where c in ('(1, 100]'::int4range, '(50,
On 4/20/24 01:47, Robert Haas wrote:
On Thu, Apr 18, 2024 at 7:36 PM David Steele wrote:
Sure -- pg_combinebackup would only need to verify the data that it
uses. I'm not suggesting that it should do an exhaustive verify of every
single backup in the chain. Though I can see how it sounded that
On Friday, April 19, 2024 4:22 PM shveta malik wrote:
> On Fri, Apr 19, 2024 at 11:37 AM shveta malik wrote:
> >
> > On Fri, Apr 19, 2024 at 10:53 AM Bertrand Drouvot
> > wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Apr 18, 2024 at 05:36:05PM +0530, shveta malik wrote:
> > > > Please find v8
On Friday, April 19, 2024 10:54 AM Kuroda, Hayato/黒田 隼人
wrote:
> In your patch, the pg_dump.c was updated. IIUC the main reason was that
> pg_restore executes some queries as single transactions so that ALTER
> SUBSCRIPTION cannot be done, right?
Yes, and please see below for other reasons.
>
> Part of the underlying problem here is that, AFAIK, neither PostgreSQL
> as a piece of software nor we as human beings who operate PostgreSQL
> databases have much understanding of how autovacuum_max_workers should
> be set. It's relatively easy to hose yourself by raising
>
On Mon, Apr 22, 2024 at 12:00 AM Alexander Lakhin wrote:
> From what I can see, the following condition (namely, -l):
> if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
> {
> push @tsoids, $1;
> return 0;
>
Daniel Gustafsson writes:
>> On 6 Apr 2024, at 01:10, Tom Lane wrote:
>> (So now I'm wondering why *only* copperhead has shown this so far.
>> Are our other cross-version-upgrade testing animals AWOL?)
> Clicking around searching for Xversion animals I didn't spot any, but without
> access to
On 4/21/24 17:10, Tom Lane wrote:
> Tomas Vondra writes:
>> On 4/21/24 00:19, Tom Lane wrote:
>>> I'm not suggesting that this is an interesting security vulnerability,
>>> because if you can control the arguments to createdb it's probably
>>> game over long since. But wrapping the arguments is
Tomas Vondra writes:
> On 4/21/24 00:19, Tom Lane wrote:
>> I'm not suggesting that this is an interesting security vulnerability,
>> because if you can control the arguments to createdb it's probably
>> game over long since. But wrapping the arguments is good for
>> delivering on-point error
On 4/21/24 00:19, Tom Lane wrote:
> Tomas Vondra writes:
>> On 4/20/24 22:40, Tom Lane wrote:
>>> Seems reasonable. The alternative could be to remove createdb.c's use
>>> of fmtId() here, but I don't think that's actually better.
>
>> Why? It seems to me this is quite close to e.g.
Hello Thomas and Robert,
20.04.2024 08:56, Thomas Munro wrote:
... it still broke[4]. So I'm not sure what's going on...
From what I can see, the following condition (namely, -l):
if ($path =~ /^pg_tblspc\/(\d+)$/ && -l "$backup_path/$path")
{
On Sat, 20 Apr 2024 at 01:19, Michael Paquier wrote:
> Removing this GUC and making the backend react by default the same way
> as when this GUC was enabled sounds like a sensible route here. This
> stuff is useful.
I definitely agree it's useful. But I feel like changing the default
of the GUC
On 19.04.24 21:24, Tom Lane wrote:
But on the other hand, in my personal experience,
backtrace_on_internal_error would be the right thing in a really large
number of cases.
That's why I thought we could get away with doing it automatically.
Sure, more control would be better. But if we just
16 matches
Mail list logo
