The following bug has been logged on the website:
Bug reference: 7920
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.3
Operating system: Linux
Description:
sequence_name left stale after sequence rename:
Test case shows same
On 2013-03-06 09:15:01 +, maxim.bo...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 7920
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.3
Operating system: Linux
Description:
I don't find this particularly suprising. Nothing looks at that field in
sequences, there imo is no point on having the name inside at all.
Do you need that for some usecase or did you just happen to notice it?
I personally don't see any way to nicely fix that. We can add code to
also
Andres Freund and...@2ndquadrant.com writes:
On 2013-03-06 09:27:55 -0500, Tom Lane wrote:
Removing the sequence_name column alone would also break existing code,
for ... um ... not much.
The only argument I see is reduced chance of people making errors. Code
that actually uses sequence_name
The following bug has been logged on the website:
Bug reference: 7921
Logged by: Vinny
Email address: kova...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Windows 7
Description:
When I tried to install a product that uses postgres as a database
Hm. Can you create a reproducible test case for this?
I think this issue happens when pg_dump is slower than the backend
for some reason.
If so, perhaps injecting a sleep() delay into the right place in pg_dump
or libpq would make it reproducible? I wouldn't have any problem
crediting a test
adrianopatr...@gmail.com adrianopatr...@gmail.com wrote:
I need to process a query, the query returned as somewhere around
20 million records, I thought to do with LIMIT and OFFSET where
the limit is fixed for 5000 records and will incrementing the
OFFSET, but when reached OFFSET 400 000
Shin-ichi MORITA s-mor...@beingcorp.co.jp writes:
If so, perhaps injecting a sleep() delay into the right place in pg_dump
or libpq would make it reproducible?
An alternative way would be running pg_dump with a lower priority.
Actually, I can reproduce this issue by setting the priority of
The following bug has been logged on the website:
Bug reference: 7923
Logged by: Keith Fiske
Email address: ke...@omniti.com
PostgreSQL version: 9.2.3
Operating system: Debian/Ubuntu/Solaris
Description:
Running into an issue when we tried to add a password to a gpg
