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?
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
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)
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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 ;
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
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
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
> >
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
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
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
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)"
>
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
30 matches
Mail list logo
