I'm getting this same error and wonder if Tom's fix is sufficient.
IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT = 0x0501, but in
pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so
IPPROTO_IPV6 is left
undefined.
Regards,
Dave
---
Unfortunately I had to
Right now, I do this like this:
if ($err =~ /name_of_first_foreign_key/) {
$r-error_exit('First error message.')
}
elsif ($err =~ /name_of_second_foreign_key/) {
...
As an aside comment, a bit more regex foo with \b is indicated here :-)
if ($err =~ /\bname_of_first_foreign_key\b/) {
Which leads me to the same conclusion: anything as complicated as CASE
is the wrong design. But perhaps for slightly different reasons.
What I like about the sql CASE is, that it is expression based, and thus
allows full flexibility in partitioning and is highly self documenting.
Do we need
Could the list admin please unsubscribe Andreas Zeugswetter from the
lists until he can fix his vacation-responder-gone-nuts?
I am very sorry, fixed. I forgot to set nomail before setting the out of office
assistant
which my company requires me to do in this braindead way.
But I assume
We should delayload this dll since it is only needed
for specific configuration. No need to install when it is not used.
Andreas
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Dann Corbit
Sent: Friday, February
I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager
and Daemon
Tools, so those were probably not the problemcause since it's
still working.
I think unfortunately it may be the case, that only initdb has a problem.
Andreas
--
Sent via pgsql-hackers mailing list
We should delayload this dll since it is only needed
for specific configuration. No need to install when it is not used.
That would require building knowledge of DLL names into the code,
which isn't practical as some projects have a habit of changing them
regularly (e.g. gettext).
Yup,
One more question I have though is:
How do you make sure noone (e.g. autovacuum analyze)
unfreezes tuples after the vacuum freeze ?
I will start a new thread to answer this question, but the short answer
is that the freeze only needs to happen in a fresh initdb database, and
once clog
I would like to add a --freeze parameter to vacuumdb for use by the
binary upgrade utility, and for symmetry with the existing VACUUM
options; patch attached.
Exactly what do you think the upgrade utility is going to do with it?
Surely not a database-wide VACUUM FREEZE, if we are
So if this is a compiler bug, it certainly isn't an obvious one. I'll dig
deeper to see how I can convince configure to use -qnooptimize.
Set CFLAGS in its environment. The default is set in src/template/aix
CFLAGS=-O2 -qmaxmem=16384 -qsrcmsg -qlonglong
When I've used the build
Yes, I've had CC exported as xlC_r -q64 to do 64 bit builds, and use vacpp
C++ instead of C. Guess it didn't like that, and ended up with some horrible
compiler optimization or something that killed it.
Have you determined whether the problem is optimization or 64bit ?
Are there any other
I don't think partitioning is really the same thing as row-level security.
Of course not, but it seems to me that it can be used to accomplish most
of the same practical use-cases. The main gripe about doing it via
partitioning is that the user's nose gets rubbed in the fact that there
There is another thing that's bothering me, though, which is that the
present approach to dumping rules isn't adequate. Consider the
following scenario:
1. You create a view that the system considers updatable, so
it creates
some automatic rules.
2. You don't want those rules, so you
You don't want to just
modify pg_standby to accept small files, because then you've made it
harder to make absolutely sure when the file is ready to be
processed if a non-atomic copy is being done.
It is hard, but I think it is the right way forward.
Anyway I think the size is not robust
So, barring objections, I'll go make this happen. What do we want to
call the intermediate constraint_exclusion value? The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone has a better idea.
Not a huge fan of 'child' since it implies inheritance.
Logically, xmin horizon conflicts could be flexible/soft.
That is, if we implemented the idea to store a lastCleanedLSN for each buffer
then
xmin horizon conflicts would be able to continue executing until they
see a buffer with buffer.lastCleanedLSN conflictLSN.
I think the trouble is,
it's look well, but I still prefer some combination with =
name: = ''
name: = '''
:name = ''
$name = ..
$name = ..
I wonder about name := ''.
:= is used in Pascal/Ada to assign a value. Or would that again be an allowed
operator in pg ?
Andreas
--
Sent via pgsql-hackers mailing list
If we use some type of integer, I suggest using this structure for
pg_security:
CREATE TABLE pg_security(
relid oid,
secid int2,
secacl aclitem[],
secext TEXT
);
This allows the per-row value to be a simple int2.
Ah, that is a good point, that if we have security column which is
usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think WITH SECURITY_CONTEXT
is needed.
I sure wish others were adding ideas to this discussion.
One such idea would be,
Ah, that is a good point, that if we have security
column which is
usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think WITH
SECURITY_CONTEXT is needed.
I sure wish others were adding ideas to this discussion.
One
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
Should these return xid?
And shouldn't these two be folded together ?
It seems
The user running initdb (or the postmaster) needs
SeCreateGlobalPrivilege - which is something we cannot really start
Why not ? Doesn't the pg installer already tweak the permissions of the
installation user. On XP you can connect to session 0, so that is an
alternative on XP.
telling
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called security_context which would store the
oid of the role that can see the row; if the oid is zero (InvalidOid),
A
Simon Riggs wrote:
2. Master ignores Standby's OldestXmin
Effects:
* Long running queries on standby...
Have no effect on primary
Can delay apply of WAL records on standby
* Queries on standby give consistent answers in all cases.
Just for clarification, if you set a
I wonder whether the cancel can be delayed until a tuple/page is actually
accessed
that shows a too new xid.
Yes, its feasible and is now part of the design.
This is all about what happens *if* we need to remove rows that a query
can still see.
I was describing a procedure for
Don't understand. I am referring to the logic at the top of
AdvanceXLInsertBuffer(). We would need to wait for all people reading
the contents of wal_buffers.
Oh, I see.
If a slave falls behind, how does it catch up? I guess you're saying
that it can't fall behind, because the master
Proposal: Make the first block of a seq scan cost random_page_cost, then
after that every additional block costs seq_page_cost.
+1
AFAICS the cost cross-over is much higher than the actual elapsed time
cross-over for both narrow and wide tables.
Which makes absolute sense, since
If you accept the idea that column identity should be based on column
name, then the only two operations that are really necessary are
CREATE OR REPLACE VIEW and ALTER VIEW RENAME COLUMN, and it is
100% clear what the semantics of those operations should be.
+1
I think this would be an
Changing statement result type is also currently prohibited in
StorePreparedStatement. There maybe good reasons for this,
How about the SQL spec says so?
Prepare time is often also the time when you bind the result, or more
generally set up the code to handle the result.
Generally I
Obviously we run into problems when
a) we have a poor estimate for ndistinct - but then we have
worse problems
b) our length measure doesn't correspond well with ndistinct
in an interval
One more problem with low ndistinct values is that the condition might very well
hit no rows at all. But
I think for low ndistinct values we will want to know the exact
value + counts and not a bin. So I think we will want
additional stats rows
that represent value 'a1' stats.
Isn't that what our most frequent values list does?
Maybe ? Do we have the relevant stats for each ?
But the trick
So right now I'm thinking I like my original proposal
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00357.php
with the exception that we should go with
SQLSTATE 'xyzzy'
as the syntax in EXCEPTION lists. Also I'm willing to go with
ERRCODE rather than CODE as the name of the
Do we want the following:
1. pg_dump issues set statement_timeout = 0; to the
database prior to
taking its copy of data (yes/no/default-but-switchable)
2. pg_dump/pg_restore issue set statement_timeout = 0; in
text mode
output (yes/no/default-but-switchable)
3. pg_restore
33 matches
Mail list logo
