[GENERAL] UUID datatype

Hi Is there a way to implicit SELECT on UUID datatype in uppercase ? Please Thanks Sridhar

Re: [GENERAL] UUID datatype

On Mon, May 30, 2016 at 4:25 PM, Sridhar N Bamandlapally wrote: > Hi > > Is there a way to implicit SELECT on UUID datatype in uppercase ? You could always cast an UUID back to text and use that with upper(), though you are not explaining what you are tying to achieve: =# select upper(gen_random_

[GENERAL] How to find business partners from PostgreSQL communities?

I have a business plan for my product and services both developed on top of PostgreSQL. I am looking for partners to form a start-up to work on these product and services. My ideal candidates are PostgreSQL endorsers. In addition, I hope the technical details in my plan be exposed during the disc

Re: [GENERAL] UUID datatype

This I got, need some implicit way, like maybe in RULE on SELECT can we write this ? Thanks Sridhar OpenText On Mon, May 30, 2016 at 1:05 PM, Michael Paquier wrote: > On Mon, May 30, 2016 at 4:25 PM, Sridhar N Bamandlapally > wrote: > > Hi > > > > Is there a way to implicit SELECT on UUID data

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

On Sun, May 29, 2016 at 10:04 PM, Karsten Hilbert wrote: >>> I submitted slides to pgcon site, but it usually takes awhile, so you can >>> download our presentation directly >>> http://www.sai.msu.su/~megera/postgres/talks/pgcon-2016-fts.pdf > > Looking at slide 39 (attached) I get the impression

[GENERAL] After replication failover: could not read block X in file Y read only 0 of 8192 bytes

I'm running a streaming replication setup with PostgreSQL 9.5.2 and have started seeing these errors on a few INSERTs: ERROR: could not read block 8 in file "base/3884037/3885279": read only 0 of 8192 bytes on a few tables. If I look at that specific file, it's only 6 blocks long: # ls

Re: [GENERAL] How to find business partners from PostgreSQL communities?

On 05/30/2016 02:15 AM, CN wrote: I have a business plan for my product and services both developed on top of PostgreSQL. I am looking for partners to form a start-up to work on these product and services. My ideal candidates are PostgreSQL endorsers. In addition, I hope the technical details in

Re: [GENERAL] How to find business partners from PostgreSQL communities?

Hi! Adrian, Many thanks for your wisdom! I am going to take a look of "announce" archive in order to get some idea of its characteristics. On Mon, May 30, 2016, at 10:30 PM, Adrian Klaver wrote: > Deliver a working prototype of an idea that other folks can look at. I do have product and servic

[GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

Hi, I need to understand something: Lets assume I have a table t5 with 1'000'000 rows: (postgres@[local]:5432) [sample] > select count(*) from t5; count - 100 (1 row) Time: 2363.834 ms (postgres@[local]:5432) [sample] > I get the file for that table: postgres@pg_essentia

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

On Mon, May 30, 2016 at 11:35 AM, Daniel Westermann < daniel.westerm...@dbi-services.com> wrote: > Hi, > > I need to understand something: Lets assume I have a table t5 with > 1'000'000 rows: > > (postgres@[local]:5432) [sample] > select count(*) from t5; > count > - > 100 > (1 row)

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

Hi Daniel: On Mon, May 30, 2016 at 5:35 PM, Daniel Westermann wrote: > I get the file for that table: ... > Then I delete the file: Well, you corrupted the database and invoked undefined behaviour ( not exactly, but postgres is not designed for this ). > No issue in the log. This is probably co

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

On 30 May 2016 at 16:35, Daniel Westermann < daniel.westerm...@dbi-services.com> wrote: ... > Then I delete the file: > ... > No issue in the log. This is probably coming from the cache, isn't it? Is > this intended and safe? > Postgres manages your data for you. What you're doing is not a suppo

Re: [GENERAL] pglogical

On 25 May 2016 at 18:26, Igor Neyman wrote: > This page: > > http://2ndquadrant.com/en/resources/pglogical/ > > states that “It has also been submitted to PostgreSQL core as a candidate > for inclusion in PostgreSQL 9.6.” > > > > So, my question is: did pglogical make the 9.6 core, or not? > pgl

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

Daniel Westermann writes: > Then I delete the file: > postgres@pg_essentials_p1:/u02/pgdata/PG1/base/16422/ [PG1] rm 32809 There's a reason why the database directory is not readable/writable by unprivileged users: it's to prevent them from doing dumb things like that. People who do have write

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

On 30.05.2016 18:35, Daniel Westermann wrote: Hi, I need to understand something: Lets assume I have a table t5 with 1'000'000 rows: (postgres@[local]:5432) [sample] > select count(*) from t5; count - 100 (1 row) Time: 2363.834 ms (postgres@[local]:5432) [sample] > I get the

[GENERAL] Silent data loss in its pure form

Following this bug reports from redhat https://bugzilla.redhat.com/show_bug.cgi?id=845233 it rising some dangerous issue: If on any reasons you data file is zeroed after some power loss(it is the most known issue on XFS in the past) when you do select count(*) from you_table you got zero if yo

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 May 2016 17:35:34 +0200 (CEST), Daniel Westermann (daniel.westerm...@dbi-services.com) wrote about "[GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?" (in <184509399.5590018.1464622534207.java

Re: [GENERAL] Silent data loss in its pure form

On Mon, May 30, 2016 at 10:57 AM, Alex Ignatov wrote: > Following this bug reports from redhat > https://bugzilla.redhat.com/show_bug.cgi?id=845233 > > it rising some dangerous issue: > > If on any reasons you data file is zeroed after some power loss(it is the > most known issue on XFS in the pas

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

>>> >>>On Mon, 30 May 2016 17:35:34 +0200 (CEST), Daniel Westermann >>>(daniel.westerm...@dbi-services.com) wrote about "[GENERAL] Deleting a >>>table file does not raise an error when the table is touched >>>afterwards, why?" (in >>><184509399.5590018.1464622534207.javamail.zim...@dbi-service

Re: [GENERAL] swarm of processes in BIND state?

On Sat, May 28, 2016 at 11:32 AM, hubert depesz lubaczewski wrote: > On Sat, May 28, 2016 at 10:32:15AM -0700, Jeff Janes wrote: >> If that wasn't informative, I'd attach to one of the processes with >> the gdb debugger and get a backtrace. (You might want to do that a >> few times, just in case

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 30 May 2016 19:49:36 +0200 (CEST), Daniel Westermann (daniel.westerm...@dbi-services.com) wrote about "Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?" (in <1247360337.5599235.1464630576430

Re: [GENERAL] plugin dev, oid to pointer map

> On 30 May 2016, at 02:43, Julien Rouhaud wrote: > > On 29/05/2016 22:10, Attila Soki wrote: >> i am about to begin with postgresql plugin development. >> H Currently i'm trying to become somewhat familiar with the postgresql >> sources. > >> >> Without going too deep into details about the

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

Daniel Westermann writes: > - if the above is correct why does PostgreSQL only write a partial file back > to disk/wal? For me this still seems dangerous as potentially nobody will > notice it In quiescent circumstances, Postgres wouldn't have written anything at all, and the file would have d

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

On Mon, May 30, 2016 at 2:50 PM, Tom Lane wrote: > Daniel Westermann writes: > > - if the above is correct why does PostgreSQL only write a partial file > back to disk/wal? For me this still seems dangerous as potentially nobody > will notice it > > In quiescent circumstances, Postgres wouldn't

Re: [GENERAL] Silent data loss in its pure form

_ From: Scott Marlowe Sent: Monday, May 30, 2016 20:14 Subject: Re: [GENERAL] Silent data loss in its pure form To: Alex Ignatov Cc: On Mon, May 30, 2016 at 10:57 AM, Alex Ignatov wrote: > Following this bug reports from redhat > https://bugzilla.redhat.com/

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

On Sun, May 29, 2016 at 12:59 AM, Oleg Bartunov wrote: > > > On Thu, May 26, 2016 at 11:26 PM, Andreas Joseph Krogh > wrote: > >> Hi. >> >> Any news about when slides for $subject will be available? >> > > I submitted slides to pgcon site, but it usually takes awhile, so you can > download our p

Re: [GENERAL] Slides for PGCon2016; "FTS is dead ? Long live FTS !"

På mandag 30. mai 2016 kl. 22:27:11, skrev Oleg Bartunov mailto:obartu...@gmail.com>>:     On Sun, May 29, 2016 at 12:59 AM, Oleg Bartunov mailto:obartu...@gmail.com>> wrote:     On Thu, May 26, 2016 at 11:26 PM, Andreas Joseph Kroghmailto:andr...@visena.com>> wrote: Hi.   Any news about when slid

Re: [GENERAL] Silent data loss in its pure form

On Mon, May 30, 2016 at 4:22 PM, Alex Ignatov wrote: > > _ > From: Scott Marlowe > Sent: Monday, May 30, 2016 20:14 > Subject: Re: [GENERAL] Silent data loss in its pure form > To: Alex Ignatov > Cc: > > > > On Mon, May 30, 2016 at 10:57 AM, Alex Ignatov > wrote: >

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

On Mon, May 30, 2016 at 3:32 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > ​I have to think that we can reasonably ascribe unexpected system state to > causes other than human behavior. In both of the other examples PostgreSQL > would fail to start so I'd say we have expected behav

Re: [GENERAL] Silent data loss in its pure form

_ From: David G. Johnston Sent: Monday, May 30, 2016 23:44 Subject: Re: [GENERAL] Silent data loss in its pure form To: Alex Ignatov Cc: , Scott Marlowe On Mon, May 30, 2016 at 4:22 PM, Alex Ignatov wrote: _ From: Scott M

Re: [GENERAL] Silent data loss in its pure form

Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 31.05.2016 0:12, Alex Ignatov wrote: _ From: David G. Johnston > Sent: Monday, May 30, 2016 23:44 Subject: Re: [GENERAL] Silent data lo

Re: [GENERAL] After replication failover: could not read block X in file Y read only 0 of 8192 bytes

On Mon, May 30, 2016 at 11:37 PM, Brian Sutherland wrote: > I'm running a streaming replication setup with PostgreSQL 9.5.2 and have > started seeing these errors on a few INSERTs: > > ERROR: could not read block 8 in file "base/3884037/3885279": read > only 0 of 8192 bytes > These errors a

Re: [GENERAL] Deleting a table file does not raise an error when the table is touched afterwards, why?

>> Alex Ignatov started a new thread was started on this topic as well...​ >> >> https://www.postgresql.org/message-id/c571dfc5-91b0-0df2-4e3f-45bc94c11...@postgrespro.ru >> >> >>I posted a link to this thread on his new one as well. >> >>David J.​ for completeness: same issue with data c