On 09/18/2014 09:44 AM, lud...@kni-online.de wrote:
Hi Adrian,
this database runs as develop-version on my PC and was created by hand,
no dumps or pg_upgrade.
The same database runs as production-version on another server
(PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit), so far
witho
contents.
But I'm curious about what has caused the problems and how to avoid them...
Ludwig
Gesendet: Donnerstag, 18. September 2014 um 15:53 Uhr
Von: "Adrian Klaver"
An: "lud...@kni-online.de" , pgsql-general@postgresql.org
Betreff: Re: [GENERAL] strange p
On 09/18/2014 04:12 AM, lud...@kni-online.de wrote:
Hi Adrian,
data got into the database with normal update/insert-queries from
logged-in database-users using "normal" PG-Users/roles,
the "ghost-roles" (with these unusual numerical role-names) were never
created by me, I don't know where they co
ems?
Ludwig
Gesendet: Mittwoch, 17. September 2014 um 17:33 Uhr
Von: "Adrian Klaver"
An: "lud...@kni-online.de" , pgsql-general@postgresql.org
Betreff: Re: [GENERAL] strange problem with not existing roles
On 09/17/2014 08:08 AM, lud...@kni-online.de wrote:
> Hi list
On 09/17/2014 08:08 AM, lud...@kni-online.de wrote:
Hi list,
I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by
Visual C++ build 1600, 64-bit), there are granted privileges on schemas,
tables, columns for roles that don't exist.
So how did the data get into the database?
Exa
Hi list,
I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 64-bit), there are granted privileges on schemas, tables, columns for roles that don't exist.
Example:
In pgAdmin for schema user_data the follwing wrong grants are reported:
...
GRANT ALL ON SCHEM
On , Alban Hertroys wrote:
On 30 August 2012 10:12, Condor wrote:
Hello,
can I ask is exist some kind of automatic escape string in
postgresql ?
I use pgsql 9.1.5 and I have very interest problem, I have field
with text
string that I cant find normally.
Here is examples (I replace in examp
On 30 August 2012 10:12, Condor wrote:
> Hello,
> can I ask is exist some kind of automatic escape string in postgresql ?
> I use pgsql 9.1.5 and I have very interest problem, I have field with text
> string that I cant find normally.
> Here is examples (I replace in example Cyrillic encoding bec
Hello,
can I ask is exist some kind of automatic escape string in postgresql ?
I use pgsql 9.1.5 and I have very interest problem, I have field with
text string that I cant find normally.
Variable encoding from variables:
server_encoding | WIN1251
lc_collate
BK wrote:
[server complains that wal_level is not set correctly]
>> Did you change the correct postgresql.conf?
>> Are there more than one lines for wal_level in the file
>> (try "grep wal_level postgresql.conf")?
>
> I tried greping, there is just one nstance of it and is set on
archive.
>
> Any
On 11/30/2011 01:43 PM, Tomas Vondra wrote:
On 30 Listopad 2011, 17:23, BK wrote:
Hi Albe,
On Nov 30, 2011, at 2:31 PM, Albe Laurenz wrote:
Verify the current setting with
SELECT setting, source, boot_val, reset_val,
sourcefile, sourceline
FROM pg_settings WHERE name = 'wal_level';
If
On 30 Listopad 2011, 17:23, BK wrote:
> Hi Albe,
>
> On Nov 30, 2011, at 2:31 PM, Albe Laurenz wrote:
>> Verify the current setting with
>>
>> SELECT setting, source, boot_val, reset_val,
>> sourcefile, sourceline
>> FROM pg_settings WHERE name = 'wal_level';
>>
>> If the setting is not right
Hi Albe,
On Nov 30, 2011, at 2:31 PM, Albe Laurenz wrote:
> Verify the current setting with
>
> SELECT setting, source, boot_val, reset_val,
> sourcefile, sourceline
> FROM pg_settings WHERE name = 'wal_level';
>
> If the setting is not right (which is likely the case), try to find out
> t
BK wrote:
> I've spent a couple of hours trying some WAL archiving functionality
on PostgrSQL 9.1 (running on Mac
> OS X). I turned on all the needed options as specified in the
documentation:
>
> wal_level = archive
> archive_mode = on
> archive_command='test ! -f /Volumes/baza/%f && cp %p /Volum
Hello,
I've spent a couple of hours trying some WAL archiving functionality on
PostgrSQL 9.1 (running on Mac OS X). I turned on all the needed options as
specified in the documentation:
wal_level = archive
archive_mode = on
archive_command='test ! -f /Volumes/baza/%f && cp %p /Volumes/baza/%f'
On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > Any chance of getting the fix in patch format so we could test it on
> > this system?
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
hi
jus
hubert depesz lubaczewski writes:
> checked lengths of the text/varchar columns in database.
> there are 16 such columns in the table.
> full report of lengths is in
> http://www.depesz.com/various/lengths.report.gz
> it was obtained using:
> select length( "first_text_column" ) as length_1, cou
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> that. And that they are the only rows that, in addition to the above
> conditions, contain data fields wide enough to require out-of-line
> toasting.
checked lengths of the text/varchar columns in database.
there are 16 such columns in
hubert depesz lubaczewski writes:
> Any chance of getting the fix in patch format so we could test it on
> this system?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
regards, tom lane
--
Sent via pgsql-general mail
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> Hah ... I have a theory.
>
> I will bet that you recently added some column(s) to the source table
> using ALTER TABLE ADD COLUMN and no default value, so that the added
> columns were nulls and no table rewrite happened. And that these
I wrote:
> A different line of thought is that there's something about these
> specific source rows, and only these rows, that makes them vulnerable to
> corruption during INSERT/SELECT. Do they by any chance contain any
> values that are unusual elsewhere in your table? One thing I'm
> wondering
On Friday, November 04, 2011 6:04:02 pm Tom Lane wrote:
> I wrote:
> > A different line of thought is that there's something about these
> > specific source rows, and only these rows, that makes them vulnerable to
> > corruption during INSERT/SELECT. Do they by any chance contain any
> > values th
On Fri, Nov 04, 2011 at 05:06:35PM -0700, Adrian Klaver wrote:
> Another question.
> Between 07/20/11 and this recent attempt did you do a CREATE TABLE AS on this
> table and not have corrupted rows?
don't remember.
Best regards,
depesz
--
The best thing about modern society is how easy it is
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
On Friday, November 04, 2011 3:43:48 pm hubert depesz lubaczewski wrote:
> On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> > You said that pg_dump does not show the corruption. That could be
> > because the data is coming out through the COPY code path instead of
> > the SELECT code pa
hubert depesz lubaczewski writes:
> On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
>> You said that pg_dump does not show the corruption. That could be
>> because the data is coming out through the COPY code path instead of
>> the SELECT code path. Could you try a pg_dump with --inser
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
On Fri, Nov 04, 2011 at 06:18:55PM -0400, Tom Lane wrote:
> BTW, did you try the separate INSERT/SELECT yet? Does that show
> corruption?
pg_dump --inserts is still working.
i did create table (like), insert into ... select and it also shows the
problem, as I showed (with other data) in email:
2
I wrote:
> Good detective work. So now we at least have a believable theory about
> *what* is happening (something is stomping the first 8 data bytes of
> these particular rows), if not *why*.
Scratch that: something is stomping the first *six* bytes of data.
On a hunch I converted the original a
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
hubert depesz lubaczewski writes:
> OK. So based on it all, it looks like for some rows, first two columns got
> mangled.
Good detective work. So now we at least have a believable theory about
*what* is happening (something is stomping the first 8 data bytes of
these particular rows), if not *w
On 11/04/2011 01:47 PM, hubert depesz lubaczewski wrote:
On Fri, Nov 04, 2011 at 01:43:55PM -0700, Adrian Klaver wrote:
Does it tell you anything?
You are very thorough.
I hate mysteries. Especially the ones that break stuff.
Know the feeling.
I don't know enough about Postgres internal
On Fri, Nov 04, 2011 at 01:43:55PM -0700, Adrian Klaver wrote:
> >Does it tell you anything?
> You are very thorough.
I hate mysteries. Especially the ones that break stuff.
> I don't know enough about Postgres internals to be much help there.
> All I can point out is the problem seemed to appear
On 11/04/2011 01:17 PM, hubert depesz lubaczewski wrote:
On Thu, Nov 03, 2011 at 11:03:45PM +0100, hubert depesz lubaczewski wrote:
looking for some other info. will post as soon as i'll gather it, but
that will be in utc morning :(
I looked closer at the rows that got -1 xobject_id.
Does
On Thu, Nov 03, 2011 at 11:03:45PM +0100, hubert depesz lubaczewski wrote:
> looking for some other info. will post as soon as i'll gather it, but
> that will be in utc morning :(
I looked closer at the rows that got -1 xobject_id.
$ select magic_id, count(*) from qqq where xobject_id = -1 group
On Thu, Nov 03, 2011 at 06:02:04PM -0400, Tom Lane wrote:
> select * from pg_attribute where attrelid = 'sss.xobjects'::regclass
> and attisdropped;
no dropped columns.
looking for some other info. will post as soon as i'll gather it, but
that will be in utc morning :(
Best regards,
depesz
hubert depesz lubaczewski writes:
> i tried:
> create table qqq as select cmax as o_cmax, xmax as o_xmax, cmin as
> o_cmin, xmin as o_xmin, ctid as o_ctid, * from sss.xobjects;
> but the resulting table didn't have -1 values:
Oh, that's pretty interesting ... suggests that the targetlist has
> I would like to know the ctid's of the -1 rows in the copied table,
> along with the ctid's of the rows they share magic_ids with, and
> the ctid's of the rows with those same magic_ids in the original.
> I'm wondering whether the affected rows are physically clustered ...
i tried:
create table
Adrian Klaver writes:
> On Thursday, November 03, 2011 1:03:12 pm hubert depesz lubaczewski wrote:
>> as you can see counts of rows in created table are more or less
>> sensible, but whatever method I used - create table as, insert into,
>> using sychronized_scans (initially) or not (later) - copy
On Thursday, November 03, 2011 1:03:12 pm hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
>
> So, did some tests:
>
> as you can see counts of rows in created table are more or less
> sensible, but whatever method I used - create table as, insert int
On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > index on xobject_id might be corrupted, but it doesn't explain that I
> > don't see duplicates with group_by/having query on xobjects, which uses
> > seqscan:
>
> I was just going to ask you to check
On Thursday, November 03, 2011 8:30:34 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 08:23:01AM -0700, Adrian Klaver wrote:
> > On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> > > On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > > > So
hubert depesz lubaczewski writes:
> other tests are running, but simple question - how to get number of rows
> affected from psql?
> create table xxx as select * from xobjects;
> returns just:
> SELECT
We fixed that in 9.0, but 8.4 won't provide the count (unless you care to
patch it). That's w
On Thu, Nov 03, 2011 at 08:23:01AM -0700, Adrian Klaver wrote:
> On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> > On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > > So just to be clear there is and never has been a -1 value for xobject_id
> > > in the
On Thu, Nov 03, 2011 at 04:21:37PM +0100, Alban Hertroys wrote:
> On 3 November 2011 09:25, hubert depesz lubaczewski wrote:
> > All looks good. pg_dump of the table also doesn't show any strange
> > problems, and is duplicate free. But:
> >
> > $ create table zzz as select * from sss.xobject
On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > So just to be clear there is and never has been a -1 value for xobject_id
> > in the source table?
>
> yes. min value of xobject_id is 1000, and we had tr
On 3 November 2011 09:25, hubert depesz lubaczewski wrote:
> All looks good. pg_dump of the table also doesn't show any strange problems,
> and is duplicate free. But:
>
> $ create table zzz as select * from sss.xobjects;
> SELECT
>
> $ select xobject_id, count(*) from zzz group by 1 having c
On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> So just to be clear there is and never has been a -1 value for xobject_id in
> the
> source table?
yes. min value of xobject_id is 1000, and we had trigger in place on the
table which logged all inserts/updates/deletes and the val
On Thursday, November 03, 2011 7:15:22 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 07:00:30AM -0700, Adrian Klaver wrote:
> > > I also verified that there are no concurrent updates that would set
> > > xobject_id to -1, so it's not a problem of isolation.
> > >
> > > During the n
On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
> > index on xobject_id might be corrupted, but it doesn't explain that I
> > don't see duplicates with group_by/having query on xobjects, which uses
> > seqscan:
> I was just going to ask you to check that. Weird as can be.
> Does plain ol
hubert depesz lubaczewski writes:
> index on xobject_id might be corrupted, but it doesn't explain that I
> don't see duplicates with group_by/having query on xobjects, which uses
> seqscan:
I was just going to ask you to check that. Weird as can be.
Does plain old "SELECT COUNT(*)" show a diff
On Thu, Nov 03, 2011 at 03:19:36PM +0100, Alban Hertroys wrote:
> On 3 November 2011 15:15, hubert depesz lubaczewski wrote:
> >> Do the xobject_id values have other negative numbers or is -1 just a
> >> special
> >> case? The only thing I can think of is a corrupted index on xobject_id.
> >
> >
On 3 November 2011 15:15, hubert depesz lubaczewski wrote:
>> Do the xobject_id values have other negative numbers or is -1 just a special
>> case? The only thing I can think of is a corrupted index on xobject_id.
>
> minimal xobject_id in source table is 1000.
>
> index on xobject_id might be cor
On Thu, Nov 03, 2011 at 07:00:30AM -0700, Adrian Klaver wrote:
> > I also verified that there are no concurrent updates that would set
> > xobject_id to -1, so it's not a problem of isolation.
> >
> > During the night I repeated the procedure and the rows that got duplicated
> > seem to be the sam
On Thursday, November 03, 2011 1:25:58 am hubert depesz lubaczewski wrote:
> Hi
> We have pretty weird situation, which seems to be impossible, but perhaps
> you'll notice something that will let me fix the problem.
>
> System: SunOS 5.11 snv_130
> Pg: PostgreSQL 8.4.7 on i386-pc-solaris2.11,
Hi
We have pretty weird situation, which seems to be impossible, but perhaps
you'll notice something that will let me fix the problem.
System: SunOS 5.11 snv_130
Pg: PostgreSQL 8.4.7 on i386-pc-solaris2.11, compiled by cc: Sun C 5.10
SunOS_i386 2009/06/03, 64-bit
In there I have a table:
On Jul 9, 2007, at 9:22 AM, Gustavo Ces wrote:
Hi all,
I´ve got a strange problem, hope you could help. I´ve got a
table (a ) with n tuples, and two fields , birthplace and birth
date. There´s another table ( say b) with m tuples, where i´ve got
a lot of polygons ( with their code, sam
Hi all,
I´ve got a strange problem, hope you could help. I´ve got a table (a ) with
n tuples, and two fields , birthplace and birth date. There´s another table (
say b) with m tuples, where i´ve got a lot of polygons ( with their code, same
as bithplace). Now i want to make a join, to obtai
Dear all,
I have a very strange problem with Access 2003 as frontend and PqSql 8.1 as
backend.
In my access application, i have order form with orderdetail subform.
Subform recordsource, based on a saved Access query that has very simple
calculated field "AMOUNT" that calculate
> > One other thing about our particular setup is that we use separate
> > schema's for all user data and the functions go in the public schema.
> > So before executing this function we issue something like 'set_path to
> > username,public'.
>
> Mph. Are you expecting the function to work for mor
snacktime <[EMAIL PROTECTED]> writes:
> I have a very strange issue that I'm not sure how to debug.
Hm, are you certain there is always only one row for each value of
s_oid? This command:
> status := active from recurbilling_transactions where s_oid = in_s_oid;
is going to give you a random one
I have a very strange issue that I'm not sure how to debug. This is
on postgresql 8.0.0rc5, Freebsd 5.4. Yes I know I should be upgrading
this version and it's scheduled, but it can't happen for another week
and for all I know this might still be an issue in current versions of
postgresql.
First
On Fri, 17 Nov 2000, Robert D. Nelson wrote:
> Try uninstalling everything related to postgres that is now installed. Then
> remove /var/lib/pgsql and any data directories that may exist. Start from
> scratch. Oh, and as to order? I just installed them all together, like "rpm
> -ivh postgresql-7.
Rich Shepard wrote:
> Thanks, Lamar. I upgraded the server package, and that appeared to work
> just fine. Then I installed the others. Is 'initdb' the proper way to
> restart everything, and creat a new /var/lib/pgsql? It's been a while since
> I worked with postgres, but I need to really dig i
> I actually do understand the differences among -i (install) -U (upgrade)
>and -F (freshen). What I don't understand is why what _should_ work _isn't_
>working.
>
> For example, as Lamar and others suggested:
>
>[root@salmo rshepard]# rpm -qa | grep postgres
>postgresql-server-6.5.3-1
>postgres
On Fri, 17 Nov 2000, Lamar Owen wrote:
> Once you have verified with rpm -qa|grep postgres that there are no more
> postgresql RPM's on your system, then you will need to clean out the old
> 6.5.3 data directory (rm -rf /var/lib/pgsql).
>
> Now you should be able to install the new RPMset.
Tha
Rich Shepard wrote:
> On Thu, 16 Nov 2000, Lamar Owen wrote:
> > The result of 'rpm -qa|grep postgres' would be educational here.
> [root@salmo rshepard]# rpm -qa | grep postgres
> postgresql-server-6.5.3-1
> postgresql-test-6.5.3-1
> postgresql-7.0.3-2
> "Aha, I said. The rpm database thinks
On Thu, 16 Nov 2000, Lamar Owen wrote:
> The result of 'rpm -qa|grep postgres' would be educational here.
I actually do understand the differences among -i (install) -U (upgrade)
and -F (freshen). What I don't understand is why what _should_ work _isn't_
working.
For example, as Lamar and o
On Wed, 15 Nov 2000, Lamar Owen wrote:
> Use --nodeps to override dependencies. It is complaining because RPM
> apparently has no record of /lib/cpp -- rpm --rebuilddb may be needed.
> RPM's dependencies are not checked against the filesystem, but against
> the RPM database. You can verify this
Rich Shepard wrote:
> So, can someone please explain to me why the 7.0.3-1 package complains
> that /lib/cpp isn't there when it is? FWIW, I got the same error when I
> tried using the --force switch with rpm. Something's screwy here.
Use --nodeps to override dependencies. It is complaining be
Ever since I upgraded to 6.5.2 I've had problems upgrading to the 7.x
series. I'm running Red Hat 6.1 (2.2.17 kernel) on this box.
Now I'm trying to upgrade to 7.0.3 via the rpm. When I tried both the
freshen (-F) and upgrade (-U) switches, I found a failed dependency:
/lib/gcc! and a bunch o
71 matches
Mail list logo
