Re: PostgreSQL Windows 2019 support ?

[david moloney]

Hi,


Correct – I am talking about Windows Server 2019 which has been re-released 
since January 2019.

Windows 2019 isn’t listed as a supported platform on 
https://www.postgresql.org/download/windows/

I’m presuming there’s a qualification process before it’s listed here ? Is this 
in progress ?


Thanks,

David



From: Andres Freund 
Sent: Wednesday 3 April 2019 20:12
To: Tom Lane
Cc: david moloney; pgsql-gene...@postgresql.org
Subject: Re: PostgreSQL Windows 2019 support ?

Hi,

On 2019-04-03 12:43:25 -0400, Tom Lane wrote:
> david moloney  writes:
> > Is PostgreSQL 10+ supported on windows 2019 ?
>
> It is not.  Considering that VS2019 was released yesterday,
> you should have been surprised to get any other answer.

I don't think VS2019 and Windows 2019 are the same thing... And the
latter has been out for longer than yesterday...  I don't know if
anybody has done rigorous testing on it however.

I'd be somewhat surprised if it didn't just work however.

Greetings,

Andres Freund

dbuser acess privileges

[Durgamahesh Manne]

hi

Respected international pgsql team

pershing=# grant INSERT on public.hyd to ravi;
GRANT
i have granted insert command access to non superuser(ravi)
pershing=> insert into hyd (id,name) values('2','delhi');
INSERT 0 1
here data inserted


pershing=# grant UPDATE on public.hyd to ravi;
GRANT
i have granted update command access to non superuser(ravi)

pershing=> update public.hyd set id = 3 where name = 'hyderabad';
ERROR:  permission denied for relation hyd
please let me know what is the issue with update command

Re: dbuser acess privileges

[Ron]

On 4/4/19 5:07 AM, Durgamahesh Manne wrote:

hi
Respected international pgsql team

pershing=# grant INSERT on public.hyd to ravi;
GRANT
i have granted insert command access to non superuser(ravi)
pershing=> insert into hyd (id,name) values('2','delhi');
INSERT 0 1
here data inserted


pershing=# grant UPDATE on public.hyd to ravi;
GRANT
i have granted update command access to non superuser(ravi)

pershing=> update public.hyd set id = 3 where name = 'hyderabad';
ERROR:  permission denied for relation hyd
please let me know what is the issue with update command


Are there any triggers on public.hyd which modify other tables?

--
Angular momentum makes the world go 'round.

Re: dbuser acess privileges

[Durgamahesh Manne]

On Thu, Apr 4, 2019 at 3:55 PM Ron  wrote:

> On 4/4/19 5:07 AM, Durgamahesh Manne wrote:
> > hi
> > Respected international pgsql team
> >
> > pershing=# grant INSERT on public.hyd to ravi;
> > GRANT
> > i have granted insert command access to non superuser(ravi)
> > pershing=> insert into hyd (id,name) values('2','delhi');
> > INSERT 0 1
> > here data inserted
> >
> >
> > pershing=# grant UPDATE on public.hyd to ravi;
> > GRANT
> > i have granted update command access to non superuser(ravi)
> >
> > pershing=> update public.hyd set id = 3 where name = 'hyderabad';
> > ERROR:  permission denied for relation hyd
> > please let me know what is the issue with update command
>
> Are there any triggers on public.hyd which modify other tables?
>
> --
> Angular momentum makes the world go 'round.
>
>
> Hi
there are no triggers on public.hyd table

Regards
durgamahesh manne

Re: dbuser acess privileges

[Durgamahesh Manne]

On Thu, Apr 4, 2019 at 4:14 PM Durgamahesh Manne 
wrote:

>
>
>
> On Thu, Apr 4, 2019 at 3:55 PM Ron  wrote:
>
>> On 4/4/19 5:07 AM, Durgamahesh Manne wrote:
>> > hi
>> > Respected international pgsql team
>> >
>> > pershing=# grant INSERT on public.hyd to ravi;
>> > GRANT
>> > i have granted insert command access to non superuser(ravi)
>> > pershing=> insert into hyd (id,name) values('2','delhi');
>> > INSERT 0 1
>> > here data inserted
>> >
>> >
>> > pershing=# grant UPDATE on public.hyd to ravi;
>> > GRANT
>> > i have granted update command access to non superuser(ravi)
>> >
>> > pershing=> update public.hyd set id = 3 where name = 'hyderabad';
>> > ERROR:  permission denied for relation hyd
>> > please let me know what is the issue with update command
>>
>> Are there any triggers on public.hyd which modify other tables?
>>
>> --
>> Angular momentum makes the world go 'round.
>>
>>
>> Hi
> there are no triggers on public.hyd table
>
> Regards
> durgamahesh manne
>
>
>

 Hi

i found that there was bug for grant access on update command for non
superusers

grant access on update command worked fine on 9.3 version


please i request you to fix grant access bug on update command for
nonsupeuser asap in the next pg version 10.8



Regards

durgamahesh manne

RE: dbuser acess privileges

[Patrick FICHE]

Hi,

If I’m not wrong, UPDATE requires SELECT permission as the UPDATE statement 
needs to read the data to be updated.
So, you should probably add GRANT SELECT and you get it work.

Regards,

Patrick Fiche
Database Engineer, Aqsacom Sas.
c. 33 6 82 80 69 96

[01-03_AQSA_Main_Corporate_Logo_JPEG_White_Low.jpg]

From: Durgamahesh Manne 
Sent: Thursday, April 4, 2019 12:07 PM
To: pgsql-general@lists.postgresql.org
Subject: dbuser acess privileges

hi

Respected international pgsql team

pershing=# grant INSERT on public.hyd to ravi;
GRANT
i have granted insert command access to non superuser(ravi)
pershing=> insert into hyd (id,name) values('2','delhi');
INSERT 0 1
here data inserted


pershing=# grant UPDATE on public.hyd to ravi;
GRANT
i have granted update command access to non superuser(ravi)

pershing=> update public.hyd set id = 3 where name = 'hyderabad';
ERROR:  permission denied for relation hyd
please let me know what is the issue with update command

Re: dbuser acess privileges

[Ron]

You'd think the implicit SELECT perm of that table for the explicit use of 
UPDATE would be covered by GRANT UPDATE.


On 4/4/19 7:25 AM, Patrick FICHE wrote:


Hi,

If I’m not wrong, UPDATE requires SELECT permission as the UPDATE 
statement needs to read the data to be updated.


So, you should probably add GRANT SELECT and you get it work.

Regards,

*Patrick Fiche*

Database Engineer, Aqsacom Sas.

*c.*33 6 82 80 69 96

01-03_AQSA_Main_Corporate_Logo_JPEG_White_Low.jpg 

*From:* Durgamahesh Manne 
*Sent:* Thursday, April 4, 2019 12:07 PM
*To:* pgsql-general@lists.postgresql.org
*Subject:* dbuser acess privileges

hi

Respected international pgsql team

pershing=# grant INSERT on public.hyd to ravi;

GRANT

i have granted insert command access to non superuser(ravi)

pershing=> insert into hyd (id,name) values('2','delhi');

INSERT 0 1

here data inserted

pershing=# grant UPDATE on public.hyd to ravi;

GRANT

i have granted update command access to non superuser(ravi)

pershing=> update public.hyd set id = 3 where name = 'hyderabad';

ERROR:  permission denied for relation hyd

please let me know what is the issue with update command



--
Angular momentum makes the world go 'round.

RE: dbuser acess privileges

[Patrick FICHE]

Here is the extract of documentation relative to GRANT UPDATE

UPDATE
Allows UPDATE of any 
column, or the specific columns listed, of the specified table. (In practice, 
any nontrivial UPDATE command will require SELECT privilege as well, since it 
must reference table columns to determine which rows to update, and/or to 
compute new values for columns.) SELECT ... FOR UPDATE and SELECT ... FOR SHARE 
also require this privilege on at least one column, in addition to the SELECT 
privilege. For sequences, this privilege allows the use of the nextval and 
setval functions. For large objects, this privilege allows writing or 
truncating the object.
Regards,

Patrick Fiche
Database Engineer, Aqsacom Sas.
c. 33 6 82 80 69 96

[01-03_AQSA_Main_Corporate_Logo_JPEG_White_Low.jpg]

From: Ron 
Sent: Thursday, April 4, 2019 2:50 PM
To: pgsql-general@lists.postgresql.org
Subject: Re: dbuser acess privileges

You'd think the implicit SELECT perm of that table for the explicit use of 
UPDATE would be covered by GRANT UPDATE.
On 4/4/19 7:25 AM, Patrick FICHE wrote:
Hi,

If I’m not wrong, UPDATE requires SELECT permission as the UPDATE statement 
needs to read the data to be updated.
So, you should probably add GRANT SELECT and you get it work.

Regards,

Patrick Fiche
Database Engineer, Aqsacom Sas.
c. 33 6 82 80 69 96

[01-03_AQSA_Main_Corporate_Logo_JPEG_White_Low.jpg]

From: Durgamahesh Manne 

Sent: Thursday, April 4, 2019 12:07 PM
To: 
pgsql-general@lists.postgresql.org
Subject: dbuser acess privileges

hi

Respected international pgsql team

pershing=# grant INSERT on public.hyd to ravi;
GRANT
i have granted insert command access to non superuser(ravi)
pershing=> insert into hyd (id,name) values('2','delhi');
INSERT 0 1
here data inserted


pershing=# grant UPDATE on public.hyd to ravi;
GRANT
i have granted update command access to non superuser(ravi)

pershing=> update public.hyd set id = 3 where name = 'hyderabad';
ERROR:  permission denied for relation hyd
please let me know what is the issue with update command




--
Angular momentum makes the world go 'round.

Re: dbuser acess privileges

[Durgamahesh Manne]

*From:* Durgamahesh Manne 
*Sent:* Thursday, April 4, 2019 12:07 PM
*To:* pgsql-general@lists.postgresql.org
*Subject:* dbuser acess privileges



hi



Respected international pgsql team



pershing=# grant INSERT on public.hyd to ravi;

GRANT

i have granted insert command access to non superuser(ravi)

pershing=> insert into hyd (id,name) values('2','delhi');

INSERT 0 1

here data inserted





pershing=# grant UPDATE on public.hyd to ravi;

GRANT

i have granted update command access to non superuser(ravi)



pershing=> update public.hyd set id = 3 where name = 'hyderabad';

ERROR:  permission denied for relation hyd

please let me know what is the issue with update command



On Thu, Apr 4, 2019 at 5:55 PM Patrick FICHE 
wrote:

> Hi,
>
>
>
> If I’m not wrong, UPDATE requires SELECT permission as the UPDATE
> statement needs to read the data to be updated.
>
> So, you should probably add GRANT SELECT and you get it work.
>
>
>
> Regards,
>
>
>
> *Patrick Fiche*
>
> Database Engineer, Aqsacom Sas.
>
> *c.* 33 6 82 80 69 96
>
>
>
> [image: 01-03_AQSA_Main_Corporate_Logo_JPEG_White_Low.jpg]
> 
>
>
>
>
>
>
>

 Hi  Patrick Fiche  as per your info

Grant access on update command is worked  AFTER I DID EXECUTE THIS   GRANT
SELECT ON TABLE(hyd)  for non superuser in 10.6


But

 in 9.3 versionGrant access on update command is worked  EVEN I DID NOT
EXECUTE THIS   GRANT SELECT ON TABLE(hyd)  for non superuser


Regards

Durgamahesh Manne

Re: PostgreSQL Windows 2019 support ?

[David Rowley]

On Thu, 4 Apr 2019 at 22:15, david moloney  wrote:
> Windows 2019 isn’t listed as a supported platform on 
> https://www.postgresql.org/download/windows/
>
> I’m presuming there’s a qualification process before it’s listed here ?  Is 
> this in progress ?

That process is having a buildfarm member running the operating system
( https://buildfarm.postgresql.org/ ), to which there is currently
not.  If you're interested enough and have the means, then you can
register and run one.

-- 
 David Rowley   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: dbuser acess privileges

[Tom Lane]

Durgamahesh Manne  writes:
> On Thu, Apr 4, 2019 at 5:55 PM Patrick FICHE 
> wrote:
>> If I’m not wrong, UPDATE requires SELECT permission as the UPDATE
>> statement needs to read the data to be updated.

>  in 9.3 versionGrant access on update command is worked  EVEN I DID NOT
> EXECUTE THIS   GRANT SELECT ON TABLE(hyd)  for non superuser

I don't think so.

regression=# create table t1 (f1 int, f2 int);
CREATE TABLE
regression=# create user joe;
CREATE ROLE
regression=# grant update on table t1 to joe;
GRANT
regression=# \c - joe
You are now connected to database "regression" as user "joe".
regression=> update t1 set f1 = 1;
UPDATE 0
regression=> update t1 set f1 = 1 where f2 = 3;
ERROR:  permission denied for relation t1
regression=> select version();
version 


 PostgreSQL 9.3.25 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 
20120313 (Red Hat 4.4.7-23), 64-bit
(1 row)


It's acted that way for a very very long time.

regards, tom lane

Re: stale WAL files?

[Rob Sargent]

> On Apr 3, 2019, at 5:23 PM, Rene Romero Benavides  
> wrote:
> 
> 
> 
> On Wed, Apr 3, 2019 at 1:05 PM Rob Sargent  > wrote:
> 
> 
>> On Apr 1, 2019, at 9:20 PM, Rene Romero Benavides > > wrote:
>> 
>> 
>> On Mon, Apr 1, 2019 at 6:30 PM Rene Romero Benavides 
>> mailto:rene.romer...@gmail.com>> wrote:
>> 
>> On Sat, Mar 30, 2019 at 5:03 PM Gmail > > wrote:
>> 
>> 
>> > On Mar 30, 2019, at 10:54 AM, Gmail > > > wrote:
>> > 
>> > 
>>  On Mar 29, 2019, at 6:58 AM, Michael Paquier >  > wrote:
>> >>> 
>> >>> On Thu, Mar 28, 2019 at 09:53:16AM -0600, Rob Sargent wrote:
>> >>> This is pg10 so it's pg_wal.  ls -ltr
>> >>> 
>> >>> 
>> >>> -rw---. 1 postgres postgres 16777216 Mar 16 16:33
>> >>> 00010CEA00B1
>> >>> -rw---. 1 postgres postgres 16777216 Mar 16 16:33
>> >>> 00010CEA00B2
>> >>> 
>> >>> ... 217 more on through to ...
>> >>> 
>> >>> -rw---. 1 postgres postgres 16777216 Mar 16 17:01
>> >>> 00010CEA00E8
>> >>> -rw---. 1 postgres postgres 16777216 Mar 16 17:01
>> >>> 00010CEA00E9
>> >>> -rw---. 1 postgres postgres 16777216 Mar 28 09:46
>> >>> 00010CEA000E
>> > I’m now down to 208 Mar 16 WAL files so they are being processed (at least 
>> > deleted).  I’ve taken a snapshot of the pg_wal dir such that I can see 
>> > which files get processed. It’s none of the files I’ve listed previously
>> 
>> Two more have been cleaned up.  001C and 001D generated at 16:38 Mar 16
>> 
>> 
>> 
>> Please share your complete postgresql.conf file and the results from this 
>> query: 
>> SELECT * FROM pg_settings;
>> has someone in the past configured wal archiving?
>> You've ran out of disk space as this log message you shared states:
>> No space left on device
>> what's the output of df -h
>> 
>> -- 
>> El genio es 1% inspiración y 99% transpiración.
>> Thomas Alva Edison
>> http://pglearn.blogspot.mx/ 
>> 
>> 
>> BTW , how spread apart are checkpoints happening? do you have stats on that? 
>> maybe they're too spread apart and that's why WAL files cannot be recycled 
>> rapidly enough?  
>> -- 
>> El genio es 1% inspiración y 99% transpiración.
>> Thomas Alva Edison
>> http://pglearn.blogspot.mx/ 
>> 
> two attempts (one in-line, one with attachement) at sending postgresql.conf 
> and pg_settings report have been sent to a moderator.
> 
> 
> 
> As per your configuration :
> max_wal_size = 50GB
> this seems to be the cause for the WAL files piling up.
> 
> this has been declared twice, the last one is taking effect.

That’s an interesting catch.  Thank you.  I’ll have that reverted that to 
default.
Note that the WAL files are all the default 16M however.
Currently we’re down to 88 Mar 16 WAL files.  My inclination is to wait this 
out, to see if all of Mar 16 goes away quietly then reset our backups.


 
> -- 
> El genio es 1% inspiración y 99% transpiración.
> Thomas Alva Edison
> http://pglearn.blogspot.mx/ 
> 

How serial primary key numbers are assigned

[Rich Shepard]

Just out of curiosity, how does postgres assign serial primary key
identifiers when rows are inserted in multiple, separate working sessions?

I'm populating tables using INSERT INTO statements in separate working
sessions and see that the assigned id numbers are sequential in each
session, but have large gaps from one session to the next. I don't care what
id numbers are assigned yet would like to know how the starting number for
each session is determined, just because I expected the numbers to be
continuous.

Regards,

Rich

Re: How serial primary key numbers are assigned

[Adrian Klaver]

On 4/4/19 11:04 AM, Rich Shepard wrote:

Just out of curiosity, how does postgres assign serial primary key
identifiers when rows are inserted in multiple, separate working sessions?

I'm populating tables using INSERT INTO statements in separate working
sessions and see that the assigned id numbers are sequential in each
session, but have large gaps from one session to the next. I don't care 
what

id numbers are assigned yet would like to know how the starting number for
each session is determined, just because I expected the numbers to be
continuous.


See:

https://www.postgresql.org/docs/11/sql-createsequence.html

The relevant part:

"Unexpected results might be obtained if a cache setting greater than 
one is used for a sequence object that will be used concurrently by 
multiple sessions. Each session will allocate and cache successive 
sequence values during one access to the sequence object and increase 
the sequence object's last_value accordingly. Then, the next cache-1 
uses of nextval within that session simply return the preallocated 
values without touching the sequence object. So, any numbers allocated 
but not used within a session will be lost when that session ends, 
resulting in “holes” in the sequence."


Regards,

Rich






--
Adrian Klaver
adrian.kla...@aklaver.com

Re: How serial primary key numbers are assigned

[Rich Shepard]

On Thu, 4 Apr 2019, Adrian Klaver wrote:


See:
https://www.postgresql.org/docs/11/sql-createsequence.html


Thanks, Adrian.

My web searches did not find this URL, only results on how to set up
automatic serial id generation.

Regards,

Rich

Re: How serial primary key numbers are assigned

[Adrian Klaver]

On 4/4/19 11:27 AM, Rich Shepard wrote:

On Thu, 4 Apr 2019, Adrian Klaver wrote:


See:
https://www.postgresql.org/docs/11/sql-createsequence.html


Thanks, Adrian.

My web searches did not find this URL, only results on how to set up
automatic serial id generation.


Well serial is basically a macro for:

https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-SERIAL


"CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename (
colname integer NOT NULL DEFAULT nextval('tablename_colname_seq')
);
ALTER SEQUENCE tablename_colname_seq OWNED BY tablename.colname;
"







Regards,

Rich






--
Adrian Klaver
adrian.kla...@aklaver.com

Re: CVE-2019-9193 about COPY FROM/TO PROGRAM

[Tom Lane]

Jeremy Schneider  writes:
> I'm all for having clear documentation about the security model in
> PostgreSQL, but I personally wouldn't be in favor of adding extra
> wording to the docs just to pacify concerns about a CVE which may have
> been erroneously granted by an assigning authority, who possibly should
> have done better due diligence reviewing the content. Particularly if
> there's any possibility that the decision to assign the number can be
> appealed/changed, though admittedly I know very little about the CVE
> process.

Just FYI, we have filed a dispute with Mitre about the CVE, and also
reached out to trustwave to try to find out why they filed the CVE
despite the earlier private discussion.

regards, tom lane

Re: CVE-2019-9193 about COPY FROM/TO PROGRAM

[Magnus Hagander]

On Thu, Apr 4, 2019 at 9:45 PM Tom Lane  wrote:

> Jeremy Schneider  writes:
> > I'm all for having clear documentation about the security model in
> > PostgreSQL, but I personally wouldn't be in favor of adding extra
> > wording to the docs just to pacify concerns about a CVE which may have
> > been erroneously granted by an assigning authority, who possibly should
> > have done better due diligence reviewing the content. Particularly if
> > there's any possibility that the decision to assign the number can be
> > appealed/changed, though admittedly I know very little about the CVE
> > process.
>
> Just FYI, we have filed a dispute with Mitre about the CVE, and also
> reached out to trustwave to try to find out why they filed the CVE
> despite the earlier private discussion.
>

The original author has also pretty much acknowledged in comments on his
blog and on twitter that it's not actually a vulnerability. (He doesn't
agree with the design decision, which is apparently enough for a high
scoring CVE registration).

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

RE: Recommendation to run vacuum FULL in parallel

[Kevin Brannen]

From: Perumal Raj 

So conclude the requirement here , The only way to parallelism is multiple 
script. And no need to do REINDEX exclusively.
Question : Do we need to consider  Table dependencies while preparing script in 
order to avoid table locks during vacuum full ?

We have a small bash script (see below) that get the list of tables and their 
sizes, sorted smallest to largest, and do “vacuum full” one at a time because 
(as someone else pointed out) this is very I/O intensive. That order also helps 
to ensure we finish because some of our installs are at the edge of running out 
of space (an issue we’re dealing with). I probably wouldn’t have a problem 
doing 2 at a time, but we do this in the middle of the night when activity is 
lowest and it only takes 1-2 hours, so we’re good with it. It sounds like you 
have a lot more data though.

You might also consider putting the data into different tablespaces which are 
spread over multiple disks to help I/O. If you can, use SSD drives, they help 
with speed quite a bit. 😊

Don’t worry about table dependencies. This is a physical operation, not a data 
operation.

HTH,
Kevin

$PGPATH/psql -t -c "
WITH s AS (SELECT nspname || '.' || relname AS TABLE_NAME, 
pg_total_relation_size(c.oid) AS total_bytes
  FROM pg_class c
  LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
  WHERE relkind = 'r' AND nspname NOT IN ( 'pg_catalog', 
'information_schema' )
  ORDER BY 2 )
SELECT table_name FROM s
" |
while read t ; do echo "" ; echo $t; $PGPATH/vacuumdb -w -z -f -t $t ; done
###
This e-mail transmission, and any documents, files or previous e-mail messages 
attached to it, may contain confidential information. If you are not the 
intended recipient, or a person responsible for delivering it to the intended 
recipient, you are hereby notified that any disclosure, distribution, review, 
copy or use of any of the information contained in or attached to this message 
is STRICTLY PROHIBITED. If you have received this transmission in error, please 
immediately notify us by reply e-mail, and destroy the original transmission 
and its attachments without reading them or saving them to disk. Thank you.

Re: CVE-2019-9193 about COPY FROM/TO PROGRAM

[Andres Freund]

Hi

On 2019-04-04 21:50:41 +0200, Magnus Hagander wrote:
> On Thu, Apr 4, 2019 at 9:45 PM Tom Lane  wrote:
> 
> > Jeremy Schneider  writes:
> > > I'm all for having clear documentation about the security model in
> > > PostgreSQL, but I personally wouldn't be in favor of adding extra
> > > wording to the docs just to pacify concerns about a CVE which may have
> > > been erroneously granted by an assigning authority, who possibly should
> > > have done better due diligence reviewing the content. Particularly if
> > > there's any possibility that the decision to assign the number can be
> > > appealed/changed, though admittedly I know very little about the CVE
> > > process.
> >
> > Just FYI, we have filed a dispute with Mitre about the CVE, and also
> > reached out to trustwave to try to find out why they filed the CVE
> > despite the earlier private discussion.
> >
> 
> The original author has also pretty much acknowledged in comments on his
> blog and on twitter that it's not actually a vulnerability. (He doesn't
> agree with the design decision, which is apparently enough for a high
> scoring CVE registration).

Btw, the xp_cmdshell thing the author references several times?
It can be enabled via tsql if you have a privileged account.

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017

and it allows to execute shell code (as a specified user) even when not
a sysadmin:
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/xp-cmdshell-transact-sql?view=sql-server-2017#xp_cmdshell-proxy-account

Greetings,

Andres Freund

Re: logical replication - negative bitmapset member not allowed

[Peter Eisentraut]

On 2019-04-01 23:43, Alvaro Herrera wrote:
> Maybe the replica identity of a table got set to a unique index on oid?
> Or something else involving system columns?  (If replication is
> otherwise working, the I suppose there's a separate publication that's
> having the error; the first thing to isolate would be to see what tables
> are involved in that publication).

Looking through the code, the bms_add_member() call in
logicalrep_read_attrs() does not use the usual
FirstLowInvalidHeapAttributeNumber offset, so that seems like a possible
problem.

However, I can't quite reproduce this.  There are various other checks
that prevent this scenario, but it's plausible that with a bit of
whacking around you could hit this error message.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Seeded Replication

[Peter Eisentraut]

On 2019-04-03 13:44, Lou Tseng wrote:
> However, our database is about 200G and it will take a long time to
> complete the initial data copy.  We would like to manually seed the
> subscriber database with data dump and then turn on the subscription
> like depesz showed in this
> post 
> https://www.depesz.com/2017/02/07/waiting-for-postgresql-10-logical-replication/
>  .

I doubt you will get a huge speedup, since the dump and the initial data
copy use the same COPY command internally.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: logical replication - negative bitmapset member not allowed

[Tim Clarke]

On 04/04/2019 22:37, Peter Intrauterine wrote:
> On 2019-04-01 23:43, Alvaro Herrera wrote:
>> Maybe the replica identity of a table got set to a unique index on oid?
>> Or something else involving system columns?  (If replication is
>> otherwise working, the I suppose there's a separate publication that's
>> having the error; the first thing to isolate would be to see what tables
>> are involved in that publication).
> Looking through the code, the bms_add_member() call in
> logicalrep_read_attrs() does not use the usual
> FirstLowInvalidHeapAttributeNumber offset, so that seems like a possible
> problem.
>
> However, I can't quite reproduce this.  There are various other checks
> that prevent this scenario, but it's plausible that with a bit of
> whacking around you could hit this error message.
>

Promise I've not been whacking around..


Tim Clarke



Main: +44 (0)1376 503500 | Fax: +44 (0)1376 503550
Web: https://www.manifest.co.uk/



Minerva Analytics Ltd
9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | England



Copyright: This e-mail may contain confidential or legally privileged 
information. If you are not the named addressee you must not use or disclose 
such information, instead please report it to 
ad...@minerva.info
Legal:  Minerva Analytics is the trading name of: Minerva Analytics
Ltd: Registered in England Number 11260966 & The Manifest Voting Agency Ltd: 
Registered in England Number 2920820 Registered Office at above address. Please 
Click Here >> for further information.