The following bug has been logged on the website:
Bug reference: 8275
Logged by: Rushabh Lathia
Email address: rushabh.lat...@gmail.com
PostgreSQL version: 9.2.4
Operating system: All
Description:
View based on inheritance throws error on insert statement.
Testcase:
On Mon, 2013-07-01 at 19:27 -0400, Tom Lane wrote:
> I think probably we'd have just not compiled the dependent code, and
> would have found out about it only when somebody complained that peer
> auth didn't work on OpenBSD. Not sure that's really a more attractive
> behavior :-(
That might be t
Peter Eisentraut writes:
> On 7/1/13 9:19 AM, Tom Lane wrote:
>> AFAICT, the result in this case would be that the script comes to the
>> wrong conclusion about whether ucred.h is available. Wouldn't that
>> result in a build failure, or at least missing features? IOW, don't
>> we need to fix th
On Tue, Jul 2, 2013 at 3:05 AM, Eyal Kaspi wrote:
> You are right. I did not read the doc correctly.
>
> Is there anyway to specify a timestamp and get the database to recover to
> the first transaction after that point?
Currently there is no easy way to do that. Basically you need to find out
th
On 07/01/2013 05:35 PM, Peter Eisentraut wrote:
On 7/1/13 9:19 AM, Tom Lane wrote:
AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we ne
On 7/1/13 9:19 AM, Tom Lane wrote:
> AFAICT, the result in this case would be that the script comes to the
> wrong conclusion about whether ucred.h is available. Wouldn't that
> result in a build failure, or at least missing features? IOW, don't
> we need to fix this test anyway?
The test needs
Jeff Janes escribió:
> The bug was introduced in commit: 0ac5ad5... Improve concurrency of foreign
> key locking.
>
> I don't know what more to look into on this, so I'm cc Alvaro, the patch
> author.
Thanks, will look.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL De
On Mon, Jul 1, 2013 at 3:43 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8273
> Logged by: David Leverton
> Email address: levert...@googlemail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: RHEL 5 x86_64
> Description:
You are right. I did not read the doc correctly.
Is there anyway to specify a timestamp and get the database to recover to
the first transaction after that point?
On Mon, Jul 1, 2013 at 10:07 AM, Fujii Masao wrote:
> On Sat, Jun 29, 2013 at 7:12 AM, wrote:
> > The following bug has been logg
On Sat, Jun 29, 2013 at 7:12 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8269
> Logged by: PITR Recovery by timestamp ignores
> recovery_target_inclusive
> Email address: eyal.ka...@delphix.com
> PostgreSQL version: 9.2.4
> Operating syste
The following bug has been logged on the website:
Bug reference: 8274
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.1.9
Operating system: any
Description:
The guy on IRC who ran into this one was using 9.1.9, but it seems to
On 2013-07-01 09:19:23 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 6/30/13 11:26 AM, Andres Freund wrote:
> >> If we would treat that warning as an error unconditionally - and I am
> >> not sure how easy that is given the way it's emitted - users
> >> encountering them, which usually
Peter Eisentraut writes:
> On 6/30/13 11:26 AM, Andres Freund wrote:
>> If we would treat that warning as an error unconditionally - and I am
>> not sure how easy that is given the way it's emitted - users
>> encountering them, which usually will be on less common platforms, will
>> have to patch
On 6/30/13 11:26 AM, Andres Freund wrote:
> If we would treat that warning as an error unconditionally - and I am
> not sure how easy that is given the way it's emitted - users
> encountering them, which usually will be on less common platforms, will
> have to patch configure.in to make things work
The following bug has been logged on the website:
Bug reference: 8273
Logged by: David Leverton
Email address: levert...@googlemail.com
PostgreSQL version: Unsupported/Unknown
Operating system: RHEL 5 x86_64
Description:
The following test case causes a backend asser
On 7/1/2013 12:01 AM, Heikki Linnakangas wrote:
I agree that would be a nice feature. Patches are welcome, on the
pgsql-jdbc mailing list. As a work-around, you can set up a different
db user for each schema, and set search_path as a per-user setting in
the server.
or just use the default s
On 01.07.2013 00:41, emes...@redhat.com wrote:
Hi
Postgres does not support currently defining the schema in teh connection
parameters which makes it imposible to seprate the database to several
schemas and connect to the right one from the application.
There is already a thread discussing that
17 matches
Mail list logo
