On 10/6/2016 10:05 PM, Yogesh Sharma wrote:
I need to take source rpm for below version for rhel.
postgresql-8.1.18-2.1
8.1 is a very obsolete version, it was EOL circa 2010.8.1.18 wasn't
even the last release of 8.1, it made it up to 8.1.23.
the community sources for 8.1.18 are here,
On Fri, Oct 7, 2016 at 6:19 PM, Adrian Klaver wrote:
> On 10/06/2016 10:05 PM, Yogesh Sharma wrote:
>>
>> Dear All,
>>
>>
>>
>> Thanks for your support.
>>
>>
>>
>> I need to take source rpm for below version for rhel.
>>
>> postgresql-8.1.18-2.1
>>
>>
>>
>> Could you please share link, so that I
On 10/06/2016 10:05 PM, Yogesh Sharma wrote:
Dear All,
Thanks for your support.
I need to take source rpm for below version for rhel.
postgresql-8.1.18-2.1
Could you please share link, so that I will take.
I have tried to search but could not found.
Probably because it is 6 years pas
Dear All,
Thanks for your support.
I need to take source rpm for below version for rhel.
postgresql-8.1.18-2.1
Could you please share link, so that I will take.
I have tried to search but could not found.
Regards,
Yogesh
On Wed, Oct 5, 2016 at 3:27 PM, Stephen Frost wrote:
> Darren,
>
> * Darren Lafreniere (dlafreni...@onezero.com) wrote:
>> Tom Lane wrote:
>> > > Gavin Wahl wrote:
>> > >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You
>> > >> just find the page range with the largest/sm
Cutting ties by my own interest: I want better Postgres. I want to teach
those who probably will push patches.
Best regards, Andrey Borodin.
четверг, 6 октября 2016 г. пользователь Joshua D. Drake написал:
> On 10/06/2016 10:39 AM, Andrew Borodin wrote:
>
>> Hi everyone!
>>
>> From time to time I
On 10/06/2016 10:39 AM, Andrew Borodin wrote:
Hi everyone!
From time to time I teach at Ural Federal University. Currently
university wants me to make up online course. They are going to put it
to platform like edX or something.
I do not want to do another general programming course, so I made
On 10/06/2016 10:55 AM, Klaus wrote:
PostgreSQL 9.6 for Windows x64 comes packaged with pgadmin 4.
For me, that implies two major issues:
- It is somewhat sluggish, much slower than the previous pgadmin III
- Even more important: on my notebook with a high resolution
screen
PostgreSQL 9.6 for Windows x64 comes packaged with pgadmin 4.
For me, that implies two major issues:
- It is somewhat sluggish, much slower than the previous pgadmin III
- Even more important: on my notebook with a high resolution screen
(3.840 x 2.160), all menues and di
Hi everyone!
From time to time I teach at Ural Federal University. Currently
university wants me to make up online course. They are going to put it
to platform like edX or something.
I do not want to do another general programming course, so I made up
my mind to do a “postgres-hacker” course. But
Geoff Winkless writes:
> On 6 October 2016 at 16:47, Kevin Grittner wrote:
>> I recommend using a transactional advisory lock to serialize these.
> Thanks Kevin, that does seem like the best (although not particularly
> pleasant) solution.
I'm a bit confused about exactly what the context is he
On 10/06/2016 09:09 AM, Geoff Winkless wrote:
On 6 October 2016 at 16:57, Francisco Olarte wrote:
You are contradicting yourself. First you say after the command it
must not exist. Then you say to do it at commit time. If it is done at
commit time you cannot guarantee it does not exist after th
On 6 October 2016 at 16:47, Kevin Grittner wrote:
> I recommend using a transactional advisory lock to serialize these.
Thanks Kevin, that does seem like the best (although not particularly
pleasant) solution.
Geoff
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
On 6 October 2016 at 16:57, Francisco Olarte wrote:
> You are contradicting yourself. First you say after the command it
> must not exist. Then you say to do it at commit time. If it is done at
> commit time you cannot guarantee it does not exist after the command.
I'm not contradicting myself at
Geoff:
On Thu, Oct 6, 2016 at 5:43 PM, Geoff Winkless wrote:
> Nope. Serializable ignores the DROP, and then freezes on CREATE (and
> then fails when the first transaction COMMITs).
Yep, I tested it too.
> Which is also broken,
> because the transaction should fail if (at COMMIT time) the table
On Thu, Oct 6, 2016 at 9:31 AM, Adrian Klaver wrote:
> This is how I can trigger the ERROR:
>
> Session 1:
>
> test=# begin ;
> BEGIN
> test=# drop table if exists ddl_test;
> NOTICE: table "ddl_test" does not exist, skipping
> DROP TABLE
> test=# create table ddl_test(id int);
> CREATE TABLE
>
Adrian:
On Thu, Oct 6, 2016 at 4:31 PM, Adrian Klaver wrote:
> This is how I can trigger the ERROR:
This is how you can trigger the ISSUE, IMO it is a correct behaviour.
Anyway, your example lacks some important details:
1.- SHOW your isolation level.
2.- SHOW your command interleaving.
Here i
On 6 October 2016 at 15:04, Francisco Olarte wrote:
> And anyway, what isolation level are you working on? Because it seems
> you are using a weaker one than serializable, as I think serializable
> should give you more or less what you are expecting ( not on commit
> time, but second drop could pr
On 10/06/2016 02:21 AM, Geoff Winkless wrote:
Hi
I have code that does (inside a single transaction)
DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
Occasionally this produces
ERROR: duplicate key value violates unique constraint
"pg_type_typname_nsp_index" DETAIL: Key (typname,
typna
Hi Geoff:
On Thu, Oct 6, 2016 at 1:58 PM, Geoff Winkless wrote:
> But surely Transactional DDL implies that (it should appear that) nothing
> happens until transaction-commit. That means "drop table if exists" should
> drop the table if it exists at commit time, not drop the table if it didn't
>
On 6 Oct 2016 12:06 p.m., "Francisco Olarte" wrote:
>
> On Thu, Oct 6, 2016 at 11:21 AM, Geoff Winkless
wrote:
> > DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
> >
> > Occasionally this produces
> >
> > ERROR: duplicate key value violates unique constraint
> > "pg_type_typname_nsp_inde
On Thu, Oct 6, 2016 at 11:21 AM, Geoff Winkless wrote:
> DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
>
> Occasionally this produces
>
> ERROR: duplicate key value violates unique constraint
> "pg_type_typname_nsp_index" DETAIL: Key (typname,
> typnamespace)=(mytable, 2200) already exis
Hello, Eduardo.
> Why do you use a dictionary compression and not zlib/lz4/bzip/anyother?
Internally PostgreSQL already has LZ77 family algorithm - PGLZ. I didn't
try to replace it, only to supplement. PGLZ compresses every piece of
data (JSONB documents in this case) independently. What I did is
Hi
I have code that does (inside a single transaction)
DROP TABLE IF EXISTS mytable; CREATE TABLE mytable
Occasionally this produces
ERROR: duplicate key value violates unique constraint
"pg_type_typname_nsp_index" DETAIL: Key (typname,
typnamespace)=(mytable, 2200) already exists.
I can
On 5 October 2016 at 16:58, Aleksander Alekseev
wrote:
> What about evolving schema of JSON/JSONB/XML? For instance,
> adding/removing keys in new versions of the application. UPDATE
> COMPRESSION DICTIONARY?
You can add to a dictionary, but not remove things. I'm not sure
that's a big issue.
-
25 matches
Mail list logo
