Hi All,
Kindly check the below scenario with INTERVAL datatype.
postgres=# select interval '01 20:59:59' + interval '00 05:00:01' as
interval;
interval
1 day 26:00:00
(1 row)
Any operation with INTERVAL data, We are changing the interval values as
"60 sec" as "next minute"
"
Hi All,
While using IMMUTABLE functions in index expression, we are getting below
corruption on HEAD.
postgres=# CREATE TABLE tab1 (c1 numeric, c2 numeric);
CREATE TABLE
postgres=# INSERT INTO tab1 values (10, 100);
INSERT 0 1
postgres=# CREATE OR REPLACE FUNCTION func1(var1 numeric)
RETURNS
On Mon, Aug 23, 2021 at 4:29 AM Noah Misch wrote:
> On Wed, Aug 18, 2021 at 10:32:10PM -0700, Noah Misch wrote:
> > On Wed, Aug 18, 2021 at 10:47:24AM -0400, Robert Haas wrote:
> > > On Tue, Aug 10, 2021 at 9:35 AM Robert Haas
> wrote:
> > > > Oh, yeah, I think that works, actually. I was imagin
Hi,
On Thu, Jul 29, 2021 at 9:46 PM Robert Haas wrote:
> On Wed, Jul 28, 2021 at 7:33 AM Amul Sul wrote:
> > I was too worried about how I could miss that & after thinking more
> > about that, I realized that the operation for ArchiveRecoveryRequested
> > is never going to be skipped in the sta
On Mon, Apr 19, 2021 at 2:16 PM Amit Langote
wrote:
> Hi Prabhat,
>
> On Mon, Apr 19, 2021 at 5:13 PM Prabhat Sahu
> wrote:
> >
> > Hi All,
> >
> > Please help me out with my doubt in RANGE partition with TEXT datatype:
> >
> > postgres=# create
Hi All,
Please help me out with my doubt in RANGE partition with TEXT datatype:
postgres=# create table tab1 (col1 text) PARTITION BY RANGE (col1);
CREATE TABLE
postgres=# create table p1 (col1 text);
CREATE TABLE
-- Partition with range from '5' to '10' shows error:
postgres=# alter table tab1
Hi all,
While testing this feature with v20-patch, the server is crashing with
below steps.
Steps to reproduce:
1. Configure master-slave replication setup.
2. Connect to Slave.
3. Execute below statements, it will crash the server:
SELECT pg_prohibit_wal(true);
SELECT pg_prohibit_wal(false);
--
Hi All,
I was testing the feature on top of v3 patch and found the "pg_upgrade"
failure after keeping "alter system read only;" as below:
-- Steps:
./initdb -D data
./pg_ctl -D data -l logs start -c
./psql postgres
alter system read only;
\q
./pg_ctl -D data -l logs stop -c
./initdb -D data2
./pg
On Wed, Apr 29, 2020 at 8:52 AM 曾文旌 wrote:
> 2020年4月27日 下午9:48，Prabhat Sahu 写道：
>
> Thanks Wenjing, for the fix patch for previous issues.
> I have verified the issues, now those fix look good to me.
> But the below error message is confusing(for gtt2).
>
> postgres=# dro
On Fri, May 29, 2020 at 8:30 PM Pavel Stehule
wrote:
>
>
> pá 29. 5. 2020 v 16:45 odesílatel Prabhat Sahu <
> prabhat.s...@enterprisedb.com> napsal:
>
>> Hi All,
>>
>> Please check the below scenario, with pseudotype "anyelement" for IN, OUT
Hi All,
Please check the below scenario, with pseudotype "anyelement" for IN, OUT
parameter and the RETURN record in a function.
postgres=# create table tab1(c1 int, c2 int, c3 timestamp) ;
CREATE TABLE
postgres=# CREATE OR REPLACE FUNCTION func_any(IN anyelement, IN
anyelement, OUT v1 anyelement
obal temp table gtt2 when other backend attached it."?
I mean, without giving extra information for the index attached to that GTT.
On Mon, Apr 27, 2020 at 5:34 PM 曾文旌 wrote:
>
>
> 2020年4月27日 下午5:26，Prabhat Sahu 写道：
>
> Hi Wenjing,
>
> Please check the below scenario
Hi Wenjing,
Please check the below scenario shows different error message with "DROP
TABLE gtt;" for gtt with and without index.
*-- Session1:*postgres=# create global temporary table gtt1 (c1 int);
CREATE TABLE
postgres=# create global temporary table gtt2 (c1 int);
CREATE TABLE
postgres=# creat
ostgres=# DROP TABLE gtt DROP;
DROP TABLE
Does this syntax intensional? If not, we should get a syntax error.
On Fri, Apr 24, 2020 at 10:25 AM Prabhat Sahu
wrote:
> Hi Wenjing,
>
> Please check, the server getting crash with the below scenario(CLUSTER gtt
> using INDEX).
>
> *--
Hi Wenjing,
Please check, the server getting crash with the below scenario(CLUSTER gtt
using INDEX).
*-- Session1:*
postgres=# create global temporary table gtt (c1 integer) on commit
preserve rows;
CREATE TABLE
postgres=# create index idx1 on gtt (c1);
CREATE INDEX
*-- Session2:*
postgres=# cre
=# CLUSTER gtt2 USING idx2;
CLUSTER
In Case2, Case3 we can observe, with the absence of data in GTT, we are
able to "CLUSTER gtt2 USING idx2;" (having partial index)
But why does the same query fail for Case1 (absence of data)?
Thanks,
Prabhat Sahu
>
>
> Wenjing
>
>
&g
> I think this is expected, and user test_gtt does not have permission to
> vacuum the system table.
> This has nothing to do with GTT.
>
> Hi Wenjing, Thanks for the explanation.
Thanks for the new patch. I have verified the crash, Now its resolved.
--
With Regards,
Prabhat Kumar Sahu
Enterpris
Hi Wenjing,
Please check below scenario, we are getting a server crash with "ALTER
TABLE" add column with default value as sequence:
-- Create gtt, exit and re-connect the psql prompt, create sequence, alter
table add a column with sequence.
postgres=# create global temporary table gtt1 (c1 int);
On Fri, Apr 17, 2020 at 2:44 PM 曾文旌 wrote:
>
> I improved the logic of the warning message so that when the gap between
> relfrozenxid of GTT is small,
> it will no longer be alarmed message.
>
Hi Wenjing,
Thanks for the patch(v26), I have verified the previous related issues, and
are working fi
On Wed, Apr 8, 2020 at 1:48 PM 曾文旌 wrote:
>
>
> 2020年4月7日 下午6:22，Prabhat Sahu 写道：
>
> Thanks for review.
>> This parameter should support all types of writing of the bool type like
>> parameter autovacuum_enabled.
>> So I fixed in global_temporary_table_v24-pg1
>
> Thanks for review.
> This parameter should support all types of writing of the bool type like
> parameter autovacuum_enabled.
> So I fixed in global_temporary_table_v24-pg13.patch.
>
Thank you Wenjing for the new patch with the fix and the "VACUUM FULL GTT"
support.
I have verified the above i
Hi Wenjing,
Please check the allowed values for boolean parameter
"on_commit_delete_rows".
postgres=# create global temp table gtt1(c1 int)
with(on_commit_delete_rows='true');
CREATE TABLE
Similarly we can successfully create GTT by using the values as:
'true','false', true, false, 'ON', 'OFF', O
exit from all other sessions.
postgres=# drop table gtt2 ;
DROP TABLE
Kindly let me know if I am missing something.
On Wed, Apr 1, 2020 at 6:26 PM Prabhat Sahu
wrote:
> Hi Wenjing,
> I hope we need to change the below error message.
>
> postgres=# create global temporary table
Hi Wenjing,
I hope we need to change the below error message.
postgres=# create global temporary table gtt(c1 int) on commit preserve
rows;
CREATE TABLE
postgres=# create materialized view mvw as select * from gtt;
ERROR: materialized views must not use global temporary tables* or views*
Anyways
On Wed, Apr 1, 2020 at 8:52 AM 曾文旌 wrote:
>
>
> 2020年3月31日 下午9:59，Prabhat Sahu 写道：
>
> Hi Wenjing,
> Thanks for the new patch.
> I saw with the patch(gtt_v23.patch), we are supporting the new concept
> "global temporary sequence"(i.e. session-specific sequen
Hi Wenjing,
Thanks for the new patch.
I saw with the patch(gtt_v23.patch), we are supporting the new concept
"global temporary sequence"(i.e. session-specific sequence), is this
intentional?
postgres=# create *global temporary sequence* gt_seq;
CREATE SEQUENCE
postgres=# create sequence seq;
CREAT
> Sorry, I introduced this bug in my refactoring.
> It's been fixed.
>
> Wenjing
>
> Hi Wenjing,
This patch(gtt_v21_pg13.patch) is not applicable on PG HEAD, I hope you
have prepared the patch on top of some previous commit.
Could you please rebase the patch which we can apply on HEAD ?
--
With
Hi All,
Please check the behavior of GTT having column with "SERIAL" datatype and
column with default value as "SEQUENCE" as below:
*Session1:*postgres=# create sequence gtt_c3_seq;
CREATE SEQUENCE
postgres=# create global temporary table gtt(c1 int, c2 serial, c3 int
default nextval('gtt_c3_se
义从) wrote:
>
>
> 2020年3月11日 下午3:52，Prabhat Sahu 写道：
>
> On Mon, Mar 9, 2020 at 10:02 PM 曾文旌(义从)
> wrote:
>
>>
>>
>> Fixed in global_temporary_table_v18-pg13.patch.
>>
> Hi Wenjing,
> Thanks for the patch. I have verified the previous
On Thu, Mar 19, 2020 at 3:51 PM wenjing.zwj
wrote:
> postgres=# CREATE LOCAL TEMPORARY TABLE gtt1(c1 serial PRIMARY KEY, c2
> VARCHAR (50) UNIQUE NOT NULL) ON COMMIT DELETE ROWS;
> CREATE TABLE
> postgres=# CREATE LOCAL TEMPORARY TABLE gtt2(c1 integer NOT NULL, c2
> integer NOT NULL,
> postgres(#
On Mon, Mar 16, 2020 at 1:30 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> It seems to be expected behavior: GTT data is private to the session and
> postgres_fdw establish its own session where content of the table is empty.
> But if you insert some data in f_gtt1, then you will
Hi Wenjing,
Please check the below scenario, where the Foreign table on GTT not showing
records.
postgres=# create extension postgres_fdw;
CREATE EXTENSION
postgres=# do $d$
begin
execute $$create server fdw foreign data wrapper postgres_fdw
options (host 'localhost',dbname 'postgres',
Hi Wenjing,
Please check the below combination of GTT with Primary and Foreign key
relations, with the ERROR message.
*Case1:*postgres=# CREATE GLOBAL TEMPORARY TABLE gtt1(c1 serial PRIMARY
KEY, c2 VARCHAR (50) UNIQUE NOT NULL) ON COMMIT *DELETE* ROWS;
CREATE TABLE
postgres=# CREATE GLOBAL TEMP
Hi Wenjing,
Please check the below findings:
After running "TRUNCATE" command, the "relfilenode" field is not changing
for GTT
whereas, for Simple table/Temp table "relfilenode" field is changing after
TRUNCATE.
*Case 1: Getting same "relfilenode" for GTT after and before "TRUNCATE"*
postgres=# c
Hi all,
Please check the below behavior for the "SERIAL" datatype.
postgres=# CREATE TABLE t1(c1 int, c2 serial);
CREATE TABLE
postgres=# insert into t1 values (generate_series(1,3));
INSERT 0 3
postgres=# insert into t1 values (generate_series(4,6));
INSERT 0 3
postgres=# select * from t1;
c1 |
On Mon, Mar 9, 2020 at 10:02 PM 曾文旌(义从) wrote:
>
>
> Fixed in global_temporary_table_v18-pg13.patch.
>
Hi Wenjing,
Thanks for the patch. I have verified the previous issues with
"gtt_v18_pg13.patch" and those are resolved.
Please find below case:
postgres=# create sequence seq;
CREATE SEQUENCE
Hi All,
Kindly check the below scenario.
*Case 1: *
postgres=# CREATE GLOBAL TEMPORARY TABLE gtt1(c1 int) on commit delete rows;
CREATE TABLE
postgres=# CREATE GLOBAL TEMPORARY TABLE gtt2(c1 int) on commit preserve
rows;
CREATE TABLE
postgres=# vacuum gtt1;
VACUUM
postgres=# vacuum gtt2;
VACUUM
p
On Tue, Mar 3, 2020 at 2:11 PM 曾文旌(义从) wrote:
>
>
>
> I fixed in global_temporary_table_v16-pg13.patch.
>
Thank you Wenjing for the patch.
Now we are getting corruption with GTT with below scenario.
postgres=# CREATE GLOBAL TEMPORARY TABLE gtt1(c1 bigint, c2 bigserial) on
commit delete rows;
CR
reference only temporary tables
Thanks,
Prabhat Sahu
On Tue, Feb 25, 2020 at 2:25 PM 曾文旌(义从) wrote:
>
>
> 2020年2月24日 下午5:44，Prabhat Sahu 写道：
>
> On Fri, Feb 21, 2020 at 9:10 PM 曾文旌(义从)
> wrote:
>
>> Hi,
>> I have started testing the "Global temporary table&qu
REATE TABLE
postgres=# create temporary table child2() inherits (parent2);
CREATE TABLE
postgres=# insert into parent2 values(1);
INSERT 0 1
postgres=# insert into child2 values(2);
INSERT 0 1
postgres=# select * from parent2;
a
---
2
(1 row)
postgres=# select * from child2;
a
---
2
(1 row)
Thanks,
Prabhat Sahu
a global temp table
postgres=# create table tab2 (c1 int references gtt1(c1) );
ERROR: referenced relation "gtt1" is not a global temp table
Thanks,
Prabhat Sahu
Hi,
I have started testing the "Global temporary table" feature,
from "gtt_v11-pg13.patch". Below is my findings:
-- session 1:
postgres=# create global temporary table gtt1(a int);
CREATE TABLE
-- seeeion 2:
postgres=# truncate gtt1 ;
ERROR: could not open file "base/13585/t3_16384": No such fi
Hi all,
I would like to share my observation on this PG feature "Block-level
parallel vacuum".
I have tested the earlier patch (i.e v48) with below high-level test
scenarios, and those are working as expected.
- I have played around with these GUC parameters while testing
max_worker_processe
On Wed, Dec 25, 2019 at 8:01 AM Michael Paquier wrote:
> On Tue, Dec 24, 2019 at 05:29:25PM +0530, Prabhat Sahu wrote:
> > While performing below operations with Master-Slave configuration, Slave
> is
> > crashed.
> > Below are the steps to reproduce:
> &g
Hi,
While performing below operations with Master-Slave configuration, Slave is
crashed.
Below are the steps to reproduce:
-- create a Slave using pg_basebackup and start:
./pg_basebackup -v -R -D d2 -p 55510
mkdir /home/centos/ts1
-- Session 1(Master):
./psql postgres -p 55510
CREATE TABLESPAC
Hi,
While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got
a server crash on PG Head+V36_patch.
Changed configuration parameters and Stack trace are as below:
autovacuum = on
max_worker_processes = 4
shared_buffers = 10MB
max_parallel_workers = 8
max_parallel_maintenance_work
On Wed, Dec 18, 2019 at 6:04 PM Amit Kapila wrote:
> On Wed, Dec 18, 2019 at 6:01 PM Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> Hi all,
>>
>> While testing on v36 patch with gist index, I came across below
>> segmentation fault.
>&g
Hi all,
While testing on v36 patch with gist index, I came across below
segmentation fault.
-- PG Head+ v36_patch
create table tab1(c1 int, c2 text PRIMARY KEY, c3 bool, c4 timestamp
without time zone, c5 timestamp with time zone, p point);
create index gist_idx1 on tab1 using gist(p);
create ind
helpful in knowing if the fsync was performed just
> once or twice i.e. whether point #1 is the reason for the panic or point
> #2.
>
I have ran the same testcases with and without patch multiple times with
debug option (log_min_messages = DEBUG1), but this time I am not able to
re
On Wed, Oct 30, 2019 at 9:46 PM Robert Haas wrote:
> On Wed, Oct 30, 2019 at 3:49 AM Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> While testing the Toast patch(PG+v7 patch) I found below server crash.
>> System configuration:
>> VCPUs: 4, RAM: 8GB
Hi All,
While testing the Toast patch(PG+v7 patch) I found below server crash.
System configuration:
VCPUs: 4, RAM: 8GB, Storage: 320GB
This issue is not frequently reproducible, we need to repeat the same
testcase multiple times.
CREATE OR REPLACE FUNCTION toast_chunks_cnt_func(p1 IN text)
RE
On Mon, Jul 8, 2019 at 9:06 PM Robert Haas wrote:
> On Tue, Jun 25, 2019 at 2:19 AM Prabhat Sahu
> wrote:
> > I have tested the TOAST patches(v3) with different storage options
> like(MAIN, EXTERNAL, EXTENDED, etc.), and
> > combinations of compression and out-of-line s
column "b"
than parent
DETAIL: EXTENDED versus MAIN
Thanks,
Prabhat Sahu
On Wed, Jul 3, 2019 at 7:23 AM Amit Langote wrote:
> Hi Prabhat,
>
> On Tue, Jul 2, 2019 at 5:12 PM Prabhat Sahu
> wrote:
> >
> > Hi,
> >
> > In below testcase when I changed
Hi,
In below testcase when I changed the staorage option for root partition,
newly attached partition not including the changed staorage option.
Is this an expected behavior?
postgres=# CREATE TABLE tab1 (c1 INT, c2 text) PARTITION BY RANGE(c1);
CREATE TABLE
postgres=# create table tt_p1 as selec
On Tue, Jun 11, 2019 at 9:47 PM Robert Haas wrote:
> On Tue, May 21, 2019 at 2:10 PM Robert Haas wrote:
> > Updated and rebased patches attached.
>
> And again.
>
Hi Robert,
I have tested the TOAST patches(v3) with different storage options
like(MAIN, EXTERNAL, EXTENDED, etc.), and
combination
Hi All,
While trying to explore on CHR() function in PG,
I found that few of the ASCII values are returning hex number values(like
'\x08', '\x0B')
and few are executing within SQL (i.e. chr(9) => Horizontal tab, chr(10)
=> Line feed) as below example.
postgres=# select 1|| chr(8)|| 2 || chr(9)||
Hi,
I got a failure in pg_dump/pg_restore as below:
pg_dump/pg_restore fails with 'ERROR: schema "public" already exists' for
TAR_DUMP and CUSTOM_DUMP from v94/v95/v96 to v11/master.
-- Take pg_dump in v94/v95/v96:
[prabhat@localhost bin]$ ./pg_dump -f /tmp/*tar_dump_PG94.tar* -Ft postgres
-p 900
Hi All,
Few more findings on to_timestamp() test with HEAD.
postgres[3493]=# select to_timestamp('15-07-1984 23:30:32',' dd- mm-
hh24: mi: ss');
to_timestamp
---
1984-07-15 23:30:32+05:30
(1 row)
postgres[3493]=# select to_timestamp('15-07-*1984* 23:30:32','
Hi All,
I have found below difference in TO_TIMESTAMP results.
postgres[114552]=# select to_timestamp('15-07-1984 23:30:32','dd-mm-
hh24:mi:ss');
to_timestamp
---
1984-07-15 23:30:32+05:30
(1 row)
postgres[114552]=# select to_timestamp('15-07-84 23:30:32','dd-
Hi Hackers,
While testing with PG procedure, I found a memory leak on HEAD, with below
steps:
postgres=# CREATE OR REPLACE PROCEDURE proc1(v1 INOUT INT)
AS $$
BEGIN
commit;
END; $$ LANGUAGE plpgsql;
CREATE PROCEDURE
postgres=# call proc1(10);
WARNING: Snapshot reference leak: Snapshot 0x23678e
Hi,
I have taken pg_dumpall in pg-master and after restoring the dump I am not
able to see the "Access privileges" as below:
Same is reproducible in back branches as well, is this fine ?
CREATE ROLE user1 PASSWORD 'user1' SUPERUSER LOGIN;
CREATE DATABASE db1 OWNER=user1;
GRANT ALL ON DATABASE db
Hi,
I found a segmentation fault on pg master Head with below steps and
stacktrace.
postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID
LANGUAGE SQL
AS $$
select 10;
$$;
CREATE FUNCTION
postgres=# select func1();
server closed the connection unexpectedly
This probably means the server te
On Wed, Mar 7, 2018 at 7:51 PM, Robert Haas wrote:
> On Wed, Mar 7, 2018 at 8:59 AM, Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>>
>> 2018-03-07 19:24:44.263 IST [54400] LOG: background worker "parallel
>> worker" (PID 54482) was terminated by
On Wed, Mar 7, 2018 at 7:16 PM, Robert Haas wrote:
> On Wed, Mar 7, 2018 at 8:13 AM, Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> Hi all,
>>
>> While testing this feature I found a crash on PG head with parallel
>> create index us
Hi all,
While testing this feature I found a crash on PG head with parallel create
index using pgbanch tables.
-- GUCs under postgres.conf
max_parallel_maintenance_workers = 16
max_parallel_workers = 16
max_parallel_workers_per_gather = 8
maintenance_work_mem = 8GB
max_wal_size = 4GB
./pgbench -
Hi all,
I have been continue doing testing of parallel create index patch. So far
I haven't came across any sort of issue or regression with the patches.
Here are few performance number for the latest round of testing - which
is perform on top of 6th Jan patch submitted by Peter.
Testing is done
66 matches
Mail list logo
