On Sat, Dec 28, 2019 at 07:52:55AM +0100, Fabien COELHO wrote:
> >>Why not simply showing the files underneath their directories?
> >>
> >> /path/to/tmp/file1
> >> /path/to/tmp/subdir1/file2
> >>
> >>In which case probably showing the directory itself is not useful,
> >>and the is_dir column coul
On Sat, Dec 28, 2019 at 12:42 AM legrand legrand
wrote:
>
> Hello,
> Thank you for this patch.
>
> I have tried to use an other patch with yours:
> "Planning counters in pg_stat_statements (using pgss_store)"
> https://www.postgresql.org/message-id/CAOBaU_Y12bn0tOdN9RMBZn29bfYYH11b2CwKO1RO7dX9fQ3a
On Thursday, December 26, 2019 8:18:46 PM CET Julien Rouhaud wrote:
> Hello Pierre,
>
> On Thu, Dec 26, 2019 at 5:43 PM Pierre Ducroquet
wrote:
> > The second one was tested on PG 10 and PG 12 (with 48 lines offset). It
> > has on PG12 the same effect it has on a PG10+isAlive patch. Instead of
>
v2 had an Assert that was only correct while experimenting with
eliding right shift. Fixed in v3.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
v3-0001-Use-the-CLZ-instruction-in-AllocSetFreeIndex.patch
Descripti
Hello Justin,
Ok, so this suggests recursing into subdirs, which requires to make a
separate function of the inner loop.
Yea, it suggests that; but, SRF_RETURN_NEXT doesn't make that very easy.
It'd need to accept the fcinfo argument, and pg_ls_dir_files would call it once
for every tuple to
On Fri, Dec 27, 2019 at 10:29:15PM -0500, Tom Lane wrote:
> David Fetter writes:
> > While noodling around with an upcoming patch to remove user-modifiable
> > RULEs, I noticed that WHEN conditions were disallowed from INSTEAD OF
> > triggers for no discernible reason. This patch removes that
> >
On Sat, Dec 28, 2019 at 12:12:30AM -0300, Alvaro Herrera wrote:
> On 2019-Dec-28, David Fetter wrote:
>
> > While noodling around with an upcoming patch to remove user-modifiable
> > RULEs, I noticed that WHEN conditions were disallowed from INSTEAD OF
> > triggers for no discernible reason. This
I recently came across the need for a gcd function (actually I needed
lcm) and was surprised that we didn't have one.
So here one is, using the basic Euclidean algorithm. I made one for
smallint, integer, and bigint.
--
Vik Fearing +33 6 46 75 15 36
ht
On 2019-12-25 12:01, Sergei Kornilov wrote:
Patch does not apply to master. Could you rebase?
done
I noticed one bug:
create table testdrop (i int, b int, m int GENERATED ALWAYS AS ( i*2) stored);
insert into testdrop(i,b) values (3,4);
alter table testdrop alter COLUMN m drop expression ;
a
It can sometimes be useful to match against a superuser in pg_hba.conf.
For example, one could imagine wanting to reject nonsuperuser from a
particular database.
This used to be possible by creating an empty role and matching against
that, but that functionality was removed (a long time ago) by c
Abdul Yadi AH-2 writes:
> As I have published on
> https://abdulyadi.wordpress.com/2019/12/26/reinforce-data-validation-prevent-direct-table-modification/,
> the patch is to have "private_modify" option in table creation. For example:
> CREATE TABLE mytable (id integer) WITH (private_modify=true);
Vik Fearing writes:
> It can sometimes be useful to match against a superuser in pg_hba.conf.
Seems like a reasonable desire.
> Adding another keyword can break backwards compatibility, of course. So
> that is an issue that needs to be discussed, but I don't imagine too
> many people are using
Bonsoir Vik,
I recently came across the need for a gcd function (actually I needed
lcm) and was surprised that we didn't have one.
Why not.
So here one is, using the basic Euclidean algorithm. I made one for
smallint, integer, and bigint.
Should pg provide the LCM as well? Hmmm, probably
On 28/12/2019 19:07, Tom Lane wrote:
> Vik Fearing writes:
>> It can sometimes be useful to match against a superuser in pg_hba.conf.
> Seems like a reasonable desire.
>
>> Adding another keyword can break backwards compatibility, of course. So
>> that is an issue that needs to be discussed, but
We've often talked about the problem that we have no regression test
coverage for psql's tab completion code. I got interested in this
issue while messing with the filename completion logic therein [1],
so here is a draft patch that adds some testing for that code.
This is just preliminary invest
Hello
here is an unexpected error found while testing IVM v11 patches
create table b1 (id integer, x numeric(10,3));
create incremental materialized view mv1
as select id, count(*),sum(x) from b1 group by id;
do $$
declare
i integer;
begin
for i in 1..1
loop
Here's a version which uses an array of directory_fctx, rather than of DIR and
location. That avoids changing the data structure and collatoral implications
to pg_ls_dir().
Currently, this *shows* subdirs of subdirs, but doesn't decend into them.
So I think maybe toplevel subdirs should be shown,
Hello Tom,
We've often talked about the problem that we have no regression test
coverage for psql's tab completion code. I got interested in this
issue while messing with the filename completion logic therein [1],
so here is a draft patch that adds some testing for that code.
This is just pr
On Fri, Dec 20, 2019 at 12:04 AM Andrey Borodin wrote:
> Currently, we can have split brain with the combination of following steps:
> 0. Setup cluster with synchronous replication. Isolate primary from standbys.
> 1. Issue upsert query INSERT .. ON CONFLICT DO NOTHING
> 2. CANCEL 1 during wait fo
On 28/12/2019 19:15, Fabien COELHO wrote:
>
>> So here one is, using the basic Euclidean algorithm. I made one for
>> smallint, integer, and bigint.
>
> Should pg provide the LCM as well? Hmmm, probably not, too likely to
> overflow.
I decided against it for that reason.
> Should there be a NU
John Naylor writes:
> v2 had an Assert that was only correct while experimenting with
> eliding right shift. Fixed in v3.
I think there must have been something wrong with your test that
said that eliminating the right shift from the non-CLZ code made
it slower. It should be an unconditional win
Fabien COELHO writes:
>> We've often talked about the problem that we have no regression test
>> coverage for psql's tab completion code. I got interested in this
>> issue while messing with the filename completion logic therein [1],
>> so here is a draft patch that adds some testing for that cod
On 29.12.2019 00:55, Robert Haas wrote:
On Fri, Dec 20, 2019 at 12:04 AM Andrey Borodin wrote:
Currently, we can have split brain with the combination of following steps:
0. Setup cluster with synchronous replication. Isolate primary from standbys.
1. Issue upsert query INSERT .. ON CONFLICT D
On Fri, Dec 27, 2019 at 04:46:18PM -0300, Alvaro Herrera wrote:
On 2019-Dec-13, Kyotaro Horiguchi wrote:
At Fri, 13 Dec 2019 13:05:41 +0800, Craig Ringer wrote
in
> On Wed, 11 Dec 2019 at 02:08, Alvaro Herrera
> wrote:
>
> > On 2019-Dec-10, Tomas Vondra wrote:
> >
> > > On Tue, Dec 10, 2019
On Sat, Dec 28, 2019 at 6:19 PM Maksim Milyutin wrote:
> The stuckness of backend is not deadlock here. To cancel waiting of
> backend fluently, client is enough to turn off synchronous replication
> (change synchronous_standby_names through server reload) or change
> synchronous replica to anothe
On Tue, Dec 24, 2019 at 7:29 AM Anastasia Lubennikova
wrote:
> We can make this 'opcisbitwise' parameter enum (or char) instead of
> boolean to mark
> "always bitwise", "never bitwise" and "maybe bitwise". Though, I doubt
> if it will be helpful in any real use case.
What would be the difference
On Thu, Dec 26, 2019 at 10:57 AM Justin Pryzby wrote:
> I agree that's better.
> I don't see any reason why the progress params need to be updated atomically.
> So rebasified against your patch.
I am not sure whether it's important enough to make a stink about, but
it bothers me a bit that this i
On Mon, Nov 04, 2019 at 12:02:21PM +1300, Thomas Munro wrote:
> Rebased. I'm planning to commit this soon.
In each installcheck-parallel run under valgrind-3.14.0, I now see ~1200
reports like this:
==00:00:00:28.322 1527557== Source and destination overlap in memcpy(0x1000104,
0x1000104, 4)
==
Hello Tom,
We've often talked about the problem that we have no regression test
coverage for psql's tab completion code. I got interested in this
issue while messing with the filename completion logic therein [1],
so here is a draft patch that adds some testing for that code.
After you rai
Bonjour Vik,
Should there be a NUMERIC version as well? I'd say maybe yes.
I thought about that, too, but also decided against it for this patch.
Hmmm. ISTM that int functions are available for numeric?
I'm wondering what it should do on N, 0 and 0, 0. Raise an error?
Return 0? Return 1?
30 matches
Mail list logo
