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 prob
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
> a
Andres Freund writes:
> 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.
Yeah, and we really can't update the name there because there is no
provision for transactional updates of sequence tuples.
> I pe
On 2013-03-06 09:27:55 -0500, Tom Lane wrote:
> Andres Freund writes:
> > 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.
>
> Yeah, and we really can't update the name there because there is no
> provi
Andres Freund 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 is broken.
Wel
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
server,install
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" 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 consultation was very
>
"Shin-ichi MORITA" 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
> pg_dump to Low us
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 s
11 matches
Mail list logo
