Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane Sent: Friday, August 24, 2012 10:33 AM Chris Travers writes: >> My guess is that tableoid is not known when the check constraint is >> checked. >None of the system columns are set at the time check constraints are >checked. Is there any problem if set tableOID before calling ExecConstarints()? I am not sure may be this is not so important problem for which we don't want to change existing code. With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
Amit Kapila writes: > From: pgsql-bugs-ow...@postgresql.org > [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane >> None of the system columns are set at the time check constraints are >> checked. > Is there any problem if set tableOID before calling ExecConstarints()? Well, possibly we could kluge things to make that particular case work, but if someone expects that to be valid then why not oid, ctid, xmin, etc? And more to the point, what's the value of examining tableoid in a check constraint? The constraint is attached to a particular table, so the tableoid would be a constant for it anyway. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
On Fri, Aug 24, 2012 at 3:52 AM, Amit Kapila wrote: > From: pgsql-bugs-ow...@postgresql.org > [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane > Sent: Friday, August 24, 2012 10:33 AM > Chris Travers writes: >>> My guess is that tableoid is not known when the check constraint is >>> checked. > >>None of the system columns are set at the time check constraints are >>checked. > > Is there any problem if set tableOID before calling ExecConstarints()? > I am not sure may be this is not so important problem for which we don't > want to > change existing code. Just to be sure my initial concern is this: Table inheritance would be easier if there was a way to declare a constraint such that it prevents insert for some rows on the parent but not for a child and/or vice versa. This can be used to partition the primary key between a parent and child tables to avoid some key overlap issues. My concern was that this was the "clever" solution that someone would try, insufficiently test, and find out that their clever solution in fact did nothing except preventing the constraint from being dropped and later re-applied. As for the ideal way of looking at addressing this possibility: I am further not going to speak for the developers here but I do wonder about system columns generally and check constraints, and whether the same solution is just to check the check constraint and error if a system column is checked. Some things seem obvious but what happens if someone says "this table cannot grow beyind 5 pages and we will do this by checking against ctid"? If we start pulling out some system columns for special treatment I am not sure where it ends. I am assuming that ctid cannot be safely known before the row is formally stored on disk. I think the cleanest fix interface-wise is to prevent check constraints from being added to tables in this case. I don't see it as a high priority though. My larger priority is to flag this as a possible thing someone is likely to try to get around the issues storing rows in both parent and child tables. Best Wishes, Chris Travers -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7504: corrupted statistics file "pg_stat_tmp/pgstat.stat"
On 24-08-2012 00:16, she...@163.net wrote: > Maybe this is a bug. > if stats collector process don't product pg_stat_tmp/pgstat.stat file, the > autovacuum launcher process will output those WARNING message? > It is possible but... Did you see any ERROR message(s) related to statistics collector before those ones? To solver your problem, you can remove the pgstat.stat file that it will be created again next time server starts. Of course, you will loose the statistics, hence remember to VACUUM ANALYZE your cluster. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
Chris Travers writes: > Table inheritance would be easier if there was a way to declare a > constraint such that it prevents insert for some rows on the parent > but not for a child and/or vice versa. FWIW, 9.2 adds support for constraints that only apply to the named table and don't get inherited to children. I think use of such constraints is probably better design than mucking around with tableoid, even if we were to make that work. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, August 24, 2012 7:46 PM Amit Kapila writes: > From: pgsql-bugs-ow...@postgresql.org > [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane >>> None of the system columns are set at the time check constraints are >>> checked. >> Is there any problem if set tableOID before calling ExecConstarints()? > Well, possibly we could kluge things to make that particular case work, > but if someone expects that to be valid then why not oid, ctid, xmin, > etc? Initially, I thought of saying like that but the same is done in heap_prepare_insert() So doing it 2 times doesn't make sense and if we move them out then all places from where heap_insert gets called, we have to do it like that. However why I have asked to set tableOID, as for it, already functions CopyFrom and AtRewriteTable does it(set tableOid before Constraints check). > And more to the point, what's the value of examining tableoid in > a check constraint? The constraint is attached to a particular table, > so the tableoid would be a constant for it anyway. Here what you are suggesting if I understood correctly is while defining such constraints make sure its not allowed, because once defined, during execution we might not be able to identify. Please correct me if I have misunderstood? With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Wed, Aug 22, 2012 at 10:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 21, 2012 at 4:30 PM, Tom Lane wrote:
>>> Meanwhile, back at the ranch: I'm fine with applying that patch now that
>>> it's had some field testing.
>
>> Attached is a version that applies OK to 9.1, after resolving some
>> conflicts. Review appreciated. It wasn't exactly clear to me how to
>> handle the ereport/elog calls.
>
> It looks sane to me in a quick once-over (bearing in mind I can't test
> it). What's bothering you about the ereport calls?
Well, 9.1 currently has:
errmsg_internal("failed to enumerate network events: %i", (int) GetLastError()))
Prior to your patch, master had:
errmsg_internal("failed to enumerate network events: error code %lu",
GetLastError())
And you changed it to:
elog(ERROR, "failed to enumerate network events: error code %u",
WSAGetLastError())
So obviously there's a conflict there. In the previously-posted
version, I chose to just take your version, but I'm not sure whether
it would be better -- in the back branches -- to simply replace
GetLastError() with WSAGetLastError() and leave it alone otherwise.
>> What to do pre-9.1 is a bit less clear to me, as the latch machinery
>> doesn't exist at all in those versions. Some of the fixes can
>> probably still be pulled out and applied, though.
>
> Presumably the changes in win32/socket.c could still be applied; but
> on the other hand it's not clear there's so much need for them pre-9.1.
> IIRC most of the point of this patch was to eliminate the tug-of-war
> over the socket's event attachment between socket.c and win32_latch.c,
> so maybe there's not a bug pre-9.1.
Well, this thread started as a bug report against 8.3.7...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
Excerpts from Robert Haas's message of sáb ago 25 00:10:57 -0400 2012:
> > It looks sane to me in a quick once-over (bearing in mind I can't test
> > it). What's bothering you about the ereport calls?
>
> Well, 9.1 currently has:
>
> errmsg_internal("failed to enumerate network events: %i", (int)
> GetLastError()))
>
> Prior to your patch, master had:
>
> errmsg_internal("failed to enumerate network events: error code %lu",
> GetLastError())
>
> And you changed it to:
>
> elog(ERROR, "failed to enumerate network events: error code %u",
> WSAGetLastError())
>
> So obviously there's a conflict there. In the previously-posted
> version, I chose to just take your version, but I'm not sure whether
> it would be better -- in the back branches -- to simply replace
> GetLastError() with WSAGetLastError() and leave it alone otherwise.
Note that for translations none of this matters, because
errmsg_internal() does not mark its argument for translation, and
neither does elog().
The change of %i to "error code %lu" was done recently (during 9.2 devel
cycle) to make all error messages involving GetLastError() consistent;
see commit 1af55e275.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
