[GENERAL] 9.6 beta2 win-x64 download links still point to beta1

[Thomas Kellerer]

Hello,

the Beta2 downloads on 

  http://www.enterprisedb.com/products-services-training/pgdownload
  http://www.enterprisedb.com/products-services-training/pgbindownload

still lead to Beta1 for the Windows 64bit builds. 

All others properly link to beta1

Thomas



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Concerned to discover DOMAINs can be the same as built in types with no escaping

[Justin Dearing]

Hello,

We happen to have in our schema the following domain.

CREATE DOMAIN public.name varchar(50) NOT NULL;

This was done before me. We assumed this was used in many tables in our
app. Then I wrote a function with a return clause like the following:

RETURNS (
id INT,
name name,
other_names name ARRAY
)

This worked fine until CI tried to build this on a postgres 9.3 box (we are
mostly 9.1, but are fixing that). Then it failed.

So then I discovered that there is a built in type called pg_catalog.name
as well as my public.name. Followed by the discovery that you can't have
arrays of domains. This query showed two rows

SELECT typnamespace, typname
FROM pg_catalog.pg_type typ
WHERE typname = 'name';

Then there was wailing and gnashing of teeth, and I made everything
explicitly varchar, and everything was all good, except I have to fix unit
tests. Oh and nothing is actually using our domain, as demonstrated by this
query:

SELECT attrelid::regclass AS table_name,
  attname, atttypid::REGTYPE
  FROM pg_catalog.pg_attribute
  WHERE atttypid::REGTYPE IN ('name', 'public.name')
  ORDER BY atttypid DESC, attrelid::regclass


Based on this, and some consultations with friends who know more about
postgres than I, I'd like to propose that domains not be allowed to be the
same name as built in types or at the very least give a warning. The fact
that I have to quote keywords, but not even need to quote built in types is
bothersome. Here are examples of queries and behaviors I expect


CREATE DOMAIN "INTO" char(5); -- Does work. Should work without a warning.
The error you get for doing it unquoted is sufficient IMHO
CREATE DOMAIN int CHAR(50); -- Does work. Id prefer it not to work.
Alternatively it could work but emit a warning.
CREATE DOMAIN public.int CHAR(50); -- Does work. I could see the argument
for it working, but would prefer it didn't work. Should still emit a
warning its overriding a base

Since I'm returning to postgres after close to a decade, I figured I'd ask
here for feedback before posting to the hackers list.

Regards,

Justin Dearing

Re: [GENERAL] What Causes Access Exclusive Lock?

[Sameer Kumar]

On Fri, 24 Jun 2016, 6:23 a.m. Jeff Janes,  wrote:

> On Thu, Jun 23, 2016 at 10:54 AM, Sameer Kumar 
> wrote:
> >
> >
> > On Fri, 24 Jun 2016, 1:47 a.m. Jeff Janes,  wrote:
> >>
> >> On Thu, Jun 23, 2016 at 8:14 AM, Sameer Kumar 
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I just wanted to understand what are the commands which will acquire
> >> > Access
> >> > Exclusive Lock on a table? In my knowledge below operations will
> acquire
> >> > access exclusive lock:-
> >> >
> >> > 1. VACUUM FULL
> >> > 2. ALTER TABLE
> >> > 3. DROP TABLE
> >> > 4. TRUNCATE
> >> > 5. REINDEX
> >> > 6. LOCK command with Access Exclusive Mode (or no mode specified)
> >> >
> >> > I am using PostgreSQL v9.4.
> >>
> >> A regular VACUUM (not a FULL one), including autovac, will take an
> >> ACCESS EXCLUSIVE lock if it believes there are enough empty
> >> (truncatable) pages at the end of the table to be worth truncating and
> >> returning that storage to the OS. On master it will quickly abandon
> >> the lock if it detects someone else wants it, but that does not work
> >> on a standby.
> >
> >
> > Thanks! This is helpful. I believe going by this explaination I can try
> to
> > reproduce this issue manually.
> >
> > Is this part about regular vacuum acquiring an AccessExclusive Lock
> > documented? I did not see a reference to it on page for Explicit Locking.
>
> Not that I know of.  I don't think any part of the user documentation
> attempts to make an exhaustive list of all actions which take which
> level of locks.  It only provides some illustrative examples.
>


Thanks!
But is it something which is worth mentioning on the page about VACUUM?


> Cheers,
>
> Jeff
>
-- 
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com

Re: [GENERAL] Transaction serialization

[Thomas Munro]

On Fri, Jun 24, 2016 at 4:13 AM, Dusan Milanov  wrote:
> Hi,
>
> A question about transactions: does postgres report serialization errors
> before a transaction is committed? Obviously, it does on commit, but how
> about previous statements? Can there be an ERRCODE_T_R_SERIALIZATION_FAILURE
> error as a response to anything else but the commit?

Yes.  See src/test/isolation/expected/project-manager.out, which shows
how to reach this error:

postgres=# UPDATE person SET is_project_manager = false WHERE person_id = 1;
ERROR:  could not serialize access due to read/write dependencies
among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during write.
HINT:  The transaction might succeed if retried.

-- 
Thomas Munro
http://www.enterprisedb.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] What Causes Access Exclusive Lock?

[Jeff Janes]

On Thu, Jun 23, 2016 at 10:54 AM, Sameer Kumar  wrote:
>
>
> On Fri, 24 Jun 2016, 1:47 a.m. Jeff Janes,  wrote:
>>
>> On Thu, Jun 23, 2016 at 8:14 AM, Sameer Kumar 
>> wrote:
>> >
>> > Hi,
>> >
>> > I just wanted to understand what are the commands which will acquire
>> > Access
>> > Exclusive Lock on a table? In my knowledge below operations will acquire
>> > access exclusive lock:-
>> >
>> > 1. VACUUM FULL
>> > 2. ALTER TABLE
>> > 3. DROP TABLE
>> > 4. TRUNCATE
>> > 5. REINDEX
>> > 6. LOCK command with Access Exclusive Mode (or no mode specified)
>> >
>> > I am using PostgreSQL v9.4.
>>
>> A regular VACUUM (not a FULL one), including autovac, will take an
>> ACCESS EXCLUSIVE lock if it believes there are enough empty
>> (truncatable) pages at the end of the table to be worth truncating and
>> returning that storage to the OS. On master it will quickly abandon
>> the lock if it detects someone else wants it, but that does not work
>> on a standby.
>
>
> Thanks! This is helpful. I believe going by this explaination I can try to
> reproduce this issue manually.
>
> Is this part about regular vacuum acquiring an AccessExclusive Lock
> documented? I did not see a reference to it on page for Explicit Locking.

Not that I know of.  I don't think any part of the user documentation
attempts to make an exhaustive list of all actions which take which
level of locks.  It only provides some illustrative examples.

Cheers,

Jeff


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Transaction serialization

[Dusan Milanov]

Hi,

A question about transactions: does postgres report serialization errors
before a transaction is committed? Obviously, it does on commit, but how
about previous statements? Can there be an
ERRCODE_T_R_SERIALIZATION_FAILURE error as a response to anything else but
the commit?

Best regards,

Dusan Milanov

Re: [GENERAL] What Causes Access Exclusive Lock?

[Sameer Kumar]

On Fri, 24 Jun 2016, 1:54 a.m. Sameer Kumar, 
wrote:

>
>
> On Fri, 24 Jun 2016, 1:47 a.m. Jeff Janes,  wrote:
>
>> On Thu, Jun 23, 2016 at 8:14 AM, Sameer Kumar 
>> wrote:
>> >
>> > Hi,
>> >
>> > I just wanted to understand what are the commands which will acquire
>> Access
>> > Exclusive Lock on a table? In my knowledge below operations will acquire
>> > access exclusive lock:-
>> >
>> > 1. VACUUM FULL
>> > 2. ALTER TABLE
>> > 3. DROP TABLE
>> > 4. TRUNCATE
>> > 5. REINDEX
>> > 6. LOCK command with Access Exclusive Mode (or no mode specified)
>> >
>> > I am using PostgreSQL v9.4.
>>
>> A regular VACUUM (not a FULL one), including autovac, will take an
>> ACCESS EXCLUSIVE lock if it believes there are enough empty
>> (truncatable) pages at the end of the table to be worth truncating and
>> returning that storage to the OS. On master it will quickly abandon
>> the lock if it detects someone else wants it, but that does not work
>> on a standby.
>>
>
> Thanks! This is helpful. I believe going by this explaination I can try to
> reproduce this issue manually.
>

Thanks!
I could reproduce this.

The test setup-

1. I have master and standby databases. To get the error I reduced my
max_streaming_delay to 10s
2. On standby start a new transaction and read data from a very huge table

Begin transaction;
Select count(*) from table_with10k_rows;

3. On master delete rows from the bottom of this table (i.e. the rows
inserted last)

4. Run a vacuum on the table in master (normal vacuum).

5. Go back to the transaction on standby, fire
Select 1;

6. You will see session is disconnected

I repeated this a few times and if I don't run vacuum manually (and wait
for a while) autovacuum would fire and results in similar situation.

I repeated the same steps with REPEATABLE READ isolation level on standby
transaction and I got SQLSTATE 40001 but with detail "User Query might have
needed to see riw versions that must be removed". I have
hot_standby_feedback on.

Thanks!


> Is this part about regular vacuum acquiring an AccessExclusive Lock
> documented? I did not see a reference to it on page for Explicit Locking.
>
>
>> Before version 9.6, if there are bunch of all-visible (but non-empty)
>> pages at the end of the table, then every vacuum will think it can
>> possibly truncate those pages, take the lock, and immediately realize
>> it can't truncate anything and release the lock. On master, this is
>> harmless, but on a standby it can lead to spurious cancellations.  In
>> 9.6, we made it check those pages to see if they actually are
>> truncatable before it takes the lock, then check again after it has
>> the lock to make sure they are still truncatable.  That should greatly
>> decrease the occurrence of such cancellations.
>>
>>
>> Cheers,
>>
>> Jeff
>>
> --
> --
> Best Regards
> Sameer Kumar | DB Solution Architect
> *ASHNIK PTE. LTD.*
>
> 101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533
>
> T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com
>
-- 
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com

Re: [GENERAL] What Causes Access Exclusive Lock?

[Sameer Kumar]

On Fri, 24 Jun 2016, 1:47 a.m. Jeff Janes,  wrote:

> On Thu, Jun 23, 2016 at 8:14 AM, Sameer Kumar 
> wrote:
> >
> > Hi,
> >
> > I just wanted to understand what are the commands which will acquire
> Access
> > Exclusive Lock on a table? In my knowledge below operations will acquire
> > access exclusive lock:-
> >
> > 1. VACUUM FULL
> > 2. ALTER TABLE
> > 3. DROP TABLE
> > 4. TRUNCATE
> > 5. REINDEX
> > 6. LOCK command with Access Exclusive Mode (or no mode specified)
> >
> > I am using PostgreSQL v9.4.
>
> A regular VACUUM (not a FULL one), including autovac, will take an
> ACCESS EXCLUSIVE lock if it believes there are enough empty
> (truncatable) pages at the end of the table to be worth truncating and
> returning that storage to the OS. On master it will quickly abandon
> the lock if it detects someone else wants it, but that does not work
> on a standby.
>

Thanks! This is helpful. I believe going by this explaination I can try to
reproduce this issue manually.

Is this part about regular vacuum acquiring an AccessExclusive Lock
documented? I did not see a reference to it on page for Explicit Locking.


> Before version 9.6, if there are bunch of all-visible (but non-empty)
> pages at the end of the table, then every vacuum will think it can
> possibly truncate those pages, take the lock, and immediately realize
> it can't truncate anything and release the lock. On master, this is
> harmless, but on a standby it can lead to spurious cancellations.  In
> 9.6, we made it check those pages to see if they actually are
> truncatable before it takes the lock, then check again after it has
> the lock to make sure they are still truncatable.  That should greatly
> decrease the occurrence of such cancellations.
>
>
> Cheers,
>
> Jeff
>
-- 
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com

Re: [GENERAL] What Causes Access Exclusive Lock?

[Jeff Janes]

On Thu, Jun 23, 2016 at 8:14 AM, Sameer Kumar  wrote:
>
> Hi,
>
> I just wanted to understand what are the commands which will acquire Access
> Exclusive Lock on a table? In my knowledge below operations will acquire
> access exclusive lock:-
>
> 1. VACUUM FULL
> 2. ALTER TABLE
> 3. DROP TABLE
> 4. TRUNCATE
> 5. REINDEX
> 6. LOCK command with Access Exclusive Mode (or no mode specified)
>
> I am using PostgreSQL v9.4.

A regular VACUUM (not a FULL one), including autovac, will take an
ACCESS EXCLUSIVE lock if it believes there are enough empty
(truncatable) pages at the end of the table to be worth truncating and
returning that storage to the OS. On master it will quickly abandon
the lock if it detects someone else wants it, but that does not work
on a standby.

Before version 9.6, if there are bunch of all-visible (but non-empty)
pages at the end of the table, then every vacuum will think it can
possibly truncate those pages, take the lock, and immediately realize
it can't truncate anything and release the lock. On master, this is
harmless, but on a standby it can lead to spurious cancellations.  In
9.6, we made it check those pages to see if they actually are
truncatable before it takes the lock, then check again after it has
the lock to make sure they are still truncatable.  That should greatly
decrease the occurrence of such cancellations.


Cheers,

Jeff


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] What Causes Access Exclusive Lock?

[Sameer Kumar]

On Thu, Jun 23, 2016 at 11:57 PM Adrian Klaver 
wrote:

> On 06/23/2016 08:14 AM, Sameer Kumar wrote:
> >
> > Hi,
> >
> > I just wanted to understand what are the commands which will acquire
> > Access Exclusive Lock on a table? In my knowledge below operations will
> > acquire access exclusive lock:-
> >
> > 1. VACUUM FULL
> > 2. ALTER TABLE
> > 3. DROP TABLE
> > 4. TRUNCATE
> > 5. REINDEX
> > 6. LOCK command with Access Exclusive Mode (or no mode specified)
> >
> > I am using PostgreSQL v9.4.
>
> https://www.postgresql.org/docs/9.4/static/explicit-locking.html
>
> ACCESS EXCLUSIVE
>

Thanks!
I had checked that and arrived at the list above.

Why I wanted to confirm because, I am facing a situation similar (or rather
same) as what is described in two threads below-

https://www.postgresql.org/message-id/7f74c5ea-6741-44fc-b6c6-e96f18d76...@simply.name

https://www.postgresql.org/message-id/BE95C564-0D49-462A-A57C-4C9DF6238F71%40simply.name

pg_stat_database_conflicts.confl_lock is *non-zero* and connections on
standby (idle in transaction or executing SELECT) are disconnected.

I *do not* see the message -
"User query might have needed to see row versions that must be removed."

But I see disconnection on standby because of a "relation lock" being held
for long.

>From what I understood that if there is a LOCK conflict on standby (between
a session an a WAL replay), it might cause even cause disconnection of an
"idle in transaction" session (which is causing conflict on standby). Is
this right?

My understanding is only Access Exclusive Locks will cause conflicts
against a read-only query. Is that right?

So I checked and confirmed that there is no such operation on master which
would result in Access Exclusive lock.

I am using v9.4.4. Is there a bug which is hitting me or is there any other
kind of query which might cause lock conflict on standby?

The threads above seem to have same issue, but I did not see any conclusive
reason explained in the hacker or admin thread.

>
> >
> >
> > Regards
> > Sameer
> > --
> > --
> > Best Regards
> > Sameer Kumar | DB Solution Architect
> > *ASHNIK PTE. LTD.*
> >
> > 101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533
> >
> > T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com
> >
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
-- 
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com

Re: [GENERAL] What Causes Access Exclusive Lock?

[Adrian Klaver]

On 06/23/2016 08:14 AM, Sameer Kumar wrote:


Hi,

I just wanted to understand what are the commands which will acquire
Access Exclusive Lock on a table? In my knowledge below operations will
acquire access exclusive lock:-

1. VACUUM FULL
2. ALTER TABLE
3. DROP TABLE
4. TRUNCATE
5. REINDEX
6. LOCK command with Access Exclusive Mode (or no mode specified)

I am using PostgreSQL v9.4.


https://www.postgresql.org/docs/9.4/static/explicit-locking.html

ACCESS EXCLUSIVE




Regards
Sameer
--
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com




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


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] What Causes Access Exclusive Lock?

[Sameer Kumar]

Hi,

I just wanted to understand what are the commands which will acquire Access
Exclusive Lock on a table? In my knowledge below operations will acquire
access exclusive lock:-

1. VACUUM FULL
2. ALTER TABLE
3. DROP TABLE
4. TRUNCATE
5. REINDEX
6. LOCK command with Access Exclusive Mode (or no mode specified)

I am using PostgreSQL v9.4.



Regards
Sameer
-- 
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com

Re: [GENERAL] client_min_messages and INFO

[Tom Lane]

Jason Dusek  writes:
> I notice that INFO is not included in the list of settable levels for
> client_min_messages:
> This seems to be true several versions back so I wonder: what is the
> rationale? Is it like the reverse of LOG?

INFO is used for cases where the user specifically requested the message
(VACUUM VERBOSE, for instance).  Arguably, suppressing such a message
would break things, so you can't.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: ERROR: missing chunk number 0 for toast value while using logical decoder.\

[sudalai]

Thank u. 
The problem is because of the commented line.  I forgot about that. 
Now, I uncommented it. It working fine. 
Thank u very much.

-Sudalai




-
sudalai
--
View this message in context: 
http://postgresql.nabble.com/ERROR-missing-chunk-number-0-for-toast-value-while-using-logical-decoder-tp5909194p5909233.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Re: ERROR: missing chunk number 0 for toast value while using logical decoder.\

[Michael Paquier]

On Thu, Jun 23, 2016 at 4:55 PM, sudalai  wrote:
> Thanks for : https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw
> I will upgrade my servers to PostgreSQL 9.5.3, but i want to find the
> problem.
> Please help me.
> I don't have SQL sequence.
> Does anything i can get from server, that will help us to debug the problem?
>
> Here is logical_decoder code:  rep_slot.c
> 

if (isnull)
appendStringInfoString(s, "NiLnUlL");   // Printing null as "NiLnUlL"
//else if (typisvarlena && VARATT_IS_EXTERNAL_ONDISK(origval))
//  appendStringInfoString(s, "unchanged-toast-datum")
Uncomment that.
-- 
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: ERROR: missing chunk number 0 for toast value while using logical decoder.\

[sudalai]

Thanks for : https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw
I will upgrade my servers to PostgreSQL 9.5.3, but i want to find the
problem. 
Please help me.
I don't have SQL sequence.  
Does anything i can get from server, that will help us to debug the problem?

Here is logical_decoder code:  rep_slot.c
  

Thanks in Advance.

-Sudalai



-
sudalai
--
View this message in context: 
http://postgresql.nabble.com/ERROR-missing-chunk-number-0-for-toast-value-while-using-logical-decoder-tp5909194p5909207.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: ERROR: missing chunk number 0 for toast value while using logical decoder.\

[sudalai]

Hi john,

PostgreSQL 9.5.0  has bug !!!,  Does 9.5.0 remove  unconsumed toast rows
need for slot?? 
It is fixed in latest!!!.  

-Sudalai



-
sudalai
--
View this message in context: 
http://postgresql.nabble.com/ERROR-missing-chunk-number-0-for-toast-value-while-using-logical-decoder-tp5909194p5909201.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] ERROR: missing chunk number 0 for toast value while using logical decoder.\

[Michael Paquier]

On Thu, Jun 23, 2016 at 3:38 PM, sudalai  wrote:
>
> I am using PostgresSQL 9.5.0.
> I have customized :
> https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw to get
> result as json. It works fine. suddenly i getting below exception while
> consuming or peeking changes through that logical slot.
> Does postgres removed the  rows needed for that slot??
> Kindly help me to find the problem.
>
> db=# select * from pg_logical_slot_get_changes('lslot',NULL,1);
> ERROR:  missing chunk number 0 for toast value 857563 in pg_toast_782254
> CONTEXT:  slot "lslot", output plugin "rep_slot", in the change callback,
> associated LSN 2E/3C26D6F0

A couple of failures in logical decoding have been fixed in 9.5.2 and
9.5.3 but this one is new, still you had better update... The error is
visibly coming from the code of your plugin per the context message.
Do you have an SQL sequence that allows to reproduce the problem? I
recall playing with a couple of data types with my own plugin but I
never noticed that.
-- 
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] ERROR: missing chunk number 0 for toast value while using logical decoder.\

[John R Pierce]

On 6/22/2016 11:38 PM, sudalai wrote:

I am using PostgresSQL 9.5.0.


while this likely has no bearing on your problem, you really should 
upgrade to 9.5.latest, 9.5.3 is out now.sub version upgrades like 
9.5.0 to 9.5.3 are painless, just upgrade and restart the server with 
the new code.



--
john r pierce, recycling bits in santa cruz



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] client_min_messages and INFO

[Jason Dusek]

Hi List,

I notice that INFO is not included in the list of settable levels for
client_min_messages:


https://www.postgresql.org/docs/9.5/static/runtime-config-logging.html#GUC-CLIENT-MIN-MESSAGES

This seems to be true several versions back so I wonder: what is the
rationale? Is it like the reverse of LOG?

Kind Regards,
  Jason Dusek

[GENERAL] ERROR: missing chunk number 0 for toast value while using logical decoder.\

[sudalai]

I am using PostgresSQL 9.5.0. 
I have customized :
https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw to get
result as json. It works fine. suddenly i getting below exception while
consuming or peeking changes through that logical slot. 
Does postgres removed the  rows needed for that slot??
Kindly help me to find the problem.

db=# select * from pg_logical_slot_get_changes('lslot',NULL,1);
ERROR:  missing chunk number 0 for toast value 857563 in pg_toast_782254
CONTEXT:  slot "lslot", output plugin "rep_slot", in the change callback,
associated LSN 2E/3C26D6F0


 select * from pg_class where relname like 'pg_toast_782254';
-[ RECORD 1 ]---+
relname | pg_toast_782254
relnamespace| 99
reltype | 782273
reloftype   | 0
relowner| 10
relam   | 0
relfilenode | 782272
reltablespace   | 0
relpages| 464
reltuples   | 2066
relallvisible   | 464
reltoastrelid   | 0
relhasindex | t
relisshared | f
relpersistence  | p
relkind | t
relnatts| 3
relchecks   | 0
relhasoids  | f
relhaspkey  | t
relhasrules | f
relhastriggers  | f
relhassubclass  | f
relrowsecurity  | f
relforcerowsecurity | f
relispopulated  | t
relreplident| n
relfrozenxid| 1982173
relminmxid  | 1
relacl  | 
reloptions  | 



Thanks In Advance.



-
sudalai
--
View this message in context: 
http://postgresql.nabble.com/ERROR-missing-chunk-number-0-for-toast-value-while-using-logical-decoder-tp5909194.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general