eshkin...@gmail.com writes:
> The following bug has been logged on the website:
>
> Bug reference: 6480
> Logged by: Sergey Burladyan
> Email address: eshkin...@gmail.com
> PostgreSQL version: 9.1.2
> Operating system: Debian testing
> Description:
>
> This code incorr
The following bug has been logged on the website:
Bug reference: 6483
Logged by: Kouber Saparev
Email address: kou...@saparev.com
PostgreSQL version: 9.1.2
Operating system: Debian
Description:
The rows of a SELECT statement are being evaluated, even when not shown in
Hello
this is not bug
"OFFSET" doesn't mean go to line n - it means - first n lines don't
send to client.
Regards
Pavel Stehule
2012/2/22 :
> The following bug has been logged on the website:
>
> Bug reference: 6483
> Logged by: Kouber Saparev
> Email address: kou...@sapare
The following bug has been logged on the website:
Bug reference: 6482
Logged by: Dmitriy
Email address: dzolotarevs...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Windows Server 2003 r2 32bit
Description:
All Postgres processes terinates.
In log you can fin
The following bug has been logged on the website:
Bug reference: 6481
Logged by: Michał Rakoczy
Email address: michal.rako...@sb-betting.com
PostgreSQL version: 9.0.5
Operating system: Windows Server 2008 R2 Enterprise x64 SP1
Description:
Hi
I'm struggling with this
dzolotarevs...@gmail.com writes:
> All queries works fine when there is only one session. When Sessions more
> then 20 it starts terminating with some probability.
> On my production server it stops about 50 times per day.
> On my dev pc, with testing utility that uses 50 sessions at one time, it
On Wed, Feb 22, 2012 at 20:53, wrote:
> -- shows a notice for 1, 2, 3 and 4
> SELECT x.id, f(x) FROM xxx as x LIMIT 2 OFFSET 2;
Currently the way to fix this is to use a subquery that acts as an
optimization barrier in the presence of OFFSET:
SELECT x.id, f(x) FROM (SELECT * FROM xxx as x LIMIT
Marti Raudsepp writes:
> According to this model, evaluating SELECT clause fields for *all*
> found rows is done in step 5, whereas LIMIT/OFFSET are only applied
> later at step 9. So we're already bending the rules here (in general
> we don't do such optimizations around volatile functions). The
On Wed, Feb 22, 2012 at 23:40, Tom Lane wrote:
> Marti Raudsepp writes:
>> According to this model, evaluating SELECT clause fields for *all*
>> found rows is done in step 5, whereas LIMIT/OFFSET are only applied
>> later at step 9. So we're already bending the rules here (in general
>> we don't
The following bug has been logged on the website:
Bug reference: 6484
Logged by: Charlie Neo
Email address: c...@accessdata.com
PostgreSQL version: 9.0.6
Operating system: Windows Server 2008 R2 Enterprise
Description:
During heavy database loading, "pgstat wait timeo
The following bug has been logged on the website:
Bug reference: 6485
Logged by: Ramanujam
Email address: innomot...@gmail.com
PostgreSQL version: 9.0.3
Operating system: Windows 7 Home Premium
Description:
Primary key information in pg_attribute table is not updated
innomot...@gmail.com writes:
> Primary key information in pg_attribute table is not updated when a column
> name is renamed.
This is intentional --- we gave up updating index column names awhile
ago.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postg
On Thu, Feb 23, 2012 at 3:22 PM, Tom Lane wrote:
> innomot...@gmail.com writes:
>
> This is intentional --- we gave up updating index column names awhile
> ago.
Is pg_constraint a credible place to retrieve primary key information from?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
13 matches
Mail list logo
